Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Czego nauczyły mnie pierwsze dwa lata pracy jako inżynier oprogramowania

Mitchell Irvin Software Engineer / Palantir
Droga do zostania świetnym inżynierem oprogramowania jest długa i wymaga starannych kroków. Ale łatwiej ją przebrnąć wspólnie.
Czego nauczyły mnie pierwsze dwa lata pracy jako inżynier oprogramowania

Moja droga do zostania świetnym architektem oprogramowania wciąż trwa. Jednak zdążyłem się wiele nauczyć. Poniżej przedstawiam dwie historie, kilka lekcji, moje żale i cele po pierwszych dwóch latach pracy jako inżynier oprogramowania.

Uniwersytet i miejsce pracy

W 2015 roku byłem jeszcze studentem na University of Florida. W tym czasie studiowałem pod okiem profesora, który, podczas chyba najtrudniejszych zajęć na kierunku, przez cały semestr przydzielał wiele projektów zespołowych. Na zakończenie każdego projektu profesor oceniał każdego studenta indywidualnie. Kiedy pojawił się kolejny projekt, nasz profesor zgrupował najlepszych studentów z poprzednich zadań razem, i to samo zrobił z najgorszymi. Pod koniec semestru, każdy albo walczył w silnym zespole i odniósł sukces, albo zakończył z niepowodzeniem w zespole pełnym mało wydajnych osób. To było piękne. Silni nie byli zmuszeni do noszenia słabych, a słabi mogli tylko stać się silni lub umrzeć. Środowisko to można trafnie opisać słowem merytokracja. System ten nagradza najbardziej utalentowanych studentów i pozwala studentom, którzy nie pracowali ciężko zatonąć z własnym statkiem. Uwielbiałem to.

Rok później ukończyłem studia. Byłem energiczny, idealistyczny i gotowy, aby zaznaczyć swoją obecność na polu, na którym studiowałem przez ostatnie cztery lata. Po odbyciu stażu otrzymałem ofertę na stanowisko inżyniera oprogramowania w dużej firmie o dobrej reputacji. Pierwszego dnia wszedłem do biura pełen zapału, by zostać wielkim inżynierem oprogramowania.

Zacząłem pracę nad projektem z paraliżującym brakiem zasobów. Budowaliśmy aplikację internetową, która robi to, co robi większość aplikacji internetowych: eksponuje niektóre dane i pozwala użytkownikom na manipulowanie nimi. Pracowałem z dwoma innymi inżynierami nad rozwojem aplikacji oraz z jednym inżynierem ds. jakości, z którym robiłem testy. Zajęło mi tylko kilka miesięcy, by dojść do wniosku, że to ja jestem filarem trzymającym wszystko w górze. Użytkownicy potrzebowali nowej funkcji? Poradzę sobie z tym. Potrzebujemy kogoś, kto ułatwi nam retrospektywę? Jasne. Szybko znalazłem się w miejscu, gdzie bez mojego wysiłku niewiele się działo. W wieku 22 lat grałem rolę głównego inżyniera w firmie z listy Fortune 25.

Ale poczekaj chwilę.... mimo że przez prawie rok niosłem większość projektu na plecach, nadal otrzymywałem wynagrodzenie w wysokości ułamka tego, co moi bardziej doświadczeni członkowie zespołu zabierali do domu. Nie dostałem żadnej piątki za moją pracę, a oni nie dostawali żadnych pał. Nie miałem udziału w firmie. Miałem mniej wakacji. Co tu się dzieje? Bardzo szybko zacząłem to zauważać i równie szybko zacząłem obnosić się z frustracją. Z trudem przychodziło mi być cierpliwym i pomocnym kolegą z zespołu podczas pracy z mniej doświadczonymi inżynierami. Moja apatia wzrosła, a produktywność spadła. Jeśli sparują mnie z innym inżynierem i będę pracował w jego tempie (nawet jeśli jest to tylko 5% mojego), nadal wykonuje swoją pracę, prawda?

