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:
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.
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?
źródło
Odpowiedzi:
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.
źródło
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
źródło
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.
źródło
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.
źródło
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 .
źródło
Dodany
Dodany
Moje dwa centy: przyzwyczaj się do tego.
źródło
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).
źródło
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:
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.
źródło
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.
źródło
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?
źródło