Czy programowanie to zawód w wyścigu do dna? [Zamknięte]

Wydaje mi się, że branża programistyczna pędzi w dół. Jeśli zastosujemy praktyki:

1. Nie poświęcanie czasu na wdrażanie najlepszych praktyk
2. Maksymalne wykorzystanie kodu osób innych osób (kod niestandardowy jako zobowiązanie)
3. Używanie coraz wyższych języków w celu poprawy wydajności
4. „Narzędzia” programistyczne oparte na GUI, które znacznie upraszczają „programowanie” i nie wymagają od ludzi rozumienia hydrauliki stojącej za kodem

Te rzeczy sugerują mi, że jesteśmy w wyścigu, aby stać się jak każdy inny pracownik biurowy. W interesie pracodawcy jest, aby rzeczy nie wymagały umiejętności (łatwiej je wymienić), aby rzeczy były wstępnie budowane (krótszy czas projektu).

Chodzi mi o to, że a) czy istnieje rozbieżność między umiejętnościami a interesami ekonomicznymi pracodawcy? oraz b) jeśli tak, to w jaki sposób łagodzicie go w celu egzekwowania standardów zawodowych?

Myślę, że zadałeś bardzo przejmujące pytanie.

Tworzenie narzędzi do kodowania GUI wyklucza programistów z pracy, podobnie jak roboty wykluczają z pracy pracowników linii montażowej. Moim zdaniem, pomimo utraty miejsc pracy, następuje również zmiana w miejscu, gdzie znajdują się kolejne miejsca pracy.

Technologia wykonania zadania zmienia się, ale zadanie wciąż musi zostać ukończone: samochody muszą być wykonane / zmontowane, zanim będą mogły być prowadzone; kod / logika biznesowa musi być jeszcze połączona, aby aplikacja mogła działać.

Zmiany technologiczne dają wybory programistom: poznaj programowanie oparte na graficznym interfejsie użytkownika lub programowe narzędzia GUI ... lub ... coś zupełnie innego.

Może wystąpić rozbieżność między umiejętnościami pracowników a interesem pracodawcy, ale nie na długo, szczególnie jeśli pracodawca jest bystry. Dlatego w najlepszym interesie zarówno pracodawcy, jak i pracownika leży dążenie do tego, co jest dla nich obopólne. Ale jedno nieuchronnie wyprzedzi drugie. Mam nadzieję, że to ty (-:

Wszystkiego najlepszego,

KM

Do wspomnianych trendów dodam jeszcze jeden, który IMHO je wyjaśnia:

Potrzebnych jest znacznie więcej programistów niż kiedykolwiek.

Ilość zadań wymagających lub obejmujących programowanie stale rośnie i jest jeszcze szybsza niż liczba programistów. Obecnie w przeciętnym samochodzie jest kilka mikroczipów. Za 5 lat może być chip w lodówce i tosterze. Za 10 lat twoja bielizna? ... I ktoś musi wyprodukować całe to oprogramowanie, żeby te działały. Dlatego dokładamy wszelkich starań, aby zautomatyzować wszystko, co jest zautomatyzowane, i poprawić „produktywność” (jakkolwiek jest to zdefiniowane). I rekrutuje się coraz więcej świeżych mózgów.

Oznacza to, że większość dzisiejszych aktywnych programistów jest niedoświadczona i / lub źle przygotowana do pracy. Osiągnięcie odpowiedniego poziomu doświadczenia zajmuje kilka lat i ciągłe uczenie się, aby się tam utrzymać. Najważniejsze jest to, że coraz więcej zadań związanych z programowaniem staje się coraz trudniejszych. Ale wciąż jest wystarczająco dużo wyzwań dla każdego, kto ich szuka .

Pozwól, że zagram adwokata diabła przeciwko twoim punktom powyżej:

Nie poświęcanie czasu na wdrażanie najlepszych praktyk

Wiele osób tego nie robi, wiele osób tak robi. Dziesięć lat temu, kiedy po raz pierwszy odkryłem testy jednostkowe i zwinne podejście, żaden z moich kolegów nie miał najmniejszego pojęcia, co to jest. Obecnie jest to prawie standardowy materiał na uniwersytetach, więc wielu świeżo upieczonych absolwentów już to rozumie.

Maksymalne wykorzystanie kodu osób innych osób (kod niestandardowy jako zobowiązanie)

W przeciwieństwie do czego? Nowe podejście do koła? A może używasz kodu innej osoby, aby tego uniknąć?

Myślę, że ważne jest, aby pamiętać, że zarabia się (głównie) na rozwiązywaniu problemów, a pisanie kodu to nie koniec, tylko środki na to . Jeśli problem można rozwiązać bez napisania jednego wiersza kodu, nadal cieszy klienta. Zwłaszcza jeśli w ten sposób uda nam się stworzyć bardziej niezawodne rozwiązanie szybciej i taniej. Nie widzę z tym żadnego problemu.

Używanie coraz wyższych języków w celu poprawy wydajności

W przeciwieństwie do kodowania wszystkiego w asemblerze? ;-)

„Narzędzia” programistyczne oparte na GUI, które znacznie upraszczają „programowanie” i nie wymagają od ludzi rozumienia hydrauliki stojącej za kodem

IMHO dowolne narzędzie może być niewłaściwie użyte. Co nie znaczy, że konstruktory GUI były z konieczności doskonałe, a nawet dobre - większość (lub przynajmniej niektóre) z nich można wykorzystać w granicach swoich możliwości. Ale jeśli ktoś nie zna tych ograniczeń, czy jest to problem narzędzia lub jego użytkownika?

Ogólnie rzecz biorąc, uważam (choć nie ma na to dowodów), że w czasach kart dziurkowanych i kodów maszynowych, mniej więcej tyle samo części istniejącego kodu było okropne jak teraz, tylko oba

• ogólna ilość kodu, oraz
• szanse osób postronnych na zobaczenie takiego kodu

było znacznie mniej.

Teraz dzięki Internetowi i Daily WTF z dnia na dzień jesteśmy narażeni na najgorsze przykłady. To trochę tak, jak oglądanie wszystkich wiadomości o terroryzmie i trzęsieniach ziemi i rozwodach celebrytów oraz płacz, jak niebezpieczny i niemoralny stał się ten świat.

Poprawnie podsumowujesz sytuację, ale całkowicie błędnie interpretujesz znaczenie.

W miarę, jak oprogramowanie staje się coraz potężniejsze, zadania, które wykonuje wraz ze skalą. Dlatego na pewno nie będzie konieczne, aby być programistą bazy danych, aby utworzyć bazę danych kontaktów telefonicznych, gdy będzie można użyć programu Access. I nie musi być programistą internetowym, aby założyć blog, gdy możesz po prostu przejść do wordpress. Ale chociaż 15 lat temu konieczne byłoby bycie programistą, aby robić te rzeczy, to, co robią programiści, jest o rząd wielkości większy niż to, co można zrobić 15 lat temu.

Ujmę to w ten sposób: za 100 lat konfiguracja tak złożonego systemu jak Facebook czy Google będzie banalna. Nie mówię o ich stronach internetowych, mam na myśli ich centra danych. Każdy będzie mógł to zrobić. Zostanie wbudowany w telefony, zakładając, że nadal ich używamy. ALE wciąż będą programiści i chociaż za 100 lat nie będą mogli pracować na takich „trywialnych” systemach, będą pracować na systemach o wiele bardziej złożonych i wyrafinowanych, że nikt tutaj nie będzie w stanie zrozumieć ich zakresu i skala. Te systemy, podobnie jak obecnie, będą daleko poza zasięgiem przeciętnego pracownika biurowego, ponieważ niektórzy ludzie, zwani programistami, zdecydują się na specjalizację w posunięciu technologii tej epoki do granic możliwości.

Czytałem takie rzeczy od czterdziestu lat i nie byłem na początku prognoz. To się jeszcze nie wydarzyło.

COBOL był oryginalnym narzędziem programistycznym mającym na celu wyeliminowanie potrzeby programistów biznesowych i był językiem znacznie wyższego poziomu niż asembler. Biblioteki kodów (aby uniknąć konieczności pisania własnego kodu) mają podobną starożytność.

Co jakiś czas pojawia się coś, co pozwala programistom zrobić coś więcej niż programowanie. Były „języki czwartej generacji” z lat osiemdziesiątych, fantazyjne arkusze kalkulacyjne, takie jak Excel, generatory raportów i tym podobne. To, co jednolicie zrobili, jeśli zakończy się sukcesem, to usunięcie części kodu z programowania i umożliwienie programistom robienia innych, bardziej interesujących rzeczy.

Ten wzór nie będzie trwał wiecznie, ale będę potrzebować czegoś więcej niż teoretyczne argumenty i prognozy, aby przekonać mnie, że programowanie naprawdę idzie w dół.

Problem od COBOL do nowoczesnych narzędzi programistycznych polega na tym, że nie zastępują one możliwości przyjęcia niedokładnej specyfikacji i przekształcenia jej w coś precyzyjnego i użytecznego. To podstawowa umiejętność programistów i dlatego nie wyjeżdżamy na długi czas.

Programiści asembler i FORTRAN prawdopodobnie powiedzieli to samo, gdy pojawiały się programy ustrukturyzowane i powszechni tłumacze.

Na koniec oprogramowanie jest dziełem mającym zautomatyzować coś, co wcześniej było robione ręcznie. Dział księgowości w umiarkowanej korporacji wymagałby wcześniej kilkudziesięciu osób, teraz wszystkie te prace można wykonać przez pracę jednego lub dwóch. W rezultacie przesunęły się słupki bramkowe i teraz oczekujemy od księgowego tego dodatkowego standardu możliwości.

Renderowanie filmów trwa dłużej niż kiedykolwiek wcześniej. Pomimo ogromnego wzrostu prędkości obliczeniowej wraz z nim animatorzy domagali się coraz większej złożoności i szczegółów w swoich scenach. Animacja kalibru Toy Story jest niedopuszczalna w 2010 r., Podobnie jak w 1995 r. W miarę postępu ich narzędzi, ich możliwości, a tym samym oczekiwań.

Kiedy metody „przeciągnij i upuść” lub inne metody programowania są powszechne, świat będzie wymagał rozwiązań jeszcze trudniejszych i bardziej złożonych problemów i będzie potrzebował programistów korzystających z tych nowszych, wymyślnych narzędzi, aby je rozwiązać. Słupki bramek się poruszą.

Chociaż zgadzam się z większością odpowiedzi, które wskazują, że nadal będzie mnóstwo pracy, dam wam inną odpowiedź do rozważenia:

Tak, i powinno być

Jestem tutaj, aby zaprojektować rozwiązanie problemów, których inni nie mogą. Wszystko w zestawie narzędzi, które zabiera mi czas na rozwiązywanie problemów związanych ze wszystkimi drobnymi szczegółami wdrażania mojego projektu, jest marnotrawstwem.

Jedynym powodem, dla którego obawiałbym się przejścia na język wyższego poziomu lub prostsze i bardziej abstrakcyjne narzędzie, jest to, że narzędzia te często przyjmują założenia, które stają mi na drodze i wymagają czasu, aby obejść założenia, aby uzyskać pożądaną implementację.

Zawsze istnieje więcej problemów do rozwiązania niż dobrych rozwiązań. Nawet gdyby cały łańcuch deweloperów stał się tak prosty, że przedszkolaki mogłyby z niego korzystać, większość zaprojektowanych rozwiązań byłaby niewystarczająca lub wystarczająco nieefektywna, aby ludzie płacili za lepsze rozwiązanie, ponieważ większość ludzi po prostu źle widzi prawidłowe rozwiązanie problemów ze wszystkimi przypadkami na krawędzi i co, jeśli musisz wziąć pod uwagę dobre rozwiązanie.

Naszym zadaniem jest rozwiązywanie problemów lepiej niż większość pozostałych, złożoność łańcucha narzędzi nie jest szczególnie istotna w widoku dużego obrazu, dopóki nie przeszkadza i pozwala budować i budować coś dobrego.

Mimo że technologie programowania mogą ulec zmianie, złożoność oprogramowania nadal istnieje. Jeśli oprogramowanie można napisać całkowicie przy użyciu diagramów lub schematów blokowych (lub w inny „prosty” sposób), cała złożoność oprogramowania musi zostać jeszcze zrozumiana i rozwiązana. Z tego powodu ważne jest, aby pracodawcy mieli programistów, którzy znają produkty firmy na wylot, aby je zaktualizować lub dodać nowe funkcje. Nauka pracowników oprogramowania może zająć sporo czasu.

Bez względu na to, co możesz zautomatyzować lub ściągnąć z półki, większość spakowanych programów można podzielić na dwie kategorie:

1. Jest prosty w użyciu, ale nie do końca odpowiada potrzebom firmy
2. Jest wysoce konfigurowalny, ale specjalista musi zrozumieć i wykorzystać dostosowanie

Wydaje mi się, że zapomniałem o trzecim. To standardowe oprogramowanie zwiększające produktywność (e-mail, przeglądarka, Word Proc itp.). Oprogramowanie w pierwszej kategorii prowadzi firmy do zatrudniania programistów w celu dostosowania gotowego oprogramowania (jeśli to możliwe). równie dobrze mogliby zatrudnić programistę, ponieważ osoba, która wie, że konfigurowalny system wewnątrz i na zewnątrz jest albo bardzo poszukiwana (pomyśl SAP, PeopleSoft itp.), albo umierająca rasa (pomyśl dowolny system podobny do SAP i PeopleSoft, który nie do końca mają taką samą penetrację rynku).

Zawsze będzie potrzeba programistów. Widzę, że więcej z tego, co kiedyś było pracą manualną, żmudną, powtarzalną, zostało zautomatyzowane (pomyśl pisanie kodu dostępu do danych ręcznie, a nie O / RM). Umożliwia to programistom dostarczanie większej wartości dla firmy przy mniejszym wysiłku.

Nie biorę twoich argumentów:

1. Nie poświęcanie czasu na wdrażanie najlepszych praktyk

oprócz tego.

1. Maksymalne wykorzystanie kodu osób innych osób (kod niestandardowy jako zobowiązanie)

Ponowne użycie kodu jest najlepszą praktyką. Używany kod jest testowany. Oczywiście powinieneś używać kodu z dobrych źródeł, który jest utrzymywany i używany przez wielu.

1. Używanie coraz wyższych języków w celu poprawy wydajności

Wydajność sama w sobie nie jest zła - prawda?

1. „Narzędzia” programistyczne oparte na GUI, które znacznie upraszczają „programowanie” i nie wymagają od ludzi rozumienia hydrauliki stojącej za kodem

Jeśli narzędzie wykonuje zadanie: użyj go. Jeśli nie: odmów. Jeśli obietnica się spełni, a ludzie naprawdę nie muszą rozumieć kodu - dobra robota! Wydaje się, że mówisz, że to nie jest obietnica?

(Liczby tutaj są automatycznie ponownie źle wysyłane. :))

Programowanie wizualne jest nie mniej ważne i zasługuje na pogardę niż programowanie tekstowe.

Istnieją pewne braki i wyzwania podczas programowania wizualnego, ale hydraulika leżąca u jej podstaw jest potencjalnie niebezpieczna, gdy zostanie zignorowana, nie jest zmonopolizowana przez komponenty wizualne i, co bardziej istotne, projektantów wizualnych. Zignorowanie leżącej u podstaw hydrauliki stanowi ryzyko dla jakiegokolwiek rozwoju.

Jeśli masz szansę wypróbować Labview, możesz zobaczyć potencjał (lub nawet specjalistyczny wariant w środowisku Lego NXT). Chociaż nie bez wad i niedociągnięć, istnieją odziedziczone korzyści. Zobaczyć to uwierzyć.

Praktyki programowania nie tylko zwiększają produktywność i redukują koszty niektórych rodzajów rozwoju (wyścig do samego dołu), ale zwiększają możliwości aplikacji i oczekiwania klientów (zachęcając w ten sposób do wyścigu na szczyt). Zobacz, jakie premie wypłacają Goole i Facebook, aby zdobyć najlepszych technologów.

Nie ma innego zawodu, który zajmowałby się inżynierią egzystencji, która dąży do zmian tak samo jak programowanie. Gdy tylko coś uprościsz, po prostu otwierasz puszkę na nowe problemy, które rodzą nowe pomysły.

Więc nie zabrudziłbym wysiłków innych ludzi, aby dzielić się kodem i rozwiązaniami, aby pomóc nam przejść do nowych wyzwań, pomysłów i doświadczeń użytkowników ze złymi praktykami poszczególnych praktyków, złymi nawykami i obyczajami pozbawionymi humanizmu.

Jeśli zastosujemy praktyki:

WTF? Czy chodziło Ci o niespójność tej listy? Listy powinny pochodzić z tej samej strony dla każdego elementu, zamiast przełączać się tam iz powrotem bez ostrzeżenia. Dlatego twoja lista powinna brzmieć:

Jeśli zastosujemy praktyki: