🎯 7 rzeczy, które sprawią, że jako programista będziesz niezastąpiony

Niezastąpiony programista? Czyli jaki? Czy chodzi o takiego programistę, który dokładnie zna daną aplikację i wiedzy tej nie odda … i będzie niezastąpiony. Czy może o coś dużo ważniejszego, bardziej holistycznego? Coś, co sprawi, że Ty, jako programista, będziesz wnosił mnóstwo wartości do projektu?

Pogadajmy. Lecimy!

Wprowadzenie

Tytuł artykułu, gdzie występuje niezastąpiony programista, jest dość przewrotny. Dokładnie taki miał być, bo porusza ważną kwestię. I warto o niej szczerze porozmawiać.

Bycie niezastąpionym np. w legacy projekcie to nie zawsze szczęśliwe rozwiązanie. Choć niektórzy lubią taki wariant, moim zdaniem jednak ma on wiele negatywnych czynników w przyszłości.

Bycie natomiast pierwszym wyborem w nowych projektach, gdy ktoś lubi wyzwania i to jego biznes, sprzedaż, etc. ciśnie, żeby dana osoba była na pokładzie w nowym przedsięwzięciu – no to chyba fajna perspektywa.

Super jest też bycie programistą, do którego zgłaszają się ludzie, gdy potrzebują rozwiązać jakiś problem biznesowy, szukają rady, jak coś rozwiązać, czy też, czy w ogóle się da dane zagadnienie ruszyć w oprogramowaniu.

Niezastąpiony programista – kontekst

Context is King!
Z moich prezentacji o Domain-Driven Design 🙂

Żebyśmy wszyscy mieli jasny kontekst, to tutaj ustalmy między sobą, że bycie niezastąpionym postrzegamy tutaj w następujący sposób. Czyli, nasza sprzedaż, biznes, etc. widzi w nas specjalistów, dzięki którem projekt idzie sprawnie do przodu. A my jesteśmy programistami wychodzącymi poza stereotypowe myślenie o zamkniętym, mrukliwym sofware developerze i dążymy do sukcesu projektu, a nie tylko do hiper jakości kodu. Tak zupełnie na marginesie, hiper jakość kodu, czy też „geniusz” w nim wyrażony, to często oznaka, że nikt inny go nie zrozumie … także, no wiesz, będzie też o tym kawałek dalej w artykule.

My, jako developerzy, bardzo często lubimy jednak, gdy inni wiedzą, że mogą na nas polegać, że chcą nas w swoich projektach i że po prostu jesteśmy dla innych synonimem dobrej jakości oprogramowania.

Takie przez innych innych nie jest kwestią doskonałych umiejętności kodowania. Kodowanie to za mało. Zresztą nasz biznes na kodowaniu się nie zna. Ma działać, tak jak powinno i się nie wykładać.

To trochę tak, jak ze sprzedażą. Możesz mieć świetny produkt, ale jak nikt o nim nie wie, nie widzi wartości z jego stosowania, to sorry, produkt nie odniesie sukcesu.

I tak też jest z karierą programistów. Jest to dużo bardziej złożony proces, który dotyczy wielu aspektów naszego „bycia” w danej organizacji. Być świetnym programistą to nie tylko pisanie jakościowych milionów linijek kodu. To dużo więcej.

Niektórzy się oburzą, że jak to, przecież jako programiści nie będziemy zajmować się sprzedażą naszych umiejętności biznesowi. Otóż, moi Drodzy, a właśnie powinniście! Firmy nie tworzą oprogramowania, bo lubią oprogramowanie. Tworzą je na potrzeby sprzedawanych usług i produktów. A nam programistom, powinno zależeć na tym, żeby cały ekosystem funkcjonowała jak najlepiej. Bo jesteśmy jego częścią.

Dalej przedstawiam kilka rad, dzięki którym staniesz się niezastąpionym programistą w danej organizacji. Rady te uczynią Cię również po prostu lepszym wytwórcą oprogramowania niż statystyczna większość. To takie schodki do wejścia na poziom wyżej.

1. Dokładnie zrozum, dlaczego ten projekt powstaje

Niby oczywiste, prawda? No pewnie, że … nie! Wiesz, jak często developerzy wiedzą dlaczego dany projekt jest realizowany, jaki jest jego cel? Powiem Ci zupełnie szczerze, że z moich obserwacji wynika, że niestety rzadko 😔

I teraz chwila o konsekwencjach tej niewiedzy. Wyobraź sobie razem ze mną teraz taki oto zespół. Trzech juniorów, jeden senior, który zajmuje się też architekturą. I wpada temat, zróbmy katalog produktów dla firmy (niech to będzie branża spożywcza, a co tam).

Zespół, jak to zespół, no czytać dokumentacji nie będzie, a spotkania o celach aplikacji są przecież nudne i nie dla nich …

Zafascynowany DDD zespół już dzierga genialną architekturę, tu agregat, tam value object, serwis domenowy, nawet zdarzenia domenowe, może dołożą też Event Sourcing …

Wow, brzmi jak fantastyczny projekt, takie cuda, ekstra, super rozwiązania.

Tylko …

Product Owner ma na zrobienie projektu dwa miesiące i ma on generalnie po prostu zebrać informacje opisowe o wszystkich produktach w firmie. Serio, tutaj domena (problemu) jest płyciutka …

Czy teraz widzisz, jak ważne jest zrozumienie, dlaczego robisz dany projekt i jakie są jego cele? No właśnie! Na podstawie takich informacji Ty, jako członek zespołu, możesz dopasować odpowiednią architekturę (rzuć okiem na drivery architektoniczne) i narzędzia do danego problemu.

A w tym konkretnym przypadku, płytka domena, totalny CRUD. JHipster na przykład i tyle.

A co jeśli takich danych o celach projektu nie masz? Dwa warianty.

Jeśli pracujesz w organizacji, która robi wewnętrznie projekt – no … popytaj na około, pochodź, serio, po prostu jest to wiedza leżąca niedaleko. Wystarczy po nią sięgnąć.

Jeśli natomiast pracujesz w organizacji, która otrzymała zlecenie na realizację projektu i nie wiesz, jaki jest cel tego projektu. Pytaj sprzedaż, account managera – bez tych danych nigdy nie będziecie produkować aplikacji spełniających realne potrzeby klientów. Te magiczne need behind the need. A może to czas zmienić organizację, na taką, która zwraca uwagę na sukces swój, ale i klienta?

A jeśli możesz w tym aspekcie pomóc, to naucz się definiować jasno cele. Trochę więcej na ten temat możesz przeczytać tutaj: 7 nawyków sukcesu projektu. Część 1 – cel typu SMART.

2. Rozmawiaj z klientem

Weźmy taką scenkę rodzajową. Popularny gdzieniegdzie model – z klientem rozmawia się przez Project Managera. Taki model komunikacji o niezwykłym braku efektywności, zwany również proxy-manager.

I teraz Ty, jako developer, musisz się czegoś dowiedzieć od klienta. Macie deadline. Musi działać integracja z magazynem. Ale nie działa, bo API jest inne niż dokumentacja dostarczona dokładnie trzy miesiące wcześniej (punkt w planie projektu zrealizowany perfekcyjne 😊). A tu Twój manager jest na L4 – taki psikus. No a Ty nie wiesz nawet z kim się kontaktować, bo model organizacji komunikacji tego nie przewiduje.

No, nie jest dobrze. Zgodzisz się, prawda? Pomijając absurdalność niektórych modeli komunikacyjnych, to w naszej branży komunikacja ma znaczenie. I to dużo większe niż się wydaje. Developerzy nie muszą wiedzieć absolutnie wszystkiego o biznesowych aspektach projektu, ale muszą umieć komunikować się z klientem. I to jest bardzo proste. Czasem parę minut rozmowy na chat, hangout, czy skype rozwiązuje wszystkie wątpliwości.

Dlaczego tak często developerzy nie chcą rozmawiać z klientem?

Często pojawia się po prostu strach przed rozmową. Ten strach ma zwykle wielkie oczy i początek rozmowy sprawia, że zaraz go nie ma. Znasz ten wykład Jacka Walkiewicza z TEDxWSB? Jeśli nie, to zdecydowanie polecam go przesłuchać. Fragment od 15 min 30 s jest dokładnie dla Ciebie.

Dlatego nie bój się komunikacji z klientem. Szansa, że dzięki temu dany projekt będzie lepszy jest dużo większa.

Ja też na początku swojej kariery uważałem, że jak są wymagania, to wiadomo, co trzeba zrobić.

Nic bardziej mylnego. Wymagania powstają w czasie X, czasem ten X oznacza pół roku wcześniej. A przetargi potrafią ciągnąć się wiele, wiele miesięcy. Środowisko biznesowe zmienia się cały czas. Wymagania również. Trzeba o tym pamiętać i cały czas weryfikować ich wspólne zrozumienie z klientem. I to też jest Twoja rola, jeśli chcesz być kimś więcej, niż zwykłym klepaczem kodu.

3. Twój głos na spotkaniu też się liczy

Znam wielu programistów. I osobiście nie znam chyba ani jednego, który nie ma swojego własnego zdania na temat realizowanego projektu.

Gdy ktoś pracuje roku, 5, 10 lat przy danym produkcie IT, to tak naprawdę jest prawdopodobnie osobą dobrze znającą w firmie dany fragment biznesu. To dokładnie ta osoba wie, dlaczego jakaś integracja została zrobiona w ten sposób, dlaczego fragment danego kodu jest taki, a nie inny.

Twoja wiedza i doświadczenie dają olbrzymią wartość. Ale tylko wtedy, gdy się nimi podzielisz.

Dlatego staraj się aktywnie uczestniczyć w spotkaniu. Dodaj coś od siebie, bo może to pozwoli wszystkim spojrzeć z innej perspektywy, której wcześniej nie dostrzegali.

I nie dotyczy to tylko spotkań projektowych. Bo spotkań wszelakich w pracy będziesz miał zapewne mnóstwo. Czy to o procesie wytwarzani oprogramowania, o szkoleniach, etc.

4. Współtwórz wymagania, nie bądź tylko ich biernym odbiorcą

Ustalmy, bo czasem to bywa nieoczywiste. Współtworzenie wymagań przez programistów nie polega tylko i wyłącznie na krytykowaniu User Story i wytykaniu niejednoznaczności.

Współtworzenie wymagań polega na tym, że i Ty angażujesz się w proces ich pozyskiwania, zapisywania i ewaluacji. Ty też możesz np. podczas udoskonalania backlogu (ang. backlog refinement) zadać ważne pytanie, doszczegółowić jakiś element.

Wydaje Ci się, że wymaganie jest bez sensu, niespójne, generalnie od czapy. A umiesz powiedzieć to tak, żeby Twój Product Owner, nie poczuł się krytykowany, ale żebyście razem mogli rozwiązać taki problem?

Naucz się budować złote mosty. Pozwól drugiej stronie wyjść z tej sytuacji z twarzą. Pytaj, nie krytykuj. Po pierwsze, w tej sytuacji możesz odkryć coś nowego. Po drugie, czasem po prostu da się takie wymaganie zmienić. I projekt będzie lepszy.

Ile razy po spotkaniu słyszałeś: a te wymagania są bez sensu, tego nie da się tak zrobić? Spraw, żeby takich obiekcji było mniej. I uwierz mi, nie tylko developerzy czują, że spotkanie nie szło, wszyscy uczestnicy to wiedzą.

Dlatego staraj się pomagać w tworzeniu wymagań.

A jeśli nie wiesz, jak tworzyć wymagania, których nie powstydziłby się nasz niezastąpiony programista to tutaj znajdziesz garść informacji na ten temat: User Story – przewodnik

5. Koduj jasno, nie genialnie

Ustalmy jedno. W większości przypadków nie programujemy aplikacji dla misji kosmicznych NASA, czy SpaceX.

Nasz kod biznesowy nie musi korzystać z wszystkich możliwych optymalizacji, jakie wymyślono. Genialny kod to często kod, którego nie zrozumieją Twoi koledzy z zespołu. Nie każdy musi znać wszystkie warianty odwracania listy, ani ciut lepszego algorytmu do sprawdzania kodów kreskowych w bazie danych na podstawie hash (taki przykład).

Twój kod powinien być przede wszystkim czytelny. A to oznacza, że powinien jasno pokazywać swoje intencje. Co ma być zrobione, jak to jest zrobione i jaki ma być wynik.

Ja zawsze, jak mam wątpliwości, przypominam sobie ~~kod~~ treść rozwiązań zadań z fizyki w liceum. Tam zawsze nasz profesor oczekiwał jasnego określenia tych trzech elementów: dane wejściowe, wzory i obliczenia, na końcu wynik.

W programowaniu jest podobnie. Dbaj o jasność przekazu. Twój kod nie powinien wyglądać jak rozwiązanie zadania z Competitive Programming.

6. Testuj i sprawdzaj otoczenie

Prawdziwy niezastąpiony programista nie testuje? Od testów są testerzy? Twój kod nie zawiera błędów?

Jeśli tak myślisz, to zdecydowanie zmień takie podejście. Każdy popełnia błędy, czy jest to junior programista, regular, czy też senior. Popełnianie błędów w kodzie jest wpisane w nasz zawód.

Mając świadomość możliwości popełniania błędów mamy wiele narzędzi, które mogą nam pomóc w minimalizowaniu ich liczby.

Nie musisz być mistrzem testowania. Ja też nie jestem. Ale czasem wystarczy, że włączysz aplikację. Tak, tak, zdarzają się tacy programiści, którzy nawet po zmianach kodu jej nie włączą … Nie kompiluje się, sorry, pierwszy raz się mi zdarzyło … No nie pierwszy i raczej nie ostatni.

Po prostu testuj, to co zrobisz. Manualnie albo automatycznie. Ale testuj. Dbaj o jakość. Ona świadczy o Tobie.

7. Prowadź wiki projektowe

Niby nic wielkiego. Gdy pracujesz przy projekcie pamiętaj o tym, żeby utworzyć sobie takie małe wiki. To może być prosty plik w projekcie, strona w Google Docs, czy Confluence lub w innym narzędziu, którego w danej chwili używacie w zespole.

Jedno małe miejsce, gdzie Ty i Twoi koledzy znajdziecie informacje o rzeczach typu: adresy IP usług, sposób otrzymania VPN, zestawienie tuneli, czy też lista osób zaangażowanych w projekt.

To niewielkie narzędzie, małe wiki, zapewni Ci jasną komunikację podstawowych elementów w projekcie. Niezastąpiony programista dba o takie rzeczy.

Zgodzisz się lub nie, ale przesyłanie w kółko mailem informacji o adresach URL usług jest całkiem denerwujące – i to tak naprawdę zarówno po stronie pytającego, jak i odpowiadającego.

Podsumowanie

Także nie wpisuj się w nudny stereotyp o programiście piszącym swoje programy w niedostępnej jaskini. Nie staraj się zostać tym „niezastąpionym programistą”, który trzyma wszystkie informacje dla siebie. A po latach martwi się, czy zastąpienie „jego” aplikacji oznaczać też będzie zastąpienie jego stanowiska pracy.

Pomyśl o sobie, jako o człowieku instytucji. To jaką wartość możesz wnieść do swojej organizacji. Nie tylko zespołu developerskiego, ale właśnie całej organizacji. Miej inicjatywę i staraj się wychodzić poza swoją role. Nie bądź zwykłym klepaczem kodu. Dawaj większą wartość!

Pamiętaj. Niezastąpiony programista dba o:

zrozumienie celu powstania projektu,
komunikację z klientem swojej aplikacji,
aktywny udział w spotkaniach,
jakość i współtworzenie wymagań,
jasność przekazu w kodzie, a nie jest „genialność”,
jakość kodu poprzez jego testowanie,
prostą komunikację podstawowych danych dotyczących projektu, np. poprzez wiki.

I jak zawsze na końcu, skoro tu dotarłaś, czy też dotarłeś, to śmiało daj znać w komentarzu, co Ty o tym myślisz? Czy niezastąpiony programista to dla Ciebie coś więcej poza pisaniem kodu? A może kompletnie się ze mną nie zgadzasz?

W serii Junior Developer ukazały się następujące wpisy:

5 2 votes

Article Rating