Pisanie kodu nigdy nie było wąskim gardłem

Zapytaj inżyniera, co robił w tym tygodniu, a bardzo niewielka część odpowiedzi będzie dotyczyć wpisywania nowej logiki do pustego pliku.

Na co naprawdę idzie czas

Publiczny obraz tej pracy to komponowanie. Rzeczywistość jest bliższa archeologii, negocjacjom i naprawom.

Czytanie istniejącego kodu, żeby zrozumieć, co robi. Odtworzenie zgłoszonej usterki. Recenzowanie cudzej zmiany. Integracja z systemem, którego dokumentacja jest nieaktualna. Czekanie na build. Dyskutowanie podejścia. Wdrażanie. Sprawdzanie, dlaczego wdrożenie zachowało się inaczej niż środowisko testowe. Naprawianie czegoś, co działało dwa lata i przestało.

Faktyczne pisanie nowego kodu to prawdziwa część tej pracy i nie jest jej największą częścią, i rzadko jest tą częścią, która decyduje o sukcesie projektu.

To ma bezpośrednią konsekwencję dla szkoleń. Program rozwojowy skupiony wyłącznie na językach i frameworkach szkoli pod mniejszą połowę tej pracy. Kompetencje, które decydują o wyniku – czytanie nieznanych systemów, dobre recenzowanie, projektowanie pod zmianę, komunikowanie decyzji technicznej – da się nauczyć, a zwykle zostawia się je do wchłonięcia samoistnego.

Co obejmuje ten kierunek

Zakres: architektura, kod, testowanie, interfejsy programistyczne, kontrola wersji, wdrażanie i praca w zespole.

Cztery obszary.

Budowanie. Języki, projektowanie, interfejsy i rzemiosło pisania kodu, który inni mogą zmieniać.

Weryfikacja. Testowanie na każdym poziomie, recenzja i dyscyplina wiedzy, co naprawdę zostało sprawdzone.

Dostarczanie. Kontrola wersji, ciągła integracja, wdrażanie i praktyka wydawania.

Współpraca. Praca zespołowa nad wspólnym systemem, gdzie tak naprawdę leży większość trudności komercyjnego oprogramowania.

Największy wzrost zatrudnienia w całej tabeli

Warto podać to precyzyjnie, bo publiczna dyskusja o tym zawodzie stała się chaotyczna.

Amerykańskie Bureau of Labor Statistics prognozuje wzrost zatrudnienia deweloperów oprogramowania o 15,8 procent między 2024 a 2034 rokiem – to 267 700 nowych etatów. W tym samym zestawie prognoz to największy wzrost bezwzględny wśród śledzonych zawodów technologicznych, większy w liczbach bezwzględnych niż data scientiści i analitycy bezpieczeństwa informacji razem wzięci, mimo że oba te zawody rosną w wyższym tempie procentowym. Całkowite zatrudnienie we wszystkich zawodach ma w tym samym okresie wzrosnąć o 3,1 procent.

Do tej liczby należą od razu dwa zastrzeżenia, i pominięcie ich byłoby nieuczciwe.

To prognoza. Prognozy to modele zbudowane na założeniach dotyczących adopcji technologii i wzrostu branżowego, i są korygowane. Ta uwzględnia założenie, że sztuczna inteligencja podnosi produktywność, dlatego ta sama tabela pokazuje spadek zatrudnienia w kilku zawodach administracyjnych.

Zatrudnienie juniorów jest trudne. Absolwenci i osoby zmieniające karierę napotkali ciaśniejszy rynek, niż sugeruje nagłówkowy wskaźnik wzrostu, a zagregowany wzrost liczony w dekadach niczego nie mówi o tym, jak łatwo w danym roku dostać pierwszą pracę.

Wyjaśnienie polega na tym, że duża część prognozowanych wakatów wynika z zastąpień, nie ekspansji, i że popyt przechyla się w stronę ludzi, którzy potrafią pracować z istniejącymi systemami. To stwierdzenie, jakie szkolenie się opłaca, nie argument, że wzrost jest fikcyjny.

Recenzja to kompetencja, która skaluje zespół

Nauczalna kompetencja o najwyższej dźwigni w inżynierii oprogramowania, której niemal żadna organizacja nie uczy świadomie.

Code review to miejsce, gdzie łapie się defekty, zanim zaczną kosztować, gdzie wiedza rozchodzi się po zespole, gdzie standardy stają się realne, a nie tylko udokumentowane, i gdzie młodsi inżynierowie uczą się najszybciej. To też miejsce, gdzie marnuje się mnóstwo czasu i skąd bierze się zaskakująca część konfliktów w miejscu pracy.

Cztery rzeczy odróżniające przydatną recenzję od rytuału.

Wiedza, czego szukać. Poprawność, obsługa błędów, bezpieczeństwo, zachowanie przy skali i czy to będzie zrozumiałe za rok. Formatowanie powinno obsłużyć narzędzie, i to na nim niedoświadczeni recenzenci skupiają uwagę.

Recenzowanie projektu, nie diffa. Najcenniejszy komentarz to często to, że zmiana nie powinna istnieć w tej formie, a ten komentarz jest dużo tańszy, zanim praca zostanie wykonana.

Oddzielanie tego, co musi się zmienić, od tego, co zrobiłoby się inaczej. Mylenie preferencji z wymaganiem to pojedyncze największe źródło tarcia w recenzji i uczy ludzi, żeby przestali pytać.

Sprawianie, żeby było to bezpieczne. Kultura recenzji, w której ludzie boją się krytyki, daje mniejsze, późniejsze, mniej szczere zmiany i ukrywa problemy, aż stają się kosztowne.

Nic z tego nie jest trudne do nauczenia. Po prostu zakłada się, że uczy się przez ekspozycję, a ludzie uczą się tego, co akurat robił ich pierwszy zespół.

Gdzie to się mieści w domenie

Inżynieria oprogramowania to drugi z ośmiu kierunków w domenie AI, danych i informatyki Astra Trainer, i jest największy pod względem liczby etatów niemal w każdej organizacji partnerskiej. Opiera się na informatyce w zakresie leżącego pod nią modelu i łączy się dalej z cloud computingiem i DevOps, gdzie teraz mieszka połowa tej pracy dotycząca dostarczania.

Łączy się też z cyberbezpieczeństwem, bo duża część podatności to zwykłe defekty oprogramowania, oraz ze sztuczną inteligencją i uczeniem maszynowym, gdzie systemy wokół modelu to konwencjonalna inżynieria oprogramowania. Zobacz osiem kierunków tutaj.

Utrzymanie to praca, nie jej następstwo

Oprogramowanie nie jest gotowe w chwili wydania. Większość pieniędzy wydawanych na system w ciągu jego życia idzie po pierwszym wydaniu, a większość inżynierów spędza większość kariery, pracując nad kodem, który już istnieje.

A jednak niemal cała edukacja techniczna korzysta z ćwiczeń od zera. Ludzi uczy się budować coś nowego, w izolacji, z czystymi wymaganiami i bez historii, a potem zatrudnia się ich do systemu z piętnastoma latami zgromadzonych decyzji, częściowymi migracjami i komentarzami opisującymi zachowanie, które dawno się zmieniło.

Kompetencje, których wymaga ta luka, są konkretne i nauczalne.

Czytanie nieznanego kodu. Znalezienie punktu wejścia, śledzenie ścieżki, budowanie działającego modelu mentalnego bez czytania wszystkiego.

Bezpieczna zmiana kodu. Dodawanie testów do nietestowanego kodu przed jego modyfikacją, wprowadzanie małych, odwracalnych zmian i używanie typów oraz kontraktów, żeby ograniczyć skutek edycji.

Rozumienie, dlaczego coś jest takie, jakie jest. Wiele rzeczy wyglądających w starym kodzie irracjonalnie było poprawną reakcją na ograniczenie, które już nie istnieje, albo na błąd, o którym nikt już nie pamięta. Usunięcie tego bez wiedzy, o co chodziło, to sposób, w jaki powstają awarie.

Uczciwe zarządzanie długiem technicznym. Odróżnianie decyzji, które były rozsądnym kompromisem, od zaniedbania, które się nawarstwiło, i uwidacznianie kosztu każdej z nich ludziom, którzy decydują o priorytetach.

Migracja przyrostowa. Niemal każdy duży przepis podjęty jako jednorazowe zastąpienie jest ostrzegawczą historią. Migracja przyrostowa to kompetencja o znanych wzorcach, a rzadko się jej uczy.

Role, nazwane wprost

Inżynierowie oprogramowania, na froncie, backendzie i full stack.

Inżynierowie platformowi, budujący wewnętrzne narzędzia, od których zależą inne zespoły.

Inżynierowie mobilni.

Inżynierowie jakości i testów, w tym automatyzacji.

Site reliability engineerzy, gdzie inżynieria oprogramowania spotyka się z operacjami.

Architekci techniczni.

Kierownicy inżynierii i liderzy techniczni, gdzie ograniczeniem jest zwykle osąd, nie umiejętność kodowania.

Inżynierowie developer experience, rosnąca specjalizacja celująca w wąskie gardło zrozumienia i koordynacji.

Inżynierowie integracji, łączący systemy niezaprojektowane, żeby się spotkać.

Kogo można w to przeszkolić

Inżynierowie jakości i testów. Najsilniejsze wewnętrzne przekwalifikowanie. Już znają produkt, wiedzą, jak zawodzi, i znają bazę kodu od zewnątrz.

Inżynierowie wsparcia i operacji. W stronę developmentu, mając wiedzę produkcyjną, której zespołom deweloperskim brakuje i która jest im często potrzebna.

Analitycy danych. Już piszący kod, potrzebujący praktyki inżynierskiej: kontroli wersji, testowania, recenzji i projektowania pod zmianę.

Analitycy biznesowi i personel produktowy o technicznych skłonnościach, w stronę ról pokrewnych inżynierii, gdzie rozumienie dziedziny jest tą rzadszą połową.

Inżynierowie z innych dyscyplin. Mechanicy, elektrycy i inżynierowie budownictwa dobrze się przekwalifikowują, wnosząc systematyczną metodę.

Naukowcy i badacze, którzy już piszą kod do własnej pracy, potrzebujący praktyki zespołowej, nie samego programowania.

Doświadczeni deweloperzy w starzejących się technologiach. Często pomijani, mający głęboką wiedzę o systemach i potrzebujący aktualnego zestawu narzędzi, nie zmiany kariery.

Co z tego wynieść

Tworzenie nowego kodu to mniejszość tej pracy, a szkolenie obejmujące tylko języki i frameworki adresuje tę mniejszą połowę.

Deweloperzy oprogramowania mają dodać 267 700 miejsc pracy do 2034 roku, największy wzrost bezwzględny wśród zawodów technologicznych śledzonych przez BLS, a to prognoza towarzysząca naprawdę trudnemu rynkowi dla juniorów.

Code review to nauczalna kompetencja o najwyższej dźwigni w zespole i niemal powszechnie zostawiana samoistnemu wchłonięciu.

Utrzymanie i praca na starym kodzie to miejsce, gdzie faktycznie spędza się karierę, a edukacja szkoli przede wszystkim pod projekty od zera.

A najlepsi wewnętrzni kandydaci są zwykle w testach, wsparciu i operacjach, mając już wiedzę, której zdobycie zajmuje nowym pracownikom rok.