Ostatnio miałem okazję zapoznać się z książką The Software Engineer’s Guidebook autorstwa Gergely’ego Orosza. Gergely prowadzi The Pragmatic Engineer newsletter. Obecnie jest to największy technologiczny newsletter na Substacku. Treści kieruje dla software engineerów i menedżerów.

W tym artykule poznasz moją opinię po przeczytaniu książki. Nie jest to jednak recenzja, a raczej moje spostrzeżenia i wnioski po lekturze. Być może pomoże Ci to podjąć decyzję czy książka jest warta Twojego czasu.

Ogólne wrażenia z lektury

Książka stara się poruszyć wszystkie istotne aspekty z punktu widzenia rozwoju kariery Software Engineera z podziałem na poszczególne etapy kariery. Począwszy od samej ścieżki kariery, przez omówienie kluczowych umiejętności i wyzwań na poszczególnych szczeblach kariery przez aspekty techniczne, takie jak dobre praktyki kodowania, typy testów czy metody monitorowania aplikacji. Jednocześnie zawiera się w nieco ponad 350 stronach. Sprawia to, że znajdziemy tu raczej odpowiedzi na pytanie „co warto wiedzieć i dlaczego” niż „jak coś zrobić”.

Książka w strukturze przypomina nieco zbiór blogpostów, gdzie artykuły podzielone są na poszczególne sekcje, które zamykają się w maksymalnie kilku stronach. W każdym z rozdziałów autor porusza kluczowe aspekty na tyle, by wiedzieć, co należy we własnym zakresie doczytać lub przećwiczyć. Przykładowo w rozdziale dotyczącym testów dowiesz się o typach testów, sposobach testowania i poznasz nieco dobrych praktyk. Brakuje moim zdaniem konkretów, które można od razu przełożyć na praktykę.

Książka jest napisana prostym językiem i czyta się ją szybko i przyjemnie. Każdy rozdział składa się ze spisu treści opisujących zagadnienia z danego rozdziału. Ze względu na objętość oraz skondensowaną formę zdecydowanie nie jest to lektura na jeden wieczór. Nie jest to jednak też tekst wymagający dokładnego wczytywania się w detale, jak to ma często miejsce w książkach poruszających aspekty czysto techniczne.

Książka w szczegółach

Na książkę składa się 25 rozdziałów podzielone na 5 części. Każda z części zahacza o kolejny szczebel kariery software engineera.

Part 1: Developer Career Fundamentals

Ta część dotyczy aspektów związanych z kierunkami i możliwościami kariery inżynierów. Ta część książki jest uniewersalna i przyda się każdemu z branży IT, niezależnie od stanowiska. Autor skupia się na takich aspektach jak:

• Miejsce pracy (Big Tech, duże i średnie firmy technologiczne, scaleupy, startupy, firmy non-tech z zapleczem IT, mikrobiznesy, sektor publiczny, sektor edukacji i praca naukowa, organizacje non-profit, agencje). Autor opisuje aspekty rozwoju kariery oraz jak różnią się w zależności od tego, gdzie pracujemy;
• Potencjalne ścieżki i drabinki rozwoju z rozróżnieniem na stanowiska inżynierskie i menedżerskie;
• Możliwości zarobku (wynagrodzenie podstawowe, bonusy, udziały) w kontekście miejsca pracy i stanowiska;
• Aspekty niezwiązane ze ścieżką kariery, takie jak: możliwości rozwoju, dopasowanie z kulturą firmy i zespołu, elastyczność czasu i miejsca pracy, work-life balance czy aspekty zdrowia fizycznego i psychicznego.
• Rozwój kariery w kontekście zmiany miejsca pracy;
• Aspekty związane z oceną swojego rozwoju i procesu performance review.

Part 2: The Competent Software Developer

Osobiście uważam tę część za najważniejszą z całej książki. To tutaj autor opisuje, co powinien wiedzieć i umieć kompetentny inżynier. Wybrałem kilka moim zdaniem najistotniejszych:

• Bądź osobą, która mówiąc kolokwialnie „dowozi tematy”. Chodzi tu głównie o to, że jeśli zobowiązaliśmy się do dowiezienia tematu X na termin Y, to robimy wszystko by być słownym i faktycznie dostarczyć rozwiązanie dobrej jakości na ustalony termin. Warto być osobą, która jest postrzegana jako ta, na której można polegać. Z dowożeniem tematów wiąże się również dowożenie tematów od A do Z. Chodzi tu o cały proces od zebrania wymagań, po przygotowanie i zaimplementowanie rozwiązania, następnie jego wdrożenie i upewnienie się, że wszystko działa zgodnie z oczekiwaniami. Autor określa takie podejście jako „Getting Things Done”;
• Koduj! Jest to chyba najbardziej oczywista rada, jaką można dać komuś, kto chce być lepszym programistą. Autor podkreśla, że nie ma tu drogi na skróty i w pełni się z tym zgadzam. Jeśli chcesz tworzyć dobry kod, musisz tworzyć dużo kodu i uczyć się na błędach. Poza kodem tworzonym w ramach pracy warto rozważyć branie udziału w wyzwaniach programistycznych. Możesz również postawić na side project, który będzie piaskownicą do testowania pomysłów i nowych technologii. Do tego zestawu warto również dorzucić umiejętność skutecznego debuggowania kodu, przeprowadzania w nim refaktoryzacji i testowania. W kontekście refaktoryzacji śmiało mogę polecić pozycję Refaktoryzacja. Ulepszanie struktury istniejącego kodu autorstwa Martina Fowlera.
• Oprócz dobrych praktyk programowania warto dobrze znać samą technologię, której używamy. Oprócz podstaw danego języka warto poznać też te mniej znane przypadki i problemy. Przykładowo w JavaScript jest tego multum. Oprócz samego języka warto poznać główne frameworki (choćby jeden) i powszechne wykorzystywane narzędzia.
• Nie mniej ważna jest biegłość w obsłudze swojego środowiska lokalnego. Obecne IDE mają multum narzędzi i usprawniaczy codziennej pracy. Warto z tego korzystać! Warto też biegle posługiwać się systemowym CLI, Gitem oraz umieć wyciągać z wykorzystywanej bazy danych potrzebne dane.

Są to dość skondensowane wnioski z tej części książki. Poruszonych zagadnień jest znacznie więcej i są opisane w bardziej wyczerpujący sposób 😉

Part III: The Well-Rounded Senior Engineer

W tej części dość mocno poszerzone zostały aspekty omówione w części II. Wyższe stanowisko oznacza też większe wymagania i oczekiwania. Tu również sporo zostały powiedziane o „Getting Things Done” ale z perspektywy seniora. Duży nacisk został tu położony na aspekt komunikacji. Jeśli coś jest zrobione, to nie ma co oczekiwać, że ktoś to zauważy sam. Jeśli jakieś zadanie jest gotowe, to poinformujmy zainteresowanych. Jeśli zauważysz przeszkody w dowiezieniu czegoś lub zrobieniu tego na czas to również warto dać znać od razu. Znane i nieznane nieznane potrafią skutecznie popsuć pierwotne terminy i założenia, ale tu konieczna jest szczerość i transparentność. Informowanie o problemach lub obsuwach na ostatnią chwilę jest słabe. Osobiście uważam, że over-communication > under-communication.

Autor porusza również zagadnienie ownershipu projektu end-to-end. Wpisuje się to w koncepcję GTD, gdzie zadanie nie kończy się po wypchnięciu zmian na mastera.

Z komunikacją wiąże się również współpraca. Wyczerpany tu został temat code review, pair programmingu, mentoringu oraz sztuki dawania feedbacku.

Dalsza część rozdziału porusza kolejne aspekty związane ściśle z wytwarzaniem oprogramowania — dług technologiczny, rozwiązywanie problemów, testy, oraz dokumentowanie kodu i decyzji architektonicznych. Osobiście uważam jednak, że reszta tego rozdziału spokojnie mogłaby się znaleźć w części II.

Part IV: The Pragmatic Tech Lead

W dalszej części książki coraz mniej uwagi poświęcone jest ściśle kodowaniu na rzecz innych zagadnień równie istotnych w dowiezieniu projektu jako całości. Uwagę poświęcono tu Project Managementowi, omówieniu kim są stakeholdersi ich typach, współpracy i komunikacji z nimi oraz zarządzaniu zespołami i ich strukturze.

Rozdział „Shipping to Production” poświęcony wdrożeniom również uważam, że lepiej pasowałby to wcześniejszej części książki. Uważam, że wiedza w nim zawarta nie jest wiedzą z zakresu Tech Leada. Znajomość teorii i praktyki wdrażania softu na produkcję oraz obsługa całego procesu z tym związana zdecydowanie przydaje się też na wcześniejszych etapach kariery.

Part V: Role-Model Staff and Principal Engineers

Tu po raz trzeci mam podobny dysonans. Część wiedzy zawartej w tej bardziej technicznej części spokojnie mogłaby być przedstawiona wcześniej. Najciekawszy dla mnie był rozdział Reliable Software Systems, gdzie omówiono aspekty związane z observability, monitoringiem i obsługą incydentów w systemie. Moim zdaniem powinien on być znacznie wcześniej, podobnie jak Engineering Practices to Iterate Quickly.

Reszta tej części książki skupia się na bardzo szerokim i długodystansowym spojrzeniu na system i projekt, co na takich stanowiskach moim zdaniem jest kluczowe.

Podsumowanie

Jeśli ktoś oczekuje rewolucyjnych treści, niedostępnych nigdzie indzie to raczej się zawiedzie. Większość informacji spokojnie można znaleźć w sieci lub w innych książkach. Jednak tutaj jest to podane w lekkostrawnej, przeredagowane formie przez osobę, która ma doświadczenie i wiedzę w tym obszarze. Jeśli podejdziesz do tej lektury bez wygórowanych oczekiwań, to myślę, że się nie zawiedziesz.

Przekaz sugerujący, że targetem tej książki są osoby na stanowiskach senior+ uważam za mylący. Moim zdaniem wiele aspektów opisanych w tej pozycji warto, by trafiła do regularów, a nawet do ambitniejszych juniorów. Nie mówię, by od razu mieli oni wdrażać wszystkie rzeczy opisane w książce. Z pewnością jednak pomoże to im w określeniu priorytetów i obszarów do polepszenia. Da im to też szerszy obraz tego, jak wygląda branża i jakie są oczekiwania właśnie od osób na wyższych stanowiskach. Uważam też, że część treści z części dedykowanych Leadom i Staff+ również może przydać się osobom na niższych stanowiskach.

Podsumowując, moim zdaniem pozycja jest ciekawa i warta przeczytania. Jednak polecam, by nie nastawiać się, że przeczytanie tej książki to będzie przełom w Twojej karierze. Daj znać, czy miałeś/aś już okazję przeczytać The Software Engineer’s Guidebook, a jeśli tak, to jakie masz przemyślenia po lekturze!

Dodatkowe linki

• The Pragmatic Engineer
• The Software Engineer’s Guidebook
• Wrapped: The Pragmatic Engineer in 2024

Zaobserwuj mnie na LinkedIn!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zaobserwuj mój profil na LinkedIn, by być na bieżąco!
Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

Chcesz docenić moją pracę? Postaw mi kawę!