Dzisiejsi twórcy oprogramowania wkrótce przestaną kodować?

Podróż indywidualnego kontrybutora juniora

Wyobraź sobie: zaczyna się ścieżka kariery juniorki, która jest indywidualnym kontrybutorem. Dopiero co rozpoczęła swoją pierwszą rolę związaną z tworzeniem oprogramowania. Siedzi, schowana przy biurku, tworząc tysiące linii kodu miesięcznie.

Dostarcza wysokiej jakości pracę i zaczyna budować zaufanie wśród swoich kolegów z zespołu. Z czasem otrzymuje dodatkowe zaproszenia na spotkania od interesariuszy projektu. Jej menedżer prosi ją, aby popracowała nad problemami o szerszym zakresie i większej niejednoznaczności.

I zaczyna się zmiana. Zamiast powierzać jej dobrze zdefiniowane i jasno określone zadania, proszona jest o pisanie dokumentów projektowych, w których zarysowane są obszary problemowe i możliwe rozwiązania. Z czasem jej czas poświęcony na kodowanie zmniejsza się z 90 do 80, a później do 70%. Nie jest już zielona w temacie.

Jej doświadczenie się powiększa. Pracuje nad wieloma własnymi projektami i coraz bardziej angażuje się w projektowanie projektów kolegów z zespołu. Wraz z rozwojem jej umiejętności, nowe funkcje i ulepszenia, które opisała, piętrzą się szybciej, niż jest w stanie się nimi zająć. Widząc to, jej kierownik oferuje pomoc innego kolegi z zespołu, ale pod pewnym warunkiem: całe projektowanie i planowanie musi być wykonane na początku. Akceptuje, po czym zapisuje i przekazuje kilkanaście zadań do realizacji przez kolegę z zespołu.

Co stało się z kodowaniem?

Chociaż nadal uwielbia kodować, to stopniowo pracuje coraz mniej w VSCode, a więcej w Google docs. Ta anegdota, na dobre i na złe, to historia wielu programistów takich jak ja. Wraz ze zdobywanym doświadczeniem, moja wydajność jest mierzona w mniejszym stopniu w liniach kodu, a bardziej w mojej umiejętności zarządzania dużymi projektami, wpływania na kierunek techniczny zespołu i mentorowania innym.

Nawet jeśli pozostanę indywidualnym kontrybutorem i będę unikać zarządzania, to jest mało prawdopodobne, że kiedykolwiek będę kodować przez 90% mojego czasu. Zmaganie się z większymi obowiązkami zwiększa potrzebę współpracy i zapewnienia jasności przekazu wśród kolegów z zespołu, interesariuszy i partnerów działających w różnych dziedzinach. Nikt nie jest w stanie zrobić tego sam.

Co mogę z tym zrobić ja?

Gdy w pracy proponuje się większą odpowiedzialność, widzę dwa wyjścia. Mogę albo piąć się do góry lub wrócić do mojego przytulnego biurka z VSCode. Ani jedno, ani drugie nie jest z natury dobrym lub złym wyborem i moim zdaniem sam będziesz wiedział, co jest dla ciebie najlepsze, kiedy będziesz na to gotowy. Ostatni rok spędziłam na obydwu rozwiązaniach.

Moja podróż

Pierwszego dnia pracy w 2022 roku dołączyłam do nowego zespołu w firmie Meta. Jasno określiłam mojemu nowemu menedżerowi mój cel, jakim jest rozwijanie umiejętności poza moim obszarem specjalizacji (UX). Chciałam szerzej poznać back-end, aby zbudować moje umiejętności w kształcie litery T. Przyznaję, że chciałam też zwalczyć syndrom oszusta, który wykształciłam pracując na tak wysokim poziomie w stosie technologicznym.

Po sześciu miesiącach pracy w nowym zespole mój menedżer przydzielił mi projekt dotyczący prywatności w back-endzie o decydującym znaczeniu, który miał być zrealizowany jeszcze w tym samym roku. Zaraz po tym wkradł się do nas chaos, ponieważ jedna z naszych kluczowych symulacji uległa uszkodzeniu, a mój zespół kolejne dwa miesiące spędził na debugowaniu zależności end-to-end. Kiedyś nauczyłam się C++ w jeden dzień tylko po to, żeby złożyć pull request w bazie kodu innego zespołu.

Następnie, podczas debugowania dla projektu prywatności, zespół partnerski złożył SEV (tj. zgłoszenie priorytetowe) przeciwko naszemu UI. Funkcja, którą utrzymywałam, zawieszała się przy błędzie 500 OOM. Gdy oba projekty zostały przerwane, wyszłam daleko poza moją strefę komfortu.

Po rozwiązaniu SEV, wyjaśniłam mojemu tech leadowi i menedżerowi, że powoli optymalizowałam zapytania UI w ciągu ostatnich kilku tygodni. Rozumiałam pracę, którą miałam wykonać, ale nie mogłam znaleźć czasu, żeby to wszystko zrobić.

Mój menedżer zachęcił mnie do prowadzenia działań mających na celu naprawienie pozostałych, łatwych na naprawienia problemów z wydajnością UI. Nie zgodziłam się jednak. Chciałam skupić się na projekcie back-endowym, który został mi powierzony. Mimo że plan projektu prywatności przewidywał dodatkowo płatny czas, bałam się, że wzięcie na siebie większej odpowiedzialności w tym momencie byłoby zbyt dużym ryzykiem. Obawiałam się, że jeśli mi się nie uda, to już nikt mnie nigdy nie doceni i będę “tylko” osobą z UX.

Kiedy mój menedżer poprosił mnie o ponowne rozważenie możliwości poprowadzenia nowego projektu UI, ponownie odmówiłam. Wiedziałam już, na czym polega problem z UI i chciałam rozwijać się technicznie. Oznaczało to, że NIE pracowałam nad problemami związanymi z UI, i zamiast tego, pozwoliłam nowemu pracownikowi zajmować się tym, jako projektem na rozkręcenie.

Tego dnia postanowiłam wrócić do swojego biurka. Miałam swoje powody, by odmówić przyjęcia większej odpowiedzialności. Część z tego wynikała ze strachu, ale inna część z braku zrozumienia tego, czego mój menedżer wymagał ode mnie w tym właśnie momencie.

Innymi słowy, mogłabym prostym językiem opisać problem, pierwotną przyczynę i rozwiązanie większości problemów z wydajnością UI. Był w nich pewien wzór, który już wcześniej wykazałam. Pomyślałam więc, że jeśli pozwolę innemu koledze z zespołu rozwiązać resztę, wyświadczę im przysługę. Jak to mówią: „Nie daruj głodnemu ryby. Podaruj mu wędkę i naucz go łowić”.

Kilka miesięcy później zdałam sobie sprawę, że mój menedżer chciał, abym wykazała, że rozumiem swoją specjalizację, bez faktycznego wdrażania poprawek. Mogłabym napisać kilka zadań i, w ramach odrobiny LARP-u, publikować wewnętrznie informacje o postępie prac nad UI w określonym czasie.

Mój menedżer wiedział o moich celach zawodowych poza poszerzeniem zakresu technicznego. Tutaj szukał szczegółowej, pisemnej komunikacji o problemie. Prowadzenie działań UI pochłonęłoby jeszcze więcej mojego i tak już ograniczonego czasu na kilka tygodni. Niemniej jednak, mogłam również mieć wpływ na projekt, którego potrzebowałam w momencie, gdy mój projekt dotyczący prywatności miał trudności z wystartowaniem.

Z perspektywy czasu wszystko wydaje się prostsze. Gdybym mogła cofnąć się w czasie, podjęłabym dodatkowy wysiłek, aby wzbogacić swoje portfolio, które prowadziłoby do awansu. Jednak czułam się rozdarta. Mówienie „nie” w odpowiednim czasie jest ważną umiejętnością, która wymaga praktyki, i nikt nie powinien żałować, że stanął w obronie własnego zdrowia psychicznego.

Kilka miesięcy po mojej nieco rozczarowującej decyzji, do mojego zespołu dołączyła nowa absolwentka. Mój menedżer poprosił mnie, abym ją bardziej wprowadziła, dzięki czemu mogłabym zwolnić część własnych cykli, przydzielając jej pracę. Czułam się znacznie pewniej, jeśli chodzi o status mojego back-endowego projektu. Dzięki pewnej autorefleksji i nastawieniu na rozwój, przyjęłam nowe wyzwanie i zaczęłam przydzielać jej niektóre z moich zadań związanych z prywatnością, jak również zaprojektowałam dla niej nowy projekt migracji aktywów.

Teraz, gdy projekt dotyczący prywatności został zakończony na czas, z niecierpliwością czekam na rok 2023, w którym będę prowadziła jeszcze większy projekt backendowy z dużą ilością niewiadomych. Tym razem pod moim kierunkiem pracować będą dwie osoby. I po raz kolejny wyszłam daleko poza moją strefę komfortu. Jednak zaakceptowałam fakt, że taki dyskomfort to nieodłączna część tej podróży.

Powody, dla których możesz nie pisać kodu

Kodowanie nigdy nie będzie stanowiło 100% Twojego czasu pracy. Nawet juniorzy będą mieli spotkania, w których będą uczestniczyć i zadania do wykonania nie wymagające kodowania. Jako, że z czasem rozwijasz się w szeregach, poprzez seniora i jeszcze dalej, pracy, w której nie będziesz kodować, będzie tylko więcej. Poza uczestnictwem w spotkaniach, poniżej wyróżniłam kilka znaczących obowiązków, które wchodzą w zakres tej pracy:

Pisanie lub aktualizacja dokumentacji

Zacznij to robić w każdym możliwym momencie i nigdy nie przestawaj. Nikt nie jest „niewystarczająco doświadczony” - nawet nowi pracownicy mogą zacząć od uzupełnienia wszelkich luk koncepcyjnych lub „pułapek”, z którymi zetknęli się podczas onboardingu.

Pisanie dokumentu projektowego

W miarę jak problemy, którymi się zajmujesz, zwiększają swój zakres, niejednoznaczność i złożoność, będziesz musiał zacząć pisać propozycje projektowe. Zbierasz tam wymagania, przeprowadzasz analizy lub badania i dzielisz się swoimi odkryciami z interesariuszami i współpracownikami.

Juniorzy: nie pomijajcie tego kroku. Chociaż kodowanie samo w sobie brzmi kusząco, czasami warto zwolnić, aby móc działać szybciej. Lub, innymi słowy: „Mniej znaczy więcej”

Uwaga: Kiedyś pisałam na blogu o ćwiczeniach, które poprawią Twoje techniczne pisanie.

Wejść w czyjeś buty

Zespoły inżynierii oprogramowania zawsze będą borykać się z brakami w umiejętnościach. Będzie ci brakowało jakiegoś wsparcia interdyscyplinarnego, takiego jak kierownik projektu lub programu, product designer itp. W związku z tym może zaistnieć potrzeba rozwinięcia umiejętności w zakresie roli dodatkowej, takiej jak zarządzanie projektami, tak abyś był w stanie wyznaczać terminy i wykonywać inne obowiązki związane z nadzorowaniem zakończenia projektu.

Na przykład Meta ma „oddolną” kulturę inżynierską, co oznacza, że decyzje o tym, jaka praca zostanie faktycznie wykonana, pochodzą od indywidualnych kontrybutorów. Zazwyczaj jesteśmy pozostawieni sami sobie jako kierownicy projektów. Tak więc, ostatni tydzień spędziłam na składaniu notatek, wcześniejszej pracy rozpoznawczej i planowaniu celów do nowego planu dla mojego najbliższego projektu w 2023 roku.

Mentorowanie innych programistów w zespole

Wraz ze zdobytym w zespole doświadczeniem, zostaniesz poproszony o wprowadzenie do zespołu nowych pracowników, w tym mentorowanie młodszym programistom. Pełnienie roli mentora to dobra droga do poprawy Twoich umiejętności komunikacyjnych i przybliżenia cię do awansu.

O tym jak stać się świadomym mentorem w inżynierii oprogramowania było już trochę powiedziane, więc podzielę się tutaj tylko kilkoma spostrzeżeniami:

• Implementujcie razem — Daj nowicjuszom lub juniorom możliwości uczenia się w oparciu o Twoje wskazówki. Twórz jasno określone i dobrze zaplanowane zadania z początkowo minimalną niejednoznacznością, która z czasem może się zwiększyć.
• Wspieraj - Nowy pracownik nie napisze kodu dokładnie w taki sam sposób jak Ty. Daj temu przestrzeń, jednocześnie przestrzegając wytycznych dotyczących stylu zespołu i innych standardów. Zbalansuj pozytywne i konstruktywne informacje zwrotne w swoich code review.
• Spotykaj się regularnie 1:1-Spotykaj się na 15-30 minutowych rozmowach co tydzień lub dwa tygodnie, przez pierwsze kilka miesięcy, w zależności od potrzeb nowego pracownika. Zanotuj wszelkie problemy, z którymi się borykają, i w razie potrzeby przekaż je swojemu menedżerowi lub tech leadowi.

Podsumowanie

Ostatni sukces ChatGPT spowodował, że programiści ponownie zaczęli zastanawiać się nad tym czy i kiedy zostaną zastąpieni przez AI. Jednak my, programiści, już teraz sami zastępujemy się poprzez cykl rozwoju kariery w oprogramowaniu. Z każdym nowym poziomem stanowiska, indywidualny kontrybutor oddala się od edytora kodu i przybliża do większej ilości sal konferencyjnych.

W związku z tym, dzisiejszych twórców oprogramowania dzieli zaledwie kilka lat od całkowitego zaprzestania kodowania. Ta zmiana w obowiązkach zawodowych może wywoływać płacz i nostalgię za prostszymi czasami, ale kariery indywidualnych kontrybutorów rozwijają się w ten sposób, aby zrobić miejsce dla kolejnych. Innymi słowy, cykl kariery w naturalny sposób wzmacnia kolejne pokolenie programistów. To błogosławieństwo, że pracuję w zawodzie, który pozwala mi w znaczący sposób mentorować innym z intencją, że pewnego dnia będą jeszcze lepsi ode mnie.

Rosnące obowiązki w pracy sprawiły, że doceniłam swoje wcześniejsze doświadczenie kodowania. Dzięki udziałowi moich starszych kolegów mogłam ze spokojem i jasnością skoncentrować się na szczegółach dotyczących tylko implementacji. Od tego czasu stawiałam przed sobą nowe wyzwania i radziłam sobie z nimi na różne sposoby.

Postęp nigdy nie jest liniowy, ale z nastawieniem na rozwój w twoim arsenale narzędzi, awans na seniora nastąpi, jeśli tylko będziesz na niego gotowy.

Oryginał tekstu w języku angielskim przeczytasz tutaj.