Oczekiwania absolwentów a rzeczywistość [zamknięte]

Wybierając to, co chcemy studiować i robić z karierą i życiem, wszyscy mamy pewne oczekiwania co do tego, jak to będzie. Teraz, kiedy pracuję w branży od prawie dekady, zastanawiam się trochę nad tym, co myślałem (kiedy studiowałem informatykę), jak będzie wyglądało życie zawodowe w programowaniu i jak się to właściwie kończy być.

Moimi dwoma największymi wstrząsami (a raczej, mówiąc, złamanymi oczekiwaniami) są sama ilość prac konserwacyjnych związanych z oprogramowaniem oraz ogólny brak profesjonalizmu:

1. Konserwacja : W uni wszyscy powiedziano nam, że większość prac programowych polega na konserwacji istniejących systemów. Więc wiedziałem, że mogę oczekiwać tego w sposób abstrakcyjny. Ale nigdy nie wyobrażałem sobie, jak by to było przytłaczające. Być może jest to coś, co przemknęło mi przez myśl i miałam nadzieję, że będę budować nowe fajne rzeczy od zera. Ale tak naprawdę jest tak, że większość zadań w przeważającej mierze wymaga konserwacji, naprawy błędów i wsparcia.

2. Brak profesjonalizmu : na uniwersytecie zawsze miałem wrażenie, że oprogramowanie komercyjne jest bardzo zorientowane na proces i rygorystycznie zaprojektowane. Miałem zdjęcia procesów ISO, ryz dokumentacji technicznej, ściśle opisane wszystkie cechy i błędy oraz ogólnie profesjonalne środowisko. Ogromnym szokiem było uświadomienie sobie, że większość firm programistycznych nie działa inaczej niż zespół studentów pracujących nad dużym semestralnym projektem. Pracowałem zarówno w małym, zwinnym sklepie hakerskim, jak i średniej wielkości korporacji. Chociaż nie powiedziałbym, że zawsze było to „nieprofesjonalne”, zdecydowanie wydaje się, że branża oprogramowania (ogólnie) jest daleka od silnej dyscypliny inżynieryjnej, której się spodziewałem.

Czy ktoś jeszcze miał podobne doświadczenia? W jaki sposób Twoje oczekiwania dotyczące tego, jak wyglądałby nasz zawód, różniły się od rzeczywistości?

Czuję cię człowieku. Właśnie ukończyłem szkołę nieco ponad rok temu, skorzystałem z pierwszej oferty pracy, która pojawiła się na mojej drodze i doznałem największego szoku w moim życiu.

Czego się nie spodziewałem:

Stres w szkole i stres w pracy nie są takie same - stres związany z pracą nad projektem szkolnym z przyjaciółmi lub pracą w pojedynkę, nawet z tym zbliżającym się terminem pracy dyplomowej lub specjalną obroną projektu nie jest porównywalny do stresu wynikającego z pozornie nieuzasadnionych terminów pracy, problemów z komunikacją , (trochę polityki biurowej) i czasy kryzysu.

Brak najlepszych praktyk - tak samo jak Twoje doświadczenie w zakresie profesjonalizmu. Przed podjęciem pierwszej pracy i podczas szkolenia zacząłem przeglądać i czytać o najlepszych praktykach zarówno w programowaniu, jak i inżynierii oprogramowania. Nie są one przestrzegane tak dobrze, jak powinny, z niepraktycznych i, szczerze mówiąc, praktycznych powodów. A czasami twoja wiedza ma bardzo małe znaczenie dla innych, którzy jedynie boją się nieznanego i traktują te praktyki z pogardą.

To, czego nauczyli w szkole, było tylko wierzchołkiem góry lodowej. Myśląc, że to, czego nauczyłem się samokształcenia i na zajęciach, wystarczyło, aby mnie przejść, byłem zszokowany, mówiąc co najmniej, gdy byłem oszołomiony pierwszym fragmentem kodu, którym byłem powinien utrzymać. Wiele umiejętności, których teraz używam, nauczyłem się w pracy lub w trakcie pracy i wciąż zastanawiam się, czy nie dałbym rady w ogóle. XD

Znaczenie komunikacji - uświadomiłem sobie, do czego służą te wszystkie zajęcia z języka angielskiego. Przed prawdziwym światem nie widziałem znaczenia posiadania od trzech do czterech różnych klas języka angielskiego w college'u, gdy uczy się go, odkąd byliśmy w pierwszej klasie. Nie ma sensu w pracy, gdy można rozmawiać z komputerem, ale nie można rozmawiać z ludźmi.

Większość pracy, którą wykonujesz, nie jest przełomowa

W Uni pracowałem nad procedurami sztucznej inteligencji do sterowania robotami do gry w piłkę nożną, budowałem kompilatory i hakowałem jądra systemu operacyjnego.

Ale w prawdziwym świecie 99% ^* opracowywania oprogramowania jest dość nudne. Zawsze podziwiałem architektów lub budowniczych, którzy na pytanie „czym zarabiasz na życie?” może wskazać budynek lub cokolwiek i powiedzieć „Zrobiłem to ”. Ale większość programistów nie może tego zrobić. Na pytanie „co zarabiasz na życie?” najbliżej tego, do jakiej kiedykolwiek mogłem przyjść, było to, że pracowałem dla firmy, która tworzyła oprogramowanie przetwarzające wiadomości SMS dla stacji radiowych i tym podobne ... mógłbym powiedzieć: „wiesz, kiedy piszesz stacji radiowej, która zagłosuje na piosenkę, napisałem oprogramowanie przetwarzające te głosy i tak dalej. ” Nadal nie jest tak fajnie, jak być w stanie wskazać budynek i powiedzieć „Zbudowałem to”.

Oczywiście są ludzie, którzy mogą powiedzieć „pracowałem na systemie Windows” lub cokolwiek innego, ale jestem pewien, że tak naprawdę nikomu nie mówią, że w obawie przed następnym pytaniem brzmi: „Nie mogę uruchomić drukarki, możesz to dla mnie naprawić? ”

^* i 62% wszystkich statystyk jest sporządzanych na miejscu

Jeśli spojrzysz na oprogramowanie dzisiaj, z perspektywy historii inżynierii, z pewnością jest to swego rodzaju inżynieria - ale jest to rodzaj inżynierii, którą zrobili ludzie bez koncepcji łuku. Większość dzisiejszego oprogramowania przypomina egipską piramidę z milionami cegieł ułożonych jeden na drugim, bez strukturalnej integralności, ale zrobionymi przez brutalną siłę i tysiące niewolników. -Alan Kay, 2004

pełny wywiad: http://queue.acm.org/detail.cfm?id=1039523

Nie jestem weterynarzem branżowym; Wręcz przeciwnie, jestem niedawnym absolwentem, ale z czołowej szkoły CS w USA. Ale instynktownie mam wrażenie, że sposób, w jaki tworzymy oprogramowanie, jest zły. Zamiast naciskać przycisk pauzy i ponownie analizować podstawy tego, jak programujemy, pospieszyliśmy naprzód, używając przestarzałych modeli z lat 50. i 60. ciągle dodając trochę cukru na wierzchu. Jeśli będziemy tak postępować, nigdy nie przejdziemy tam, gdzie jesteśmy. Ludzie po prostu nie są w stanie poradzić sobie ze złożonością rzeczy wielkości bazy kodu MS Windows. Potrzebujemy nowego sposobu. Nie wiem co to jest.

Myślę, że to jest podstawowa przyczyna przekonania, że ​​duże i małe sklepy z oprogramowaniem wydają się tworzyć oprogramowanie poprzez zhakowanie go razem bez głębokiego zrozumienia podstawowych zasad.

Nie dostałem dyplomu, ale trochę podniosłem w bibliotekach i laboratoriach uniwersyteckich.

• Big Iron - Technologie, których nauczali, to przede wszystkim komputery mainframe i minikomputery. Dziekan jednego z college'ów powiedział mi, że nie będę w stanie znaleźć pracy, bo nawet nie wiedziałem, co to jest masterfile. Nie miałem zamiaru pracować na komputerach mainframe, ponieważ nie było mnie stać, ale nie zamierzałem być tak głupi, żeby nie być lekko przygotowany. VAXen były fajne i nie mogłem się doczekać, aż dostanę wynagrodzenie za kodowanie na własnym Micro VAX w mojej szafie. Jaka szkoda, że ​​ten rynek całkowicie się rozsypał. (Jak się okazało, miałem dwie pozycje związane z komputerami mainframe… jako wykonawca dla IBM.)

• Inżynieria oprogramowania - w ślad za programowaniem strukturalnym, SASD i innymi metodami projektowania, moglibyście pomyśleć, że będziemy prawdziwymi inżynierami. Zrobiłem. Ale nauczyciele udzielali bardzo mało wskazówek na temat technik projektowania, które czytałem w bibliotece. Studenci zostali zmuszeni do samodzielnej walki, a mikroskopy sprawiły, że zbyt łatwo było sflashować kod, dopóki nie otrzymali odpowiedzi, z której byli zadowoleni. Nie zdawałem sobie sprawy, jak gorzej było na rynku pracy. Jakoś musiałem napisać całkiem sporo nowego kodu, więc nie było tak nudno. Ale też dużo przejęłam i były wystarczająco złe, to było jak nowy projekt, ponieważ musiałem naprawić dużo kodu. Było to połączenie badania istniejącej funkcjonalności i stworzenia nowego kodu (jego zastąpienia); narzędzia do pisania w celu uproszczenia procesu i ustanowienia lepszego zarządzania projektami.

• Zaawansowana kariera - to jedno, gdy szkoły mają stare budynki i wyposażenie (wyposażenie w karty dziurkacza zostało zastąpione semestrem, zanim zacząłem… w 1984 roku), ale kiedy pracujesz w słabo oświetlonym magazynie lub dla szefa, który się rozłącza kiedy klienci dzwonią na linię wsparcia, zaczynasz zdawać sobie sprawę z tego, że opis pracy prawdopodobnie nie obejmuje gotowania popcornu za pomocą 5-megawatowego lasera.

• Rozwój polega głównie na pracy zespołowej. Oznacza to, że komunikacja (mówiona i czytana), czytanie kodu innych osób i ponowne wykorzystywanie poprzednich modułów (zarówno wewnętrznych, jak i zewnętrznych) jest czymś, z czym można się spotkać prawie codziennie. Na studiach przynajmniej w kilku przypadkach musiałem kodować z większą liczbą osób, więc pomyślałem, że główną częścią pracy było kodowanie samemu na pustyni. Nie jest.
• Wyjaśnianie rzeczy osobom, które nie są programistami, jest trudne (dotyczy to również pierwszego punktu) i Twoim obowiązkiem jest zdobycie punktów (nie z innych 99% świata).
• Dobry test to test, który się nie udaje. (przynajmniej za pierwszym razem) I oczywiście nie ma czegoś takiego jak kod wolny od błędów. Nie jesteś złym programistą, jeśli masz błędy. Błędy są tylko (bardzo ważną i czasochłonną) częścią twojej pracy.
• Nie ma srebrnych kul. Każda technologia ma swoje zalety i wady.
• College nie uczy Cię najnowszych technologii. Ale również 90% prac wykorzystuje całkiem stare technologie. Co, nawiasem mówiąc, czasami jest potrzebne.
• Osoby nietechniczne podejmują decyzje dotyczące rozwiązań technicznych , głównie z powodów ezoterycznych, takich jak utrzymanie, partnerstwo, dostępność pracownika ...
• Właśnie zaczynasz , młody padawanie .

Od tego czasu zacząłem zdawać sobie sprawę z tego, że kodowanie to praca, którą wykonujesz w połączeniu z większą liczbą ludzi, szczególnie teraz, gdy otwarte oprogramowanie jest bardziej widoczne. Ale kiedy byłem na studiach (pod koniec lat dziewięćdziesiątych), byłem przekonany, że będę robił rzeczy od zera i nigdy nie zajrzę do kodu innych osób ani nie będę musiał koordynować z innymi ...

Patrząc wstecz, dla mnie jedną z najlepszych części jest uczenie się i nauczanie innych .

• Programowanie komputerowe jest niefizyczne i nieintuicyjne.
  • Kiedy budowniczy domu zakończy pracę, może przejść się i od razu zobaczyć / poczuć, czy coś jest nie tak. Błąd programowania komputera nie może zostać wykryty w ten sam sposób i może czaić się w systemie przez miesiące, a nawet dekady.
  • Podczas gdy programista może przeglądać / wyczuwać fragment kodu źródłowego poprzez przegląd kodu, nie ma gwarancji wykrycia każdego błędu zawartego w kodzie. Komputer byłby jednak w stanie dokładnie odtworzyć błąd za każdym razem, wykonując program z określonymi danymi wejściowymi. Zatem ludzkie rozumienie fragmentu kodu źródłowego jest zawsze niedoskonałym modelem esencji tego, że jest instrukcją dla komputera.
• Kodowanie programu, który obsługuje najczęstsze przypadki, jest bardzo łatwe, ale całkowicie nie obsługuje przypadków skrajnych.
  • W innych dyscyplinach stosunkowo łatwo jest zastosować działanie naprawcze po fakcie. Może nawet istnieć zasób wiedzy poświęcony działaniom naprawczym. W tworzeniu oprogramowania nie ma czegoś takiego.
  • Na szczęście rozwój oparty na testach pomaga kodyfikować przypadki brzegowe, które ma obsługiwać kod.
  • Dodane Z drugiej strony niektóre metody opracowywania oprogramowania wydają się sugerować, że możemy wydobyć wartość biznesową (szybszy czas wprowadzenia produktu na rynek itp.), Świadomie decydując się nie zajmować przypadkowymi przypadkami i przekazać te decyzje klientom.
• Klienci mogą znaleźć wartości biznesowe w oprogramowaniu, które obsługuje tylko najczęstsze przypadki, dlatego dostawcy oprogramowania nie przejmują się zbytnio rzadkimi przypadkami.
  • Klienci po prostu uczą się unikać szorstkich krawędzi.

Dodany

• Elegancja kodu źródłowego nie jest ceniona.
  • Klienci nie widzą elegancji kodu źródłowego. Widzą tylko elegancję interfejsu użytkownika i interakcji.
  • Z drugiej strony programiści zwykle nie cenią elegancji interfejsu użytkownika i zwykle nie pozostają w jednym projekcie przez wystarczająco długi czas, aby zacząć doceniać elegancki projekt oprogramowania.
  • Ponieważ ani klienci, ani programiści nie cenią elegancji kodu źródłowego, nie będą one również cenione przez firmy.

Dodany

Moje dwa centy: przyzwyczaj się do tego.

Obrazy procesów ISO, ryz dokumentacji technicznej, wszystkie cechy i błędy są ściśle dokumentowane, a ogólnie profesjonalne środowisko dość dobrze opisuje moją firmę. Zajmujemy się jednak tworzeniem oprogramowania / sprzętu o krytycznej infrastrukturze, więc cóż, presja jest na jakość (na przykład mamy certyfikat ISO 9001).

Po ukończeniu studiów pomyślałem, że osoby odpowiedzialne będą w stanie rozpoznać dobrą pracę po złej pracy. Po wręczeniu milionowej kopii „naprawdę świetnego kodu nasz najlepszy programista zmontował” i wyglądał tak:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Prawie zrezygnowałem z próby zrozumienia, co dzieje się między uszami spiczastego włosa szefa. „Wielki” oznacza koszmar utrzymania, „dobry” oznacza awarie w łagodnym wietrze, a „okropny bałagan” oznacza albo dobrze skonstruowaną bazę kodu, której inżynierowie najwyraźniej odmówili przestrzegania nieprzyzwoitych terminów tylko po to, by zachować zdrowie psychiczne.

Słyszałem, jak argumentuje, że cała inżynieria oprogramowania po pierwszym wierszu kodu to utrzymanie. I to z pewnością wydaje się pasować do moich doświadczeń. Jedynym kodem, który napisałem, a który nie kosztował większości utrzymania, był kod, który był tak nieudany, że nigdy nie był używany lub tylko na krótko.

Myślę, że można znaleźć zespoły inżynierów, którzy opracowują i postępują zgodnie z silnymi procesami, które prowadzą do wydania solidnego kodu, w który zespół może mieć wysoki poziom zaufania (chociaż nie zawiłbym tego przy dużej ilości dokumentacji). Uważam, że obecnie pracuję w takim zespole. Chociaż z pewnością doświadczyłem innego rodzaju rozwoju.

Doceniam jednak to, że wyzwaniem nie zawsze jest znalezienie idealnego algorytmu lub najczystszego rozwiązania problemu. Ale często wymienia się wszelkiego rodzaju ograniczenia (zasoby, wiedza, pieniądze, czas, umiejętności, ryzyko, wcześniej istniejące szkolenia użytkowników itp.), Aby osiągnąć najwyższy zwrot z dostępnej inwestycji. To buduje system, który najlepiej pasuje do wszystkich tych czynników, a nie tylko wpływów technicznych.

Wiele programów po prostu nie wystarcza do tego, aby się wystarczająco wykorzystać / kupić. Kiedy się go robi, ma tendencję do pozostawania w pobliżu i jest „zawalony” podczas konserwacji.

Oczekiwania użytkowników rosną każdego dnia w stosunku do funkcji, ale w wielu obszarach są niższe w obszarach inżynierii. Załóżmy, że oprogramowanie do transakcji bankowych jest tak solidne i profesjonalnie zaprojektowane jak nowoczesny samochód. Obsługa wolumenu jest nowoczesnym cudem, ale co nad niezawodnością każdej transakcji? Nie tak bardzo. Twój post o pierwszym gównie szczeniaka na dywanie został odrzucony, więc co. To bardziej jak małe plastikowe torby w sklepie spożywczym. Robią ich miliardy, rozdzierają i łzą i zostają wyrzuceni. Większość ludzi nie dba o to, aby wymagać lepszej torby.

Myślę, że w końcu powstaje oprogramowanie wysokiej jakości. Niektóre z nich trafiają na rynek wcześniej niż większość komercyjnych produktów. Kto może prowadzić samochód w wersji beta?