Od przeciętnego programisty do szczęśliwego inżyniera oprogramowania

O rozwoju osobistym słów kilka.

Dlaczego tytuł inżyniera stracił tak dużo na znaczeniu? Sami jesteśmy sobie winni. Stajemy się siłą robocza XXI wieku. Nowoczesną linią produkcyjną. Dzisiaj dowiesz się co zrobić, aby to zmienić.


Moim celem jest pokazanie, jak można być szczęśliwym w zawodzie programisty. Nie ważne czy jesteś juniorem, czy seniorem. Chce pokazać, na co zwracać uwagę w pracy, czego się uczyć, jak się rozwijać. Na co uważać i jakich ludzi unikać. Jak znaleźć pracę i się w niej spełniać. Jak nie pracować nadgodzin i unikać stresu. Jak mieć także życie po pracy i jak to wszystko może prowadzić do pełnego i szczęśliwego życia.

Podstawą jest nieustanny rozwój osobisty. Niestety, ale w tej branży inaczej się nie da. Technologie, z którymi pracujemy, są w ciągłym rozwoju. Nowe wersje języków programowania, bibliotek i frameworków (prawie) zawsze przynoszą nowe możliwości, większą wydajność, oraz usprawniają nasza prace. Dzięki temu możemy tworzyć jeszcze więcej, lepiej, szybciej, przyjemniej. Jako pracodawca, zawsze faworyzuj osoby, które chcą się uczyć i przyznają się, że czegoś nie znają, ale chętnie to nadrobią. Unikaj natomiast osób, które twierdzą, że wszystko już wiedzą. Będziesz miał z nimi tylko problemy.

Teraz uwaga. Rozwój dobrego programisty to nie tylko rozwój w zakresie umiejętności technicznych(!). Oczywiście, wiedza i doświadczenie techniczne są bardzo ważne, ale zastanówmy się:

  • co z tego, że zbudowałeś milion funkcjonalności w produkcie, którego nikt nie potrzebuje?
  • co z tego, że twój backend jest najszybszy, jeżeli interfejs użytkownika jest nieintuicyjny?
  • co z tego, że używasz najnowszych technologii, jeżeli jednocześnie tracisz zdrowie i przyjaciół przez nerwy i nadgodziny spędzone przy projekcie?
  • co z tego, że znasz całą specyfikację ECMAScript na pamięć, jeżeli twoi koledzy z zespołu nie są w stanie się z tobą dogadać?
  • co z tego, że skonfigurowany przez ciebie serwer potrafi uciągnąć milion odsłon na sekundę, jeżeli twoja firma nie wie skąd wypłacić ci kolejną pensję?

Powyższe punkty pokazują przykłady błędów w kilku podstawowych dziedzinach powiązanych z zawodem programisty, mianowicie: budowanie produktu, interfejs i doświadczenie użytkownika (czyli UI i UX), zarządzanie projektem, tak zwane umiejętności miękkie oraz budowanie biznesu. Ta lista nie jest wyczerpująca, ale od czegoś trzeba zacząć. Rozwinę ją w kolejnym wpisie, gdzie znajdziesz czego i jak się uczyć.

Więc jeżeli powyższe tematy są powiązane z twoim zawodem, dobrze by było, abyś (przynajmniej trochę) się w nich orientował.

Po co nam ta cała wiedza? Zapewniam Cię, zmieni ona wiele w twoim życiu. Zaczniesz nie tylko myśleć co masz robić w pracy, ale zaczniesz się zastanawiać dlaczego. Zaczniesz zadawać (czasem trudne) pytania, nie będziesz akceptował głupot narzucanych ci z góry. Zaczniesz widzieć dużo więcej w swoim otoczeniu. Będziesz dostarczał rozwiązań, zamiast być „pracownikiem linii produkcyjnej oprogramowania”. Następstwem tego będzie fakt, że zaczniesz wykonywać swoja prace lepiej i bardziej świadomie. Zwiększy to twoja wartość i będziesz się czuł lepiej. Także twój pracodawca zacznie cię bardziej doceniać i powierzać ci coraz ambitniejsze zadania.

Programista to tak naprawdę inżynier oprogramowania. Inżynier to kiedyś był poważny tytuł. Dlaczego stracił tak dużo na znaczeniu? Sami jesteśmy sobie winni. Stajemy się siłą robocza XXI wieku. Nowoczesną linią produkcyjną. Siedzimy w piwnicach i klepiemy tysiące linii nikomu niepotrzebnego kodu, tylko dlatego, że tak nam powiedziano. Prawda jest taka, że klienci i pracodawcy powinni przychodzić do nas z problemem, a nie z rozwiązaniem.

Zróbmy małą dygresję i pomyślmy o zawodzie inżyniera budowlanego. Poznajcie Radosława. Ma on za zadanie zbudowanie mostu. Od początku wie, które dwa brzegi rzeki ma połączyć oraz jakie natężenie ruchu pojazdów musi udźwignąć. Robi projekt pod konkretne założenia. Po fazie projektowej następuje budowa według planów. Zakładam, że pewne usprawnienia mogą nastąpić już w fazie budowy, ale podstawy i założenia się nie zmieniają.

Teraz wyobraźmy sobie, metaforycznie, takie samo zadanie, ale postawione przed inżynierem oprogramowania. Zaczynamy projekt od budowy mostu łączącego brzegi rzeki. Spoko, łatwe, zaczynamy kodować. W trakcie projektu okazuje się, że rzeka ma 8 brzegów, a most przy okazji powinien też lewitować („no co ty, przecież to nie takie trudne”). Aha, i tak, żeby mógł zmieniać kolor pod każdego, kto nim przejeżdża, można było w nim zamieszkać, a liczba pasów dla samochodów skalowała się do aktualnego natężenia ruchu. No i oczywiście, czas na realizację projektu jest nadal taki sam, jak przy „tradycyjnym” moście. Tak w przełożeniu na budownictwo wyglądają zadania stawiane przed programistami.

Teraz patrz: od ciebie i twojej wiedzy będzie zależało, czy ten most powstanie. Co jest tak naprawdę najważniejsze w tym projekcie? Co się składa na tak zwane MVP (Minimum Viable Product). Podpowiem ci, najważniejsze, że nasz użytkownik będzie mógł się przedostać z jednego brzegu na drugi. Okazuje się, że brzegów jest więcej. To akurat nasza wina, bo nie zrobiliśmy odpowiednich badań i przygotowań przed startem projektu. Ale czy naprawdę musi lewitować? Może to wymysł jakiegoś szalonego managera, który i tak nie zna potrzeb naszych użytkowników? Czy naprawdę w pierwszej wersji musi się skalować, jeżeli mamy tylko 100 użytkowników na naszej platformie? Czy nie możemy wybrać jednego koloru, który spodoba się większości? Opcja mieszkalna to raczej kompletnie inny produkt albo moduł, więc pogadamy o tym przy następnym projekcie.

Widzisz, do czego zmierzam? Programista-robol rzuci się na powyższy projekt bez zastanowienia. Będzie kodował w dzień, w nocy i w weekend, zbuduje wszystko, co szefowie na niego rzucą. Rezultat? Programista będzie zmęczony i nieszczęśliwy, produkt będzie marnej jakości i pełen błędów, a użytkownicy i tak nie będą w stanie z niego skorzystać i sfrustrowani zainteresują się produktem konkurencji. Straci więc i biznes.

Dlaczego jestem przekonany, że tak będzie? W projekcie są zawsze trzy zmienne: czas, ludzie (choć niektórzy nazywają nas zasobami) oraz zakres prac. Zasada jest prosta: nie możesz zmienić jednej z nich bez modyfikacji pozostałych. Więc na przykład, nie możesz zwiększać zakresu prac bez zwiększania liczby ludzi lub czasu realizacji. I tak na marginesie, nie licz, że 10 programistów zrobi w jeden dzień tę samą pracę co 1 programista w 10 dni.

I teraz dochodzimy do „przełożonych-idiotów”, z którymi większość z nas miała zapewne do czynienia. Oczywiście nie chcę tutaj nikomu ubliżać. Przez mocne słowa chcę zwrócić uwagę na problemy, z jakimi spotykamy się w naszej branży. Ponieważ to oni, przez ich brak zrozumienia problemu, produktu, użytkowników, technologii, ludzi lub biznesu potrafią zrujnować projekt, zespół albo nawet całą firmę. Byłem tam, widziałem, pracowałem z nimi. Pozwól, że przedstawię ci kilka przykładów:

  • W pewnej małej agencji kreatywnej szef, aby dostać bardzo dobrze płatne zlecenia od prestiżowego klienta, proponował nierealne terminy realizacji (pierwszy błąd). Wcześniej ta agencja całkiem dobrze prosperowała, ale nigdy nie miała tak wielkiego klienta. Więc chodziło tu o pieniądze i pokazanie się. Design oraz zakres prac przychodził z góry i nie podlegał dyskusji (drugi błąd). Naszym zadaniem było wcielenie tego w życie. Oczywiście miało to działać we wszystkich przeglądarkach, responsive, mobile itd. Aby zwiększyć motywację, szef propagował hasło „work-life integration”. Czyli, według mojej interpretacji: „po co ci życie prywatne, jeżeli masz pracę”? A w praktyce wyglądało to tak, że jak wychodziłem rano z domu to nie wiedziałem, kiedy do niego wrócę. Ucierpiały moje relacje ze znajomymi i dziewczyną. Skończyło się to tak, że przy drugim projekcie (bo pierwszy jakoś przetrwaliśmy) dwie osoby z sześciu zwolniły się z dnia na dzień. Nie wytrzymaliśmy tego psychicznie, co mam nadzieję, jest zrozumiałe. Czy warto było stracić 1/3 zespołu, żeby podlizać się pewnej korporacji?

  • W dużej firmie e-commerce szefowie mieli tendencję do stwarzania presji. Przecież wtedy ludzie pracują lepiej, nieprawdaż? Jeżeli nikt nie patrzy nam na ręce i nie pyta po kilka razy dziennie czy już zrobione, to przecież my programiści-obiboki tylko pijemy kawę i przeglądamy Twitter’a. Co kilka tygodni zdarzały się sytuacje w takim stylu: “Właśnie dostałem informację, musimy to zmienić, teraz, zaraz, przecież dopiero 17, dasz radę”. Więc ludzie zostawali po godzinach (oczywiście niepłatnych), żeby wykonać tę super ważną zmianę w funkcjonalności naszego sklepu internetowego. Ale co najgorsze, ta zmiana nigdy nie wychodziła na produkcje tego samego dnia. Presja była tworzona dla samej presji. A tej zmiany tak naprawdę nikt nie potrzebował. Wynikała ona tylko z bałaganu, jaki panował „na górze”. Gdzie każdy szef miał kilku szefów nad i pod sobą, i tak sobie szefowali, że nikt nic nie wiedział. Więcej idiotów w jednym miejscu jeszcze w swojej karierze nie widziałem. Efekt: mało kto, z naprawdę dobrych ludzi, jakich tam spotkałem, wytrzymywał dłużej niż rok. W około 100-osobowym dziale technicznym, weteranem nazywana była osoba już z 2-letnim stażem.

  • W tej samej firmie, co powyżej, mój zespół kończył pracę przy pewnym projekcie. Z naszego punktu widzenia byliśmy gotowi. Chcieliśmy udostępnić rezultat naszej pracy naszym użytkownikom jak najszybciej. Niestety, managerowie nie mogli się zdecydować, czy to jest na pewno TO. W ostatnim momencie zaczęli wymyślać, co by tu jeszcze zmienić lub dopasować. Rozmowy toczyły się o tak istotne rzeczy, jak „czy obrazek powinien być 10 pikseli mniejszy lub większy”. Efekt? Ze zdrowego projektu, w którym ludzie byli dumni z tego, co osiągnęli, projekt przerodził się w porażkę, a zespół stracił całą motywację.

Zastanów się teraz nad tym. Na pewno już nie jednego takiego „idiotę” spotkałeś. Albo może sam jesteś jednym z nich. Na szczęście nigdy nie jest za późno na zmiany. Możesz edukować siebie, swoich współpracowników i przełożonych albo, w ostateczności, możesz po prostu zmienić pracę, albo z tą całą wiedzą założyć własną firmę.

Ważne! Bądź spokojny, obserwuj, przeanalizuj fakty kilka razy, bo możesz się też mylić w swoich osądach. Nie wyrażaj swojej opinii zbyt szybko, bo możesz sam wyjść na idiotę. Ale jeżeli jesteś całkowicie pewien, że coś jest nie tak, to musisz działać. Porozmawiaj, zaproponuj zmiany, przedstaw im swoją wersję. Może oni nauczą się czegoś od ciebie, a może ty nauczysz się od nich. Jeżeli jednak widzisz brak zrozumienia, a jesteś pewien swojej racji, to idź i szukaj innej pracy. Szkoda twojego życia i zdrowia na pracę z idiotami.

W kolejnych wpisach planuję poruszać więcej tematów związanych ze szczęśliwym i spełnionym życiem programisty. Zachęcam Cię też do sprawdzenia mojego profilu na Twitterze.

Do następnego!


READ THIS NEXT:

Short story about looking for a new place to live

I don’t like writing a lot about technical things. I mean if you are smart developer you will find a lot resources with solutions for your everyday tech problems and I don’t feel like I want to build...