Czego nauczyłem się po 1. roku pracy w zawodzie programisty?

Po pierwszym roku pracy w zawodzie na chwilę spoglądam wstecz, by uświadomić sobie, co dała mi praca i jak dzięki niej się rozwinąłem. Jest to wiedza, która różni się od wiedzy zdobytej podczas bycia developerem Wannabe. Diametralnie.

Ponad rok temu udało mi się zdobyć pierwszą pracę w zawodzie, a historię tego osiągnięcia możesz przeczytać tutaj. Był to dla mnie kamień milowy, przełom, który z oczywistych względów wpłynął na to, jak zaczęło wyglądać moje życie. Nowe zajęcie, czy nowe praca często wprowadza do życia człowieka środowisko, w którym będziemy poruszać się codziennie, spędzając podczas jej wykonywania wiele godzin tygodniowo i miesięcznie. Jesteśmy przywiązani do pracy, poświęcamy się niej i staramy być jak najefektywniejsi w tym, co robimy. To wszystko sprawia, że nabywamy nowe doświadczenia, nawyki, umiejętności i wypracowujemy nowe podejścia, które przydadzą nam się do dalszej pracy. Dziś chciałbym podzielić się tymi rzeczami. A są to rzeczy, których sami w domowym zaciszu raczej ciężko się nauczyć.

Programiści i ludzie z IT to głupcy

A przynajmniej są to ludzie dokładnie tacy sami, jak reszta społeczeństwa. Podczas swojej drogi developera Wannabe wyobrażałem sobie czynnych programistów w branży jako jednostki ponadprzeciętne, z niesamowitym zaangażowaniem i wiedzą. Wyobrażałem ich sobie jako osoby, które wiedzą tak dużo, że zazwyczaj dostarczają nowe ficzery i rzeczy automatycznie, bez większych problemów i potknięć. Oczywiście często tak jest, że tworzymy i kodzimy rzeczy, z którymi mieliśmy styczność wcześniej i dzięki temu nie sprawią nam większego problemu. Jednak bardzo często również zetkniemy się z przypadkami, z którymi nigdy wcześniej nie mieliśmy styczności albo mieliśmy, ale dany przypadek jest tak osobliwy i szczególny, że jego implementacja będzie zgoła odmienna. Co w takim przypadku? Wtedy daną rzecz trzeba prężnie przyswoić i zaimplementować. To taka nauka just-in-time.

To wszystko sprawiło, że mój pogląd na zawód programisty trochę się przeobraził i wypracowałem własną definicję programisty (oczywiście jedną z wielu):

Osoba z ponadprzeciętnymi umiejętnościami do rozwiązywania napotykanych problemów, mająca rozległą, fundamentalną wiedzę techniczną oraz charakteryzująca się wysokimi umiejętnościami interpersonalnymi. 

Do powyższej definicji podciągnąłem także jeszcze jeden aspekt, bez którego praca w zawodzie programisty raczej mija się z celem.

Praca w zespole

Przed pierwszym razem rzadko kiedy doświadczamy okazji pracy w projekcie zespołowym (niekiedy w tym aspekcie mogą w jakimś stopniu pomóc odgórne inicjatywy, takie jak koła naukowe lub internetowe grupy programistyczne). Projekty, które wtedy tworzymy są raczej projektami szufladowymi, służące do rozwijania fundamentów programowania i wiedzy technicznej. Na etapie developera Wannabe pomijamy ogromnie ważny w komercyjnej pracy aspekt współpracy, na którym właściwie większość naszych efektów będzie się opierać (nawet jako freelancerzy). Nie chodzi mi tu tylko o innych programistów pracujących nad projektem (chociaż oczywiście stanowią tutaj filar), ale także o inne grupy ludzi z branży, takie jak np.:

  • Product Ownerzy, PMowie, AMowie, founderzy, konsultanci itp.,
  • programiści na frontach (mobilki, web), backendowcy,
  • testerzy i QA,
  • designerzy,
  • użytkownicy

Każda z powyższych grup będzie wymagała charakterystycznej dla siebie formy współpracy, bez której tworzenie produktu czy projektu jest po prostu awykonalne. Przykładowo, jeżeli chodzi o współpracę z innymi programistami musimy znać fundamenty gita, dobre praktyki współpracy stricte w kodzie, code review itd. Jeżeli chodzi o grupę klienta, PO, PM, AM itd., to będziemy tutaj potrzebować przede wszystkim zdolności komunikacyjnych i miękkich, jak np. cierpliwość i umiejętność przekazywania wiedzy łopatologicznie, nietechnicznie, tak aby klient albo PM zrozumiał to, co chcemy przekazać. Szczególnym przypadkiem jest współpraca z designerami, gdzie często programiści muszą wiedzieć jak designy się tworzy, a designer, jak powstaje kod i design system od strony kodu.

Jest to wiedza, którą po prostu ciężko by było zdobyć ucząc się stricte technicznych rzeczy do szuflady. A szkoda, bo na codziennych spotkaniach jak daily, review, consulting i wiele innych spędza się w tym zawodzie ogromną ilość czasu.

Ostatni rok nauczył mnie, że praca programisty to nie tylko siedzenie w domowym czy biurowym zaciszu i klepanie kodu do zadań wyznaczonych przez kogoś w Jirze. Jest to przede wszystkim paradoksalnie praca z ludźmi i sztuka komunikacji, a umiejętność zjednywania sobie ludzi i bycie po prostu przyjaznym, otwartym i komunikatywnym człowiekiem na pewno tutaj nie zaszkodzi.

Frameworki do współpracy i masa softwaru

Scrum, Waterfall, Agile, Jira, Slack, Miro, Confluence, Salesforce, ClickUp to tylko przykłady nowych rzeczy do nauki, służących do współpracy i wynikających ze specyfikacji firmy, w której pracujemy lub projektu. O samym zwinnym podejściu Scrum pisane są całe książki. Jest to obszerny temat, który - w przypadku jeśli nigdy wcześniej nie mieliśmy z nim doświadczenia - będziemy musieli szybko przyswoić, tak żeby poruszać się dobrze podczas wytwarzania produktu dla klienta.

Jira to najbardziej prawdopodobny software służący do rozpisywania zadań, planowania, rozliczania się ze sprintów i wielu innych rzeczy w projekcie. To także jest coś, czego musimy się nauczyć w pracy, a wcześniej nie mieliśmy z tym styczności. Jest wiele przykładów takiego oprogramowania czy podejść (często nawet specyficznych i różniących się dla poszczególnych projektów), których praca w zawodzie będzie wymagać od nas nauki.

Podejście biznesowe

Jak już wspomniałem, podczas etapu Wannabe uczymy się głównie rzeczy technicznych: technologi, wzorców, dobrych praktyk, będących fundamentem do pełnienia zawodu oraz podejścia do rozwiązywania problemów. Jest to oczywiście ogromnie ważne, ale to dopiero podczas pracy poznajemy, jak ten cały technologiczny młyn przelewać na komercyjny projekt, nad którym często pieczę sprawują ludzie z biznesu i klient, któremu zawsze zależy na jak najszybszym dostarczeniu zamierzonych celów.

Niestety biznes klienta to nie piaskownica i nie można w nim robić, co nam się rzewnie podoba. Klient płaci nierzadko ogromne pieniądze za każdą godzinę naszej pracy, więc w produkcji oprogramowania wymagana jest jak największa optymalizacja środków w jego wytwarzanie. Poprzez środki mam na myśli pieniądze, czas włożony w programowanie, estymacje, research czy consulting. Wiele decyzji technicznych (i często równocześnie biznesowych) musi być podjęte w sposób najbardziej uzasadniony biznesowo. Co to tak właściwie znaczy? Już śpieszę z przykładem.

Rozwijamy produkt oparty na autorskim designie, design systemie, style guidzie i generycznych komponentach. Designer dostał wymóg od biznesu, że na konkretnym widoku użytkownik ma mieć możliwość wyboru wielu opcji z pośród konkretnej grupy dostępnych możliwości. Ponadto taki multiselect ma mieć wbudowaną wyszukiwarkę oraz paginację na scrolla. Wszystko ma być ostylowane wg istniejącego design systemu. Mając wszystkie jasno zdefiniowane wymagania możemy przystąpić do pracy. Pewnie, że tak - tyle tylko, że po drodze narodziła się masa wątpliwości.

Jak dobrze wiemy, HTML nie ma takiego wbudowanego i gotowego do użycia rozwiązania. A nawet jeśli by miał, to pewnie możliwości jego stylowania byłyby znikome (patrz select, checkbox czy radio w HTML). Stawiamy więc pytanie: jak podejść do tego problemu? Widzę dwa potencjalne rozwiązania:

  1. Stworzenie takiego generycznego komponentu totalnie od podstaw.
  2. Wykorzystanie istniejącej biblioteki, która taki multiselect implementuje i daje szerokie możliwości jego customizacji. (tylko w przypadku jeśli takowa istnieje)

Obie decyzje mają swoje plusy i minusy.

W pierwszym przypadku podejdziemy do problemu implementując je od zera, co sprawi, że zajmie nam ono znacznie więcej czasu, aniżeli jak użyjemy istniejącego gotowca. Dodatkowo, będziemy musieli przetestować taki komponent, co także wymaga od nas wiele pracy (liczonej najpewniej w godzinach). Zysk w tym przypadku to w pełni generyczny, dostosowany do projektu i jego potrzeb komponent.

W przypadku użycia gotowca zaoszczędzimy czas, jednak może się okazać, że komponent z biblioteki trzeciej po prostu nie spełni naszych oczekiwań i zostanie blokerem, a wtedy jeśli już poświęciliśmy czas na jego użycie, musimy albo z niego zrezygnować (co jest chyba najgorszym scenariuszem, ponieważ poświęciliśmy czas a zysk jest zerowy), albo zajrzeć do kodu biblioteki i rozwinąć go pod siebie. A to może być katorgą dla developera.

Spośród dwóch wyborów musimy podjąć jakąś decyzję. Ale jest jeszcze jedna opcja: współpraca na poziomie rozmów o wymaganiach biznesowych, odbywających się zanim jeszcze designer zacznie tworzyć jakiekolwiek mockupy dla generycznego multiselecta. Klient wysłuchując argumenty, dlaczego implementacja danego wymogu może być trudna i czasochłonna (a przypominam, że czas to pieniądz), może wykazać chęć na jakieś inne podejście do wymogu czy problemu. Wtedy wspólnymi siłami - podczas konsultacji z designerem i developerami może wypracować korzystniejsze rozwiązanie. Dlatego tak ważny jest aspekt komunikacji, współpracy z każdym członkiem, który pracuje nad projektem oraz bycia rzeczowym. Biznes musi się liczyć ze zdaniem developerów i ich rzeczową wiedzą. Działa to również w drugą stronę. W tym konkretnym przypadku, jeśli klient pomimo wszystkich zwróconych mu wątpliwości, obaw i uwag, zdecyduje się brnąć w pierwotne rozwiązanie, to z czystym sumieniem możemy podjąć się jego implementacji. Lecz wtedy ze świadomością, że zrobiliśmy wszystko transparentnie, a klient - także świadomie - musi się liczyć z ogromem czasu poświęconym na tą pracę.

Jeżeli chodzi o podejście biznesowe, to powyższy przykład jest wymyślony na potrzebę tego wpisu, jednak jak najbardziej możliwy, szczególnie w rozbudowanym projekcie. Praca w najróżniejszych, komercyjnych projektach zmusi nas do podejmowania wielu takich istotnych i ważnych decyzji, które w przyszłości będą miały większy lub mniejszy wpływ na to, jak będzie wyglądała praca podczas pisania kodu. Dlatego jest to tak ważne i nie ma żadnej innej możliwości na naukę tej umiejętności niż czynna praca w zawodzie.

Oprócz tego musimy przestrzegać wszelkich dobrych praktyk w kodzie, jak DRY, czy SOLID, czyli wszystko to, co sprawi, że rozwijanie kodu będzie jak najlepiej przystosowane dla nas samych, jak i innych programistów w przyszłości. O takich rzeczach musimy myśleć już na początku życia projektu i moim zdaniem jest to coś, czego także nie nawykniemy się sami, a dopiero w komercyjnym zespole.

Podsumowanie

Ostatni (a zarazem pierwszy) rok pracy w zawodzie frontendowca (programisty) nauczył mnie wiele. Poza rozwijaniem technicznych, fundamentalnych dla tego zawodu umiejętności, dostrzegłem o nim prawdę. Zdałem sobie sprawę również, ja ważna jest współpraca z innymi członkami zespołu i jak do niej podchodzić. Nauczyłem się także wielu przydatnych dla tej współpracy rzeczy, a najwartościowszą z nich jest zdecydowanie Scrum i zwinne podejście do tworzenia oprogramowania. Największą jednak wartość wyciągnąłem z doświadczenia w profesjonalnych, komercyjnych projektach prowadzonych przez profesjonalistów, które nauczyły mnie podejścia do biznesu i dlaczego praca w tym zawodzie to ciągłe trzymanie ręki na pulsie i ogromna odpowiedzialność.

© Damian Kalka 2022
Wszelkie prawa zastrzeżone