Ostatnie trzy miesiące spędziłem w ten sposób, a w atmosferze crunchu udało się zamknąć projekt. Morale zespołu było niskie. Nikt tak naprawdę nie świętował kulminacji tego 14-miesięcznego przedsięwzięcia. Co ważniejsze, wiedziałem, że kilku moich kolegów z zespołu nie będzie podekscytowanych perspektywą dalszej współpracy ze mną w przyszłości. Zacząłem zdawać sobie sprawę, jak bardzo moje nastawienie do środowiska pracy wpłynęło negatywnie na mnie samego i ludzi wokół mnie.

Kilka tygodni później wysłałem ankietę, szukając informacji zwrotnych na temat tego, jak mógłbym się poprawić jako kolega z zespołu. Wyniki badania pokazały, że jedna rzecz jest naprawdę jasna. Wydajność to nie wszystko. Wchodząc w swoją karierę zawodową, założyłem, że złoty standard merytokracji, który tak ceniłem w szkole, będzie taki sam w miejscu pracy. Że silny będzie odpowiednio nagrodzony a słaby sprawiedliwie ukarany. Ta percepcja zatruła moją zdolność do dobrej współpracy z innymi, do bycia wdzięcznym za ich wkład, do bycia pokornym i cierpliwym w nauce i w nauczaniu. Inni myśleli o mnie jedynie, że: "Jest zbyt skupiony na działaniu".

Lekcja 1: Twoje relacje ze współpracownikami (umiejętności interpersonalne/kierownicze) i Twoja sprawność techniczna (umiejętności twarde) są równie ważne.

Aby być wspaniałym inżynierem oprogramowania, musisz doskonalić swoje umiejętności przez wiele lat. Z czasem, będziesz podróżował w górę, w dół i z powrotem w górę po wykresie Dunninga-Krugera. Popełniasz błędy, uczysz się od innych i dzielisz się swoją wiedzą. Musisz mieć silną dyscyplinę techniczną. Jeśli jednak jest to jedyna siła, jaką masz, to będziesz nieszczęśliwy. Jeśli Twoim celem jest stać się najlepszym inżynierem oprogramowania, twoja podróż musi obejmować dążenie do zostania najlepszym kolegą z zespołu (i być może liderem) na świecie. Aby zacząć, musisz traktować ludzi wokół siebie z takim samym priorytetem jak siebie samego. 

Najlepszy inżynier, z którym kiedykolwiek pracowałem.

Pewnego września rano do naszego zespołu dołączyło dwóch nowych kontraktorów. Nasz zespół programuje w parach, więc pewnego dnia zostałem sparowany z jednym z nowych wykonawców na "stacji parowania", aby rozpocząć dzień pracy. W ciągu najbliższych siedmiu godzin ten inżynier (nazwijmy go Bobem) zadawał pytania. Kiedy pracowaliśmy nad nową funkcją, Bob zadawał pytania dotyczące języka i frameworka, którego używaliśmy. Kiedy dopracowywaliśmy szczegóły zasad biznesowych, Bob zadawał pytania dotyczące produktu i problemu, który rozwiązywaliśmy. Bob nie napisał zbyt wiele kodu tego dnia. Pod koniec dnia byłem trochę rozczarowany Bobem. Miałem duże nadzieje na jego umiejętności inżynierskie i miałem nadzieję, że jest kimś, od kogo mogę się uczyć.

Następnego dnia, Bob i ja pracowaliśmy nad napisaniem kolejnej funkcji. Jak napisałem wstępny test case dla tej funkcji, uruchomiłem go i uśmiechnąłem się, gdy wszystkie zielone znaki kontrolne pojawiły się na ekranie. Bob spojrzał, zamyślony, skupiony. Raptem przeszedł do testowanej metody i zmienił parę linii. Zaprotestowałem "Czekaj! To zachowanie jest niepoprawne". Kiwnął głową, a potem znów przeprowadził nasze testy. Wszystkie testy przeszły pomyślnie. O rany.

Tygodnie mijały a ja i Bob dalej pracowaliśmy w parze. Nadal zadawał pytania w miarę wykonywania naszej pracy. Zaczął formułować sugestie, gdy ja prowadziłem (aktywnie na klawiaturze/myszce), i zamieniał mnie “za kierownicą”, gdy tylko uznał to za stosowne. Odpowiedział na kilka z moich własnych pytań dotyczących naszych frameworków i wewnętrznego funkcjonowania języka oraz wprowadził wzorzec projektowy OO, którego nie znałem. Jego pytania dotyczące domeny i naszego problemu biznesowego zaczęły uwydatniać dziury w naszym oprogramowaniu. Ujawnił błędy i wady w naszym kodzie, które byłem przekonany, że nie istnieją. A jednak oto istniały, tuż przed moimi oczami. W miarę upływu czasu, wraz z Bobem rozwiązywaliśmy odkryte przez niego błędy, uczyniliśmy projekt kuloodpornym i znacznie poprawiliśmy relacje między problemem biznesowym a naszym kodem (więcej informacji na ten temat można znaleźć w koncepcji wszechobecnego języka Domain Driven Design).

W rozmowach naszego zespołu, Bob nikogo nie poniżał, kiedy myślał, że się mylą. Zadawał pytania. Ponieważ odpowiadali na te pytania, często znajdowali się tam, gdzie (podejrzewam) Bob był przez cały czas. W samym sercu niemal każdej decyzji związanej z oprogramowaniem zespół podejmował decyzję, na podstawie pytań Boba. Bob nie mówił nic o swoim wkładzie w pracę zespołu. Nigdy nie odnosił się do swoich umiejętności jako inżynier. Nie obchodziło go, ile czasu spędza na klawiaturze, kiedy z kimś pracował w parze. Bob jest najlepszym inżynierem, z którym kiedykolwiek pracowałem.

Lekcja 2: Twoja zdolność wpływania na innych jest w największym stopniu zdeterminowana twoją zdolnością pomagania im dojść do tego samego wniosku, co ty, na własną rękę.

Bob rzadko mówił, "co powinniśmy zrobić i dlaczego". Pytał innych o ich pomysły. Pod koniec większości rozmów, jego pytania doprowadziłyby innych do usunięcia prawie wszystkich innych pomysłów ze stołu. Oczywiście, Bob nie wszystkie pomysły Boba były zawsze idealne. Bardzo często otrzymywał odpowiedź na jedno ze swoich pytań, które skłaniało go do powiedzenia czegoś w efekcie: "Dobra uwaga". "Zróbmy tak." Jednak to on miał zdecydowanie najbardziej pozytywny wpływ na jakość naszego oprogramowania, ponieważ miał potężną zdolność wpływania na rozumowanie naszego zespołu. Spędzał jednak znacznie więcej czasu na zadawaniu pytań niż na dzieleniu się własnymi przemyśleniami.

Lekcja 3: Cechą kogoś, kto rozwiązuje problemy jest zadawanie wielu pytań, zanim zacznie myśleć nad rozwiązaniem. 

Jako inżynierowie oprogramowania jesteśmy, fundamentalnie, ludźmi od rozwiązywania problemów. Nauka czegoś nowego jest problemem do rozwiązania. Kodowanie jest problemem do rozwiązania. Komunikacja jest problemem do rozwiązania. Wspaniali inżynierowie oprogramowania są świetnymi rozwiązywaczami problemów, a rozwiązywanie problemów zaczyna się od zrozumienia problemu poprzez zadawanie pytań. Zadawanie pytań jest wyrazem szacunku dla pomysłów innych osób. Zadawanie pytań pozwala zebrać wiedzę, którą w przeciwnym razie nigdy byś nie pozyskał. Zadawanie pytań zwiększa szanse na to, że kiedy już podzielimy się odpowiedzią, odpowiedź ta będzie właściwa. Ludzie, którzy wymyślają świetne rozwiązanie, to najczęściej ci sami ludzie, którzy poświęcili czas na zrozumienie problemu.

Ostatnia notatka o Bobie. Był na tyle utalentowany technicznie, że mógłby zarządzać zespołami. Jestem pewien, że mógłby zostać architektem, gdyby miał ochotę. Ale nie. Bob lubi pisać kod. Lubi analizować domeny. Lubi projektować obiekty biznesowe i pisać solidne zestawy testów. Lubi dostarczać wysokiej jakości oprogramowanie.

Spoglądając wstecz

Moje pierwsze dwa lata to była przygoda. Tworzyłem oprogramowanie, psułem oprogramowanie i naprawiałem oprogramowanie. Siedziałem na spotkaniach, na których ludzie dosłownie zasypiali przy stole. Parę razy dostałem po łapach (często od samego siebie). Rzucałem się w wir pracy, radosnej i bolesnej.

Patrząc wstecz, oto rzeczy, których żałuję:

  • Te momenty, w których stawiałem pracę ponad ludźmi. Praca (produkt) zawsze sama się rozwiązuje. Ale związki i relacje są znacznie trudniejsze do utrzymania i naprawienia.
  • Te momenty, gdy patrzyłem na wszystko dookoła zamiast na siebie i do przodu. Nie stajesz się lepszym członkiem zespołu, koncentrując się na tym, co inni mogą poprawić. Stajesz się nim rozpoznając swoje słabości i mocne strony.
  • Te momenty, w których mówiłem, zamiast słuchać. Po prostu mówiąc nie nabierasz wiedzy ani empatii. 
  • Te momenty, w których byłem sfrustrowany czymś i nie komunikowałem tego otwarcie i szczerze moim przełożonym. Nie mogą mi pomóc, jeśli nie wiedzą, w czym tkwi problem.
  • Ten czas, który utraciłem na nauce AngularJS. Śpij słodko aniołku.

Jeśli bardzo się starasz i zależy ci na pracy, którą wykonujesz, nadepniesz komuś na odcisk. Pewnie kogoś obrazisz. Będziesz popełniać błąd za błędem. Gdy to się stanie, przede wszystkim skup się na ludziach. Weź odpowiedzialność, szczerze przeproś i pruj dalej do przodu. To jest umiejętność, która odróżnia tych, co na "Software Engineer" kończą, a tych, co stają się liderami w branży. Prawdopodobnie jesteś tym pierwszym, zwłaszcza jeśli mógłbyś zaoferować mi wiele krytycznych uwag na temat każdego, z kim pracujesz, ale nie myśl, że mam tak wiele złego do powiedzenia o tobie i twojej pracy. 

W miarę jak posuwam się naprzód, oto co jest najważniejsze:

  • Cel: zostać najlepszym inżynierem oprogramowania. Przede mną jeszcze setki mil a mogę tylko iść krok po kroku.
  • Cel: zostać najlepszym członkiem zespołu na świecie. Bycie najlepszym inżynierem oznacza bardzo niewiele, jeśli nie jestem pozytywną siłą relacyjną. Spójność zespołowa przewyższa indywidualne talenty.
  • Cel: utrzymanie priorytetów. Oprogramowanie nie jest ważniejsze niż moja duchowość, moje małżeństwo, moje przyjaźnie czy moje zdrowie. Zastanów się, jakie są twoje najważniejsze priorytety. Nie zamierzam poświęcać żadnej z tych rzeczy, na rzecz większej "produktywności".

Dwa lata temu wyruszyłem podróż, aby zostać najlepszym inżynierem oprogramowania, jakim mogę być. Dziś jestem o wiele bliżej celu niż wtedy i znacznie bardziej świadomy ile już przeszedłem. Powyższe historie i przemyślenia reprezentują część tej podróży. Przy odrobinie szczęścia, będą ci pomocne i przydadzą się w twojej podróży.

Masz coś do powiedzenia?

Podziel się tym z 120 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog