Kategorie
Software Craftsmanship

馃幆 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!

Junior Java Developer Handbook

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:

  1. Junior Developer w 2020 roku
  2. Top 10 umiej臋tno艣ci Junior Java Developera
  3. Junior Developer a Regular
  4. Co tak naprawd臋 sprawdza rozmowa kwalifikacyjna na stanowisko Junior Developer?
  5. Junior Developer 2020 鈥 Podsumowanie

5 2 votes
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments