1 lutego 2022 roku zmieniłem mojego głównego zleceniodawcę. Po nieco ponad 3 latach w jednym startupie, przeszedłem do innego (wcześniej 6 lat spędziłem w software house, a kolejne 3 w korporacji). Zapewne wiele można by napisać na temat organizacji pracy, zarządzania projektem, czy zespołem. Nie mnie jednak to oceniać i nie mam zamiaru tu tego robić. Chciałbym raczej podzielić się dwoma kluczowymi spostrzeżeniami, które przyszły mi do głowy pod koniec pobytu w poprzedniej firmie.

Greenfield vs. legacy code refactoring

Kiedy jako młody i nieopierzony junior dołącza się do firmy programistycznej, to chce się programować tylko i wyłącznie świeżutkie projekty. Od zera, na czysto, bez oglądania się za siebie. Wiem, bo sam tak miałem. Jednak statystycznie rzecz biorąc, większość czasu spędza się wokół kodu już wcześniej napisanego przez kogoś innego. Legacy code, jak można go nazwać, jest zazwyczaj złem koniecznym z punktu widzenia juniora. Po latach programistycznego dojrzewania zaczynamy zdawać sobie sprawę, że od zastanego kodu nie uciekniemy. Finalnie zaprzyjaźniamy się z nim i zaczynamy dostrzegać, że może on stanowić pouczające wyzwanie. Szczególnie, gdy wcześniej startował jako greenfield i był rozwijany przez nieopierzonych juniorów 🙂

I właśnie w takiej sytuacji znalazłem się około 3 lata temu. Dołączyłem, jako najstarszy stażem, do startupu będącego w zaawansowanej fazie rozwoju i używanego produkcyjnie, ale napisanego po partyzancku. Oprogramowanie działało, było wykorzystywane tu i ówdzie, ale w kodzie panował niemały chaos. Z biegiem czasu zdałem sobie sprawę, że wyprowadzanie takiego kodu „na prostą” sprawia mi o wiele więcej frajdy niż pisanie zupełnie od zera. Trzeba bowiem zwrócić uwagę na więcej aspektów. Na przykład na to, czy ktoś używa danej funkcjonalności produkcyjnie, czy dany fragment jest na pewno potrzebny, dlaczego każdy serwis napisany jest w zupełnie innym stylu, czy też co autor miał na myśli 🙂

Na szczęście przez całe 3 lata, oprócz zadań związanych z rozwijaniem i dodawaniem nowych funkcjonalności, miałem też wolną rękę na porządkowanie zastanego kodu i na doprowadzenie go do jakiegoś spójnego kształtu, co IMHO udało się osiągnąć. Dzięki temu osoby przejmujące projekt po mnie nie powinny mieć problemu z dalszym jego rozwojem.

Staraj się być najlepszym, ale nie niezastąpionym

W startupie, z którego odszedłem, byłem kimś na kształt głównego programisty oraz lidera zespołu w swoim projekcie. Z obydwu obowiązków, a w szczególności z tego programistycznego, starałem się wywiązywać najlepiej jak potrafiłem. Jednocześnie nigdy nie starałem się ukrywać mojej wiedzy i robić z siebie osoby niezastąpionej. Wręcz przeciwnie. Dzieliłem się z najbliższymi współpracownikami wszystkim co dzieje się w projekcie, a całą wiedzę na ten temat spisywałem w dokumentacji, czy używanym przez nas managerze zadań. Tak, żeby kolejne pokolenia mogły w projekt wejść z marszu.

Takie podejście okazało się zbawienne podczas „okresu wypowiedzenia”. Dzięki przekazywaniu wiedzy na bieżąco, miałem możliwość zwinąć się dosłownie w kilka dni, a moi koledzy z zespołu płynnie przejęli wszystkie moje obowiązki.

Gorąco polecam spróbować. Sam na pewno będę stosował podobne procedury również w przyszłości.

Nie tylko startup

Tak naprawdę nie ma znaczenia fakt, że pracowałem w startupie. Powyższe wnioski można było wyciągnąć w dowolnym momencie kariery. Ja wyciągnąłem je akurat teraz.

Jestem ciekaw, czy tego typu przemyślenia pojawiły się ostatnio również w Twojej głowie. Jeżeli tak, to komentarze poniżej są idealnym miejscem na podzielenie się swoimi spostrzeżeniami. Zapraszam 🙂

Bądź na bieżąco!

Podobają Ci się treści publikowane na moim blogu? Nie chcesz niczego pominąć? Zachęcam Cię do subskrybowania kanału RSS, polubienia fanpage na Facebooku, zapisania się na listę mailingową:

Dołączając do newslettera #NoweRozdanie2 otrzymasz dostęp do dodatkowych materiałów:

  • PDF: „Jednoosobowa działalność gospodarcza krok po kroku” (do artykułu)
  • PDF: „FAQ: Jak pracuje się dla Roche/Sii?” (do artykułu)
  • PDF: „Jak zmniejszyć prawdopodobieństwo wystąpienia kontroli i co zrobić kiedy urzędnik zapuka do Twoich drzwi?” (do artykułu)

Powyższe dane są przechowywane w systemie Mailchimp i nie są udostępniane nikomu innemu. Więcej szczegółów znajdziesz na stronie polityki prywatności.

lub śledzenia mnie na Twitterze. Generalnie polecam wykonanie wszystkich tych czynności, bo często zdarza się tak, że daną treść wrzucam tylko w jedno miejsce. Zawsze możesz zrobić to na próbę, a jeśli Ci się nie spodoba – zrezygnować :)

Dołącz do grup na Facebooku

Chcesz więcej? W takim razie zapraszam Cię do dołączenia do powiązanych grup na Facebooku, gdzie znajdziesz dodatkowe informacje na poruszane tutaj tematy, możesz podzielić się własnymi doświadczeniami i przemyśleniami, a przede wszystkim poznasz ludzi interesujących się tą samą tematyką co Ty.

W grupie Programista Na Swoim znajdziesz wiele doświadczonych osób chętnych do porozmawiania na tematy krążące wokół samozatrudnienia i prowadzenia programistycznej działalności gospodarczej. Vademecum Juniora przeznaczone jest zaś do wymiany wiedzy i doświadczeń na temat życia, kariery i problemów (niekoniecznie młodego) programisty.

Wesprzyj mnie

Jeżeli znalezione tutaj treści sprawiły, że masz ochotę wesprzeć moją działalność online, to zobacz na ile różnych sposobów możesz to zrobić. Niezależnie od tego co wybierzesz, będę Ci za to ogromnie wdzięczny.

Postaw mi kawę na buycoffee.to

Na wsparciu możesz także samemu zyskać. Wystarczy, że rzucisz okiem na listę różnych narzędzi, które używam i polecam. Decydując się na skorzystanie z któregokolwiek linku referencyjnego otrzymasz bonus również dla siebie.

Picture Credits