Wspomnienia z inżynierii oprogramowania

Przez cztery lata jako inżynier oprogramowania w szybko rozwijającym się startupie nauczyłem się kilku bardzo cennych lekcji, nad którymi się tutaj zastanawiam. Jest to rosnąca lista i będę ją uzupełniać.

• Praca ciągle się zmienia . Zwłaszcza, gdy firma jest niewielka. Kiedy zaczynałem w OpenGov jako 180. pracownik, nie mogłem powiedzieć, czy będę wykonywał tę samą pracę, którą wykonywałem wtedy, miesiąc później. Rzeczy szybko się zmieniają, firma stara się znaleźć swoje miejsce na rynku, a to wiąże się z ciągle zmieniającymi się wymaganiami.
• Jesteś kulturą . Kiedy firma jest mała, każda nowa rzecz, proces lub ulepszenie techniczne wprowadzone przez Ciebie może zostać przyjęte przez całą organizację inżynieryjną. (lub w niektórych przypadkach całej firmy) i może stać się częścią kultury w miarę rozwoju firmy. Moim zdaniem jest to bardzo satysfakcjonujące i nie każdy ma taką możliwość. Zawsze szukaj rzeczy, które możesz poprawić, i próbuj rozpocząć dyskusję. Nie musisz sam wykonywać całego ciężkiego podnoszenia; identyfikacja tego, co można ulepszyć, i zrobienie tego pierwszego kroku to długa droga.
• Dotknij każdej części stosu . W startupie pracującym jako inżynier role rzadko mają wyraźną granicę „rzeczy”, nad którymi możesz zostać poproszony, zwłaszcza jako młodszy inżynier. Możesz spodziewać się pracy na froncie, backendzie, infrastrukturze, bazach danych i wielu innych. Od przygotowania rejestru JIRA dla funkcji po wdrożenie powiązanego kodu — wszystko jest częścią pracy.
• Rzeczy się psują. Wdrażasz fragment kodu, który psuje system lub nie zachowuje się tak, jak w środowisku przedprodukcyjnym. Czasami infrastruktura się psuje i nie można w ogóle niczego wdrożyć! To wszystko są możliwości uczenia się i doskonalenia. W opengov, mimo że mieliśmy dedykowany zespół devops zajmujący się takimi problemami, jako inżynierowie byliśmy również narażeni na operacyjną stronę inżynierii oprogramowania.
• Dokumentacja jest ważna. Ponieważ jesteśmy zajęci pisaniem i dostarczaniem kodu, dokumentacja ma tendencję do schodzenia na drugi plan. Warto poświęcić trochę czasu, w regularnym tempie, na tworzenie nowej dokumentacji i aktualizowanie istniejących. Dobra dokumentacja jest moim zdaniem oznaką zespołu osiągającego wysokie wyniki. Gdy ludzie przychodzą i odchodzą, szczególnie w przypadku startupów, dokumentacja pomaga wprowadzać nowych ludzi i rozpowszechniać wiedzę o różnych systemach i domenach wśród istniejących członków zespołu.
• Komunikacja jest trudna . Aby uzyskać poparcie różnych interesariuszy dla projektu technicznego, musisz wyjaśnić, w jaki sposób przynosi on wartość klientowi. Chcesz spędzić kilka następnych sprintów na refaktoryzacji zarządzania stanem aplikacji? Cóż, przygotuj się na wyjaśnienie produktowi lub swojemu EM (który z kolei będzie musiał wyjaśnić to przełożonym), dlaczego jest to ważne. Czasami istnieje bezpośrednia korzyść dla użytkownika końcowego, na przykład szybsze ładowanie aplikacji, lepszy UX itp. Innym razem korzyścią byłoby lepsze doświadczenie programisty, co przyspieszyłoby rozwój funkcji w przyszłości. Cokolwiek by to nie było, prawidłowe sformułowanie tej narracji może być trudne i nawet jeśli nie jesteś osobą zaangażowaną w te negocjacje, sugeruję zawsze oddalanie i patrzenie na swoją pracę z obiektywu użytkownika.
• Znalezienie odpowiedniego mentora. Podobnie jak w innych dyscyplinach, mentoring może być przełomem dla młodego inżyniera. Mentor nie musi trzymać cię za rękę, aby cię czegoś nauczyć, ale raczej popchnąć cię we właściwym kierunku. Mają ogromne doświadczenie w tej dziedzinie, są doświadczonymi profesjonalistami i chętnie podzielą się z Tobą swoją wiedzą. Skontaktuj się z osobami w swoim zespole/firmie, na które patrzysz, i omów problem, który rozwiązujesz, dokument techniczny, który piszesz, lub cokolwiek, co do czego potrzebujesz wskazówek.