Pierwsze 90 dni: podręcznik inżyniera oprogramowania krok po kroku

Byłeś w samym środku walki.

Dopracowałeś swoje CV, aż lśniło. Rozwinąłeś swoje umiejętności i certyfikaty.

Dopracowałeś swój profil na GitHubie, uczyłeś się pytań dotyczących projektowania systemów, aż zaczęły ci się zlewać w jedno, i klikałeś „aplikuj” więcej razy, niż chciałbyś zliczyć.

Stawiłeś czoła maratonowi rekrutacyjnemu — tablice, zadania domowe, niezręczne chwile ciszy i wszystko inne. Rozwinąłeś swoje umiejętności i zachowałeś spokój.

A potem… nadszedł list z ofertą. Dostałeś tę pracę! Teraz zaczyna się prawdziwa praca.

Bo choć rekrutacja jest trudna, skuteczne wdrożenie jest jeszcze trudniejsze. To właśnie wtedy przechodzisz od kandydata do osoby wnoszącej realny wkład, a pierwsze wrażenie zaczyna mieć trwałe znaczenie. Twoje pierwsze 90 dni położą fundamenty pod wszystko, co nastąpi później.

W tym przewodniku pokażę ci, jak od początku skutecznie wejść w rolę nowego inżyniera oprogramowania, korzystając z praktycznych porad dwóch doświadczonych specjalistów z branży technologicznej, którzy sami przez to przeszli, wiedzą, co działa, i mają to już za sobą. Najpierw jednak przyjrzyjmy się bez złudzeń temu, co dziś właściwie oznacza bycie inżynierem oprogramowania.

Kim jest inżynier oprogramowania?

O rany, od czego zacząć? Mówiąc poważnie, można by napisać o tym całą książkę, częściowo dlatego, że tego określenia czasami używa się jako ogólnego terminu obejmującego wiele potencjalnych ról związanych ze wszystkimi etapami cyklu życia oprogramowania. W rezultacie istotne mogą być tu również inne nazwy stanowisk, takie jak deweloper czy programista. Używamy określenia „inżynier oprogramowania” jako terminu zbiorczego.

Oto zwięzła definicja inżynierii oprogramowania, pochodząca z Michigan Technological University, która pomoże nam zachować właściwy kierunek: „Inżynieria oprogramowania to dziedzina informatyki zajmująca się projektowaniem, tworzeniem, testowaniem i utrzymaniem aplikacji. Inżynierowie oprogramowania stosują zasady inżynierii oraz znajomość języków programowania, aby tworzyć rozwiązania programistyczne dla użytkowników końcowych”.

Jeśli sprowadzić to do najprostszych słów, brzmi to mniej więcej tak: inżynierowie oprogramowania tworzą cyfrowe rzeczy, z których korzystają ludzie i maszyny. Zamiast młotka i gwoździ używają kodu oraz zestawu narzędzi, takich jak Git, i innych komponentów. 

Warto również wspomnieć o jednym z powodów, dla których wiele osób w ogóle chce pracować jako inżynierowie oprogramowania: ta praca może być dobrze płatna. Portal z ofertami pracy Glassdoor szacuje medianę całkowitego wynagrodzenia inżynierów oprogramowania na 147,000 dolarów rocznie (ostatnia weryfikacja: 28 kwietnia 2025 r.), choć rzeczywiste kwoty będą się różnić w zależności od takich czynników jak doświadczenie, lokalizacja i branża.

Przejdźmy teraz do praktycznych wskazówek i pomysłów, które pomogą ci od początku skutecznie wejść w nową rolę.

Pierwsze 30 dni

W naszym artykule poświęconym karierze w cyberbezpieczeństwie zauważyliśmy, że pierwsze 30 dni ostatecznie sprowadza się do nauki. Oznacza to wszystko — od baz kodu i narzędzi po nowe twarze i nowe miejsca. Tutaj nadal jest to prawdą, choć z pewnymi modyfikacjami.

Wskazówka nr 1: Nie wszystkie stosy technologiczne są sobie równe

Odnalezienie się w nowej roli powinno w równym stopniu polegać na poznawaniu ludzi i procesów, co na poznawaniu bazy kodu lub stosu technologicznego.

„Z mojego doświadczenia w dużych firmach wynika, że ważniejsze jest zrozumienie ludzi [i] procesów niż architektury kodu” — mówi Justin Garrison, dyrektor ds. produktu w Sidero Labs. Przed objęciem obecnej funkcji Justin pracował jako starszy rzecznik deweloperów w AWS oraz na wielu stanowiskach inżynierskich w Disney, w tym jako starszy inżynier oprogramowania. 

Wskazówka nr 2: Zrozum, jak firma generuje przychody

Aby zmaksymalizować twoją wartość, musisz zrozumieć, jak organizacja generuje swoją wartość.

„Oprócz poznania stosu technologicznego i wymagań inżynierowie powinni zrozumieć, jak firma tworzy wartość i otrzymuje za nią wynagrodzenie” — mówi nam Chris Carter, główny menedżer produktu w NetApp Instaclustr. Przed objęciem obecnej funkcji Chris rozpoczął pracę w firmie jako starszy inżynier ds. rozwoju i lider zespołu inżynierskiego. Kontynuuje:

„Bezpośrednie subskrypcje? Terenowy zespół sprzedaży i niestandardowe umowy? Odbiorcy i reklamy? Dowiedz się, jak firma mierzy swoje wyniki i jak przechodzi od kodu do kluczowego wskaźnika efektywności.”

Zbuduj to zrozumienie wcześnie. Inżynierowie oprogramowania, którzy potrafią dostrzec związek między swoim kodem a finansami firmy, raczej nie wyjdą z mody.

„Rozumiejąc, w jaki sposób sama firma mierzy swój sukces, możesz znaleźć się w pozycji umożliwiającej ci udział w jego osiąganiu i przyczynianie się do wyników finansowych” — mówi Chris.

Wskazówka nr 3: Sklonuj repozytorium, ale nie spiesz się z zatwierdzeniem zmian

Oczywiście nie możesz się doczekać utworzenia pierwszego PR-a. Potraktuj jednak bazę kodu jak żywy organizm: obserwuj jej wzorce, poznaj jej anatomię i zadawaj pytania, zanim przystąpisz do działania. Korzystaj z funkcji nawigacji po kodzie w swoim środowisku IDE, poleceń grep lub wyszukiwarki repozytorium, aby prześledzić przepływ danych i logiki w systemie.

A jeśli utkniesz? Spróbuj odtworzyć zachowanie lokalnie, a następnie prześledź je krok po kroku. Debuggery są niedoceniane, a metoda gumowej kaczuszki wciąż działa.

Porada eksperta: Przyjrzyj się niedawno scalonym PR-om, aby zrozumieć styl kodu, kulturę przeglądów oraz to, jak naprawdę wygląda ukończona praca.

Pierwsze 60 dni

Jednym z najlepszych sposobów na szybkie wdrożenie się jest zainteresowanie się nie tylko tym, co robi kod, ale także dlaczego robi to właśnie w ten sposób.

Wskazówka nr 4: Zapytaj: „Dlaczego zbudowano to właśnie w ten sposób?”

Starszy kod może wyglądać jak spaghetti, ale często w sosie kryje się coś wartościowego. Ograniczenia wynikające z wycofanej już usługi, kompromis dotyczący wydajności, wymaganie biznesowe związane z funkcją produktu, z której zrezygnowano — te decyzje mają swoją historię. Poznanie tej historii pomaga uniknąć proponowania czegoś, czego już wcześniej próbowano (i co się nie sprawdziło), a także buduje twoją wiarygodność.

Zacznij od wewnętrznej dokumentacji (nawet jeśli jest nieaktualna). Następnie poproś członka zespołu, aby wyjaśnił ci coś, co wydaje się zagmatwane, i potraktuj go jak współautora historii systemu.

„Jakie decyzje zostały zapisane w tym kodzie?” to lepsze pytanie niż „Dlaczego ten kod jest beznadziejny?”

Wskazówka nr 5: Rozpoznaj „niepisane zasady” swojego zespołu

Każda organizacja inżynieryjna je ma. Być może zespół woli dokumenty RFC w Notion od zgłoszeń w Jira, wszyscy wdrażają zmiany w czwartki albo testy jednostkowe są opcjonalne, ale testy e2e traktuje się jak świętość.

Te normy nie zawsze znajdziesz w podręczniku, ale będą kształtować twój sukces w takim samym stopniu jak umiejętności programistyczne. Obserwuj wzorce komunikacji na Slacku, analizuj komunikaty zatwierdzeń w Git i zapytaj członków zespołu, czego chcieliby dowiedzieć się przed dołączeniem do niego.

Wskazówka nr 6: Nadal spotykaj się z ludźmi i ucz się od nich

Justin z Sidero Labs twierdzi, że spotkania z ludźmi pomagają inżynierom zrozumieć, jak systemy współdziałają poza kodem: „Po zakończeniu tych spotkań znacznie łatwiej było zrozumieć, dlaczego systemy wyglądają tak, a nie inaczej”.

Przynosi to wiele dodatkowych korzyści, w tym obniża ciśnienie, gdy czytasz kod, który na pierwszy rzut oka nie wydaje się mieć sensu. Jeśli napisał go człowiek, prawdopodobnie miał powód, by napisać go w ten sposób, a wśród tych powodów mogły znaleźć się czynniki organizacyjne, presja czasu i tym podobne. 

Takie całościowe zrozumienie pomaga w budowaniu kultury zespołu i komunikacji, ale także rozwija empatię i dyplomację, gdy nadchodzi czas na poszukiwanie i proponowanie usprawnień.

Pierwsze 90 dni

Jesteś już w pełni wdrożony: „Po 90 dniach powinieneś już dobrze odnajdywać się w swojej roli i, miejmy nadzieję, być w stanie przejąć odpowiedzialność za większe zadania” — mówi Chris z NetApp Instaclustr.

Ta ostatnia faza dotyczy przede wszystkim planowania i rozpoczęcia realizacji. Od czego
możesz zacząć, aby wywrzeć rzeczywisty wpływ?

Wskazówka nr 7: Zacznij optymalizować celowo i z myślą o wpływie

Po 90 dniach nie jesteś już tylko „nowym inżynierem” — stajesz się osobą, która zaczyna wnosić istotny wkład. Oznacza to, że nadszedł czas, aby szukać możliwości poprawy sytuacji. Jest jednak pewien haczyk: nie za każdą poprawą warto podążać i nie każdy błąd warto naprawiać.

„Nie chodzi o tworzenie długiej listy rzeczy, które są zepsute” — mówi Chris. „Chodzi o zrozumienie firmy, klienta i kontekstu, a następnie wykorzystanie tej wiedzy do wskazania wartościowych sposobów na poprawę”.

Oto jak Chris i jego zespół podchodzą do tego sposobu myślenia:

• Myśl szerzej: Nie przechodź od razu do rozwiązań — zacznij od napisania jasnych zgłoszeń opisujących problem.
• Ustalaj priorytety rozsądnie: Dowiedz się, jak twój zespół ocenia wpływ, nakład pracy i pilność. Błahy błąd interfejsu użytkownika na przestarzałym ekranie? To prawdopodobnie nie jest sytuacja alarmowa.
• Stawiaj klienta na pierwszym miejscu: Zawsze pytaj: „Czy to będzie miało znaczenie dla rzeczywistego użytkownika?” Jeśli nie, odłóż to na później i idź dalej.

Gdy poznasz systemy i kulturę organizacyjną, zacznij szukać zadań o większej dźwigni — takich, które zmniejszają tarcia, usprawniają dostarczanie lub poprawiają doświadczenia klientów.

„Dzięki konsekwentnemu dostarczaniu pracy, która przybliża firmę do realizacji celów biznesowych, szybko zyskasz opinię osoby, która «rozumie, o co chodzi» — i której można powierzyć większe zadania” — mówi Chris.

Wskazówka nr 8: Dostarcz coś. Cokolwiek. Ale weź za to odpowiedzialność.

Po 90 dniach nie musisz mieć przepisanej podstawowej usługi ani samodzielnie uruchomionej nowej funkcji. Ale powinieneś móc wskazać jedną rzecz, choćby niewielką, którą dostarczyłeś i za którą odpowiadałeś od początku do końca.

Może to być:

• Poprawka błędu, która zmniejszyła problemy użytkowników
• Usprawnienie potoku CI/CD, które przyspieszyło kompilacje
• Przebudowana dokumentacja README, która pomogła kolejnej nowo zatrudnionej osobie
• Optymalizacja zaplecza, która skróciła o 50 ms czas wykonywania często używanego zapytania

Nie musi to być efektowne — musi być użyteczne. Wpływ nie polega na blichtrze, lecz na funkcjonalności.

Mantra inżyniera: „Czy w tym tygodniu ułatwiłem zespołowi pracę choćby o 1%?”

Wskazówka nr 9: Utwórz osobisty rejestr nauki

W ciągu 90 dni nie opanujesz całej bazy kodu, infrastruktury i logiki biznesowej. I dobrze. Liczy się to, co zrobisz później.

Utwórz osobisty „rejestr” umiejętności i luk w wiedzy. Zapisz:

• Obszary systemu, których wciąż nie rozumiesz
• Narzędzia lub struktury, których chcesz nauczyć się lepiej (np. Kubernetes, gRPC, Terraform)
• Dług techniczny lub nietypowe elementy, do których chcesz wrócić

Następnie ustalaj priorytet jednej rzeczy na sprint i odhaczaj ją po ukończeniu. Nie tylko uczysz się systemu — projektujesz swoją mapę rozwoju.

Zapisz się do newslettera The CTO Club, aby otrzymywać więcej poradników na pierwsze 90 dni w dowolnej roli technicznej!