Co jest najtrudniejsze w byciu developerem? Seniorzy odpowiadają (cz.3)

„Seniorzy odpowiadają” to cykl, który powstał niedawno w naszym magazynie, ale wzbudził Wasze zainteresowanie. Może przekonuje Was to, że zadajemy nieco inne pytania niż w seriach „Od Juniora do Seniora”, czy w „DevDebatach”. Dziś postanowiliśmy przepytać doświadczonych developerów, by dowiedzieć się od nich, co jest najtrudniejsze w byciu senior developerem. Czego się dowiedzieliśmy? Zobaczcie sami.

Co jest najgorsze, najtrudniejsze i niespodziewane w byciu developerem?

Odpowiada: Iwona Jóźwiak, Senior PHP Developer w Divante:

Na tak postawione pytanie chyba można by pisać całe prace dyplomowe i innego rodzaju elaboraty. Ostatnimi czasy przekonuję się jednak, że najtrudniejsze jest zrozumienie „po co to robimy i komu ma służyć?”. Problem ten dotyczy zarówno świeżo upieczonych adeptów sztuki programowania, jak i „starych wyjadaczy”. Ilu klientów, tyle problemów i oczekiwań. Wielu z nas wychodząc z założenia, że najlepsze rozwiązania to uniwersalne rozwiązania, chciałoby znaleźć panaceum na wszystko, a co gorsza opieczętować to jedną nazwą funkcji, metody, klasy czy też modułu. W wielu przypadkach prowadzi to do niesamowitej abstrakcji rozwiązań, które stają się niejako osobnym językiem programowania. Czasami ma to swoje zalety, ale zdarza się też, że dopasowywanie takiego rozwiązania do potrzeb konkretnego klienta bywa droższe niż napisanie skromnego mechanizmu, o który właśnie w tym momencie nas prosi.

Często też uciekamy od pracy ze starszym kodem – boimy się jego aktualizacji. Zdecydowanie bardziej cenimy sobie wdrożenia niż maintenance. Dużo łatwiej jest bowiem budować swój świat niż dopasowywać się do zastanego. Łatwiej dopisać do istniejącego mechanizmu kolejne 5 linijek niż zdecydować się na refaktoryzację. Decyzja ta jest nie tylko trudna dla samego developera, ale i klienta, który niestety musi pokryć jej koszty. Wymaga to zatem dojrzałości i gotowości obu stron, jednak ciężar udowodnienia jej zasadności leży po stronie developera.

Mocowanie się z różnymi wdrożeniami, błędami i refaktoryzacjami sprawia, że czasami mamy serdecznie dość tego, czym się zajmujemy. Zastanawiamy się nad naszym rozwojem osobistym i tym, co moglibyśmy robić innego. Świat IT niesie ze sobą prawie, że nieograniczone pole rozwoju. Często potencjalne zarobki są motorem napędowym naszych decyzji, jednak szybko dociera do nas, że w innych językach programowania pojawiają się tej samej natury problemy. Cross skilling jest dziś bardzo uznawany, więc wielu developerów decyduje się na stosunkowo częstą zmianę projektów, technologii czy też samych pracodawców. Wydaje mi się jednak, że przy tak ogromnym polu do popisu nie jest możliwe być specjalistą, poświęcając jedynie rok czy dwa kolejnym obszarom developmentu. Ciekawi wszystkiego możemy więc wpaść w pułapkę powierzchownej wiedzy.

Na sam koniec pozwolę sobie krótko dodać, że w dobie pędzącego pociągu, jakim jest postęp technologiczny, najbardziej zastanawia mnie przyszłość tego zawodu. Zastanawia mnie, jak będzie wyglądał świat e-commerce za 20-30 lat, gdy nasze życie zawodowe będzie się chyliło ku końcowi. Czy będziemy jeszcze potrzebni? Czy nasze doświadczenie będzie wystarczające, by móc pracować w swoim fachu do emerytury? Jaką drogę rozwoju powinniśmy obrać, by nagle świat IT nie zamknął dla nas swych drzwi? Na te pytania wciąż szukam odpowiedzi i zapewne będą one zaskakujące technologicznie, jak i biznesowo.

Odpowiada Łukasz Cichocki, Senior Frontend Developer:

Przede wszystkim nieprawidłowe zorganizowanie dokumentacji do projektu. Gdy klient w czasie prac nad aplikacją zaczyna nanosić swoje nowe pomysły, często część wykonanej pracy idzie na marne. Można by rzec iż doświadczenie nabyte podczas kodowania zostaje, jednak takie zachowanie wydłuża czas oddania projektu. Ostatnio spotkałem się właśnie z takim projektem, który trwał około roku, gdzie początkowe założenia było 2 razy bardziej optymistyczne.

Kolejnym zagadnieniem jest marnowanie czasu w trakcie dnia pracy. Może moje podejście nie jest zbyt popularne jednak ja tak mam. Często firmy w branży IT kuszą rozrywkami takimi jak piłkarzyki, PS itp.. Zdecydowanie bardziej preferuję wyjście wcześniej z pracy niż marnowanie go na powtarzające się codziennie rozrywki, które nic nie wnoszą.

Odpowiada Nikodem Ciesielski, Lead Developer w Aptitude Software

To są pytania indywidualne więc odpowiem tylko w swoim imieniu:

• najgorsze w byciu devem — najgorszy jest brak możliwości wykorzystanie talentu, robienie naprawdę ambitnych zadań i rozwijanie umiejętności, których rynek naprawdę potrzebuje i szuka ludzi z co najmniej 10-letnim doświadczeniem;
• najtrudniejsze w byciu devem — przekonywanie innych, a w szczególności mocodawców to swoich słusznych pomysłów, znajdywanie poparcia dla swoich inicjatyw, przekonywanie innych do swoich racji;
• niespodziewane w byciu devem — niespodziewanie przeważająca większość zadań dev-owych jest prymitywna i jedyna potrzebna umiejętność, to znajomość technologii, praktycznie każdy zdolny licealista mógłby z powodzeniem te zadania robić, co widać po tym, że standardem stało się zatrudniania studentów już 3-go a nawet 2-go roku.

Odpowiada Przemysław Cackowski, iOS Tech Lead, Freelancer

Zacznę może od najtrudniejszego. Wydaje mi się, że umiejętność nadążania za zmianami technologicznymi to nie prosta sprawa. Mówię oczywiście o takim pojęciu wiedzy, dzięki której „czujemy” technologię i jesteśmy w stanie znaleźć dzięki niej pracę. Przeczytanie kilku tweetów, i zapamiętanie akronimów to zbyt mało. Natomiast widzę z czasem, robi się to coraz trudniejsze i sam nie wiem jak to będzie.

Niespodziewane dla mnie jest to, jak trudno znaleźć w firmach pomysł na „karierę” dla osób, które wolą jednak zajmować się technologią. Jest jakieś dziwne parcie i ciśnienie, że w pewnym momencie należy zostać managerem lub kierownikiem. Skąd się to bierze? Patrząc na inne rynki USA, EU, programiści lub osoby związane z technologią są porządane, wyszukiwane, niezbędne do pracy w firmach przynosząc im konkretne korzyści. W Polsce słyszę wypowiadane z dumą „ja już nie koduję”, i nie wiem co tym myśleć.

Natomiast za najgorsze to uważam zepsucie rynku IT poprzez wszelkiego rodzaju firmy offshore, nearshore, które przenoszą swoje centra do tańszych krajów jak nasz wykorzystując sytuację ekonomiczną i dobre kursy na walutach obcych. Dodatkowo obrastają te korporacje wszelkiego rodzaju firmami wynajmującymi pracowników co dodatkowo cementuje ten dość zabetonowany już sektor. Sporo osób grzęźnie w tych nikomu niepotrzebnych starych systemach, w utrzymaniu, klepaniu ticketów itp. robiąc jako tak naprawdę tania siła robocza. Mam wrażenie, że marnuje się trochę potencjału, który można by przekuć na rozpoznawalane produkty lub usługi z logiem Made in Poland. Ale to pewnie temat na szerszą dyskusję.

Oferty pracy z

Odpowiada Artur Wróbel, Senior Frontend Developer w GogoApps:

Najgorsza w byciu developerem jest ścieżka kariery. Zaczynasz, jesteś juniorem, uczysz się, ciężko pracujesz, przechodzisz do mida, a potem seniora. I nagle – jeb! – ktoś wymyśla, że dalszym rozwojem dla Ciebie będzie stanowisko menedżerskie. I stajesz się team leadem, kierownikiem albo kimś w tym stylu. Nie kodujesz, nie rozwijasz się, użerasz się z ludźmi, odpowiadasz nie za siebie, tylko za innych. Koniec końców mówisz “dość” i odchodzisz do innej firmy, na “normalne” stanowisko programistyczne. I tak w kółko.

Najtrudniejsze jest to, że programowanie nie jest celem samym w sobie. Tworzysz jakiś produkt. I ten produkt może być dla branży bankowej, medycznej, hazardowej — czyli takiej, o której masz jedynie mgliste pojęcie. Ale żeby dobrze wykonać swoją robotę musisz poznać jej specyfikę, czyli musisz nauczyć się rzeczy, które nie do końca cię interesują.

A niespodziewane jest to, że zmieniasz pracę, przychodzisz do zupełnie nowej firmy, o której nikt nigdy nie słyszał i pierwszego dnia okazuje się, że pracuje już tam już ktoś z Twoich znajomych. Mały świat 😛

Odpowiada Tomasz Szepczyński, Senior Software Developer w Bonfire IT:

Praca developera wiąże się z nieustannym rozwojem i ciągłym czytaniem dokumentacji do nowych bibliotek i frameworków. W świecie koderki wystarczy się zasiedzieć dłużej w jednej technologii i stajesz się dinozaurem, bo cały świat już pisze w czymś innym. Ponadto często kod, który dostajesz nie jest pierwszego sortu i posiada liczne ograniczenia oraz błędy. Korzystanie z cudzych rozwiązań jest najczęściej konieczne, ponieważ nie jesteśmy w stanie wszystkiego zbudować sami w skończonym czasie, jednak serwujemy sobie pewien black-box w naszej aplikacji, który w przypadku błędów gwarantuje długie sesje debugowania.

Dzień programisty to nie tylko praca z maszynami — z porozumiewaniem się z nimi akurat większość z nas nie ma problemu, ale również dochodzą liczne, długie dyskusje, często z ludźmi których dotyczy efekt Krugera-Dunninga. Jeśli chodzi o to co niespodziewane, to będzie to dla mnie proces rozwiązywania problemu. Ten moment kiedy już przeszukasz stackoverflow, docsy, napiszesz issue na githubie i wychodzisz z pracy bezsilny, zły i chcesz zaorać wszystko od nowa… a gdy budzisz się rano, w porannym autobusie rozwiązanie przychodzi samo i biegniesz żeby dopisać brakujące linijki. Ten system nagrody jest dla mnie wielkim motywatorem do pracy.

Odpowiada Sebastian Malaca, Senior Software Developer w UBS:

Moim zdaniem dwie charakterystyki tej pracy można traktować jako coś bardzo trudnego:

1. Ciągła konieczność nauki — doświadczenie jest istotne. Ilość rozwiązanych problemów, lata obycia z kodem sprawiają, że szybko jesteś w stanie zauważać rzeczy, które innym umykają. Jeżeli jednak doświadczenie nie idzie w parze z ciągłym poszerzaniem wiedzy, uczeniem się nowego, to niestety istnieje spore ryzyko, że w pewnym momencie coraz więcej zwrotów, terminów i rozwiązań będzie Ci obca.
   Praca developera powinna (i zazwyczaj tak jest) iść w parze z pasją, ponieważ dzięki temu ta nieustanna pogoń za wiedzą jest przyjemnością, a nie męczącym obowiązkiem.
2. Przyzwyczajenie się do nieustannych zmian — zmieniają się wymagania, zmieniają się rozwiązania, odkrywasz przeszkody, których nie przewidziałeś i nie wziąłeś pod uwagę, itp., itd. Programista musi być mieć świadomość, że coś się może zmienić i z pewnością czegoś jeszcze na dany temat, o danym problemie nie wie. Jest to szczególnie trudne na początkach kariery, ponieważ wymaga innego podejścia do rozwiązywania problemów. Rzadko się zdarza, że wszystko potoczy się od początku do końca zgodnie z planem. Rzeczywistość szybko weryfikuje takie podejście, a developer uczy się planować w taki sposób, aby wprowadzenie zmian było możliwe w każdym momencie. Uczy się projektować takie rozwiązania gdzie decyzje, z których najtrudniej się wycofać (o ile jest to w ogóle możliwe) są podejmowane na jak najpóźniejszym etapie.

Co natomiast jest moim zdaniem najgorsze? To, że niesamowicie rzadko odpowiedzią na pytanie jest „tak” albo „nie”. Najczęstszą odpowiedzią, którą można usłyszeć jest „to zależy”. Pomimo tego, że programiści żyją w świecie zer i jedynek to rozwiązywane problemy są bardzo złożone. Nie ma prostych odpowiedzi i zawsze działających wzorców. To czy dane rozwiązanie można zastosować w danej sytuacji zależy od wielu zmiennych, które trzeba rozpoznać i prawidłowo ocenić ich wagę. Każda decyzja to zbiór plusów i minusów i szybko należy oswoić się z myślą, że pomimo chęci zrobienia wszystkiego idealnie trzeba będzie zadowolić się tym, co Twoim zdaniem najlepiej spełnia istniejące wymagania.

Niespodziewaną rzeczą dla nowego developera może być fakt, że komunikacja wypełnia sporą część pracy. Trzeba rozmawiać z klientem/analitykiem, żeby zrozumieć wymagania. Trzeba wymyślić rozwiązanie i się nim podzielić z kolegami z zespołu. Trzeba szukać odpowiedzi na pytania, które znajduje się zarówno podczas fazy projektowania, jak i programowania. Im większy zespół, tym więcej osób, z którymi trzeba wymieniać się informacjami. Im większy projekt, tym więcej zespołów oraz innych osób w niego zaangażowanych. Dla kogoś, kto dopiero rozpoczyna swoją przygodę może być to zupełnie inny świat, niż ten, który miał w głowie.

Powyższych rzeczy osobiście jednak nie traktuję jako minusów tej pracy. Tak, potrafią być problematyczne i trudne, ale z drugiej strony to właśnie one sprawiają, że praca programisty jest taka interesująca, nieustannie dostarcza nowych bodźców i wyzwań, i każdego dnia możesz spodziewać się, że nauczysz się czegoś nowego.

Odpowiada Paweł Papke, Tech Lead w Lizard Media:

#najgorsze

Jak w wielu zawodach, uważam, że najgorsze jest trafienie do niedojrzałej, toksycznej i zabetonowanej firmy. Z ciśnieniem na deadline’y, gdzie inne prace pozwalające na łatwiejsze utrzymanie i przyjemniejsze wytwarzanie kodu spotykają się z oporem z powodu czasu jakie na nie trzeba najpierw poświęcić. Brakiem przepływu informacji, gdzie nie ma wiedzy dlaczego realizujemy funkcjonalność, co ma ona rozwiązać, w czym pomóc, dla kogo jest skierowana, jaki wolumin danych będzie obsługiwać, jak często, itp. Ma być, bo klient tak chce. Bałaganem w zarządzaniu, kiedy co drugi dzień dostajemy wrzutkę do zrealizowania na dziś. Fatalnym kodzie, gdzie kolejni deweloperzy dokładali swoje autorskie rozwiązania. Architektura systemu, jeżeli kiedykolwiek istniała, dawno została zasypana przez kolejne obudówki, tymczasowe rozwiązania i niezrozumiałe procesy. Wchodząc w ten kod czujesz, że gdzie tam, w którejś z tych klas czają się smoki, czekając tylko na Twoje potknięcie. W takim miejscu zapomnij o dobrych praktykach, wzorcach projektowych, dbaniu o jakość, fundamentalne anty patterny zaczniesz traktować jak codzienną normalność, a godziny debugowania jako standard pracy dewelopera.

Opisana atmosfera uczy nieprofesjonalnego podejścia do wytwarzania oprogramowania, pokazuje deweloperowi oderwany obraz pracy w IT, demotywuje i zniechęca do rozwoju.

#najtrudniejsze

Osobiście uważam, że najtrudniejsza jest praca z ludźmi. Umiejętność sprawnego komunikowania się z naszymi współpracownikami, osobami ze świata biznesu, klientami. W przypadku biznesu to umiejętność w zrozumiały sposób przekazania niuansów technicznych, zadawanie pytań ułatwiających dotarcie do sedna tematu oraz budowanie dobrych relacji. Uczenia się i pogłębiania swojej wiedzy z zakresu domeny klienta. Rozumienie, że eksperci są po drugiej stronie i naszym obowiązkiem jest poznanie tej wiedzy przed wdrożeniem funkcjonalności, mimo że potrafi to kosztować sporo pracy, nerwów i wyrzeczeń. Przy pracy z zespołem umiejętności konstruktywnego rozmawiania o tworzonej architekturze, implementowanych rozwiązaniach i sposobie pracy. Inicjowanie rozmów, gdy pojawiają się problemy. Przeciwstawianie się zamiataniu spraw pod dywan. Rozumieniu, że małe rzeczy z czasem stają się dużymi rzeczami, dlatego warto szybko je rozwiązywać. Proszeniu o pomoc, radę, sugestię gdy nie jesteśmy pewni obszaru po którym się poruszamy. Szanowaniu się wzajemnie, mimo różnicy zdań, doświadczenia i podejścia. Umiejętności spojrzenia z innej perspektywy, przyznania się do błędu, dążenia do sytuacji win-win.

#niespodziewane

Dla mnie nieodzowne w pracy programisty są różne fuckupy, które teoretycznie nie miały się prawa zdarzyć. Pomimo kodu, który znamy, wielu faz testów i wysokich standardów, gdy myślimy, że wszystko mamy pod kontrolą zdarza się błąd. W dodatku błąd na środowisku produkcyjnym. Poważny, krytyczny, akurat tam — w sercu systemu. Błąd, który powoduje u nas podwyższenie tętna, błyskawiczne przetwarzanie dostępnych informacji, wyostrzenie zmysłów. Musimy zareagować, tu i teraz. Załatać sytuacje na produkcji, udrożnić system, wprowadzić hotfixa. Odkręcenie problemu często wymaga wielu godzin i dni, skutecznie rozbijając plan najbliższych prac. Czasem nie jest to nawet błąd, ot została przekroczona masa krytyczna ruchu, wielkości danych, czy innego progu którego nie sprawdziliśmy przy okazji kolejnych zmian.

Odpowiada Damian Dziaduch, Freelancer, Senior Developer:

Najgorszą rzeczą w programowaniu jest aktualnie tempo w jakim to wszystko się rozwija. Co gorsze, odnoszę wrażenie, że to tempo jest coraz większe i większe. Z roku na rok, dochodzą nowe języki, nowe technologie, nowe frameworki. Na mnie to wywiera ogromny wpływ. Bardzo chciałbym być na bieżąco ze wszystkimi nowinkami, lecz pracując i prowadząc gospodarstwo domowe jestem w stanie tylko lekko liznąć te nowości. A jako programista bardzo lubię poznawać i uczyć się nowych rzeczy. Gdyby tylko doba miała więcej niż 24 godziny.

To już trzecia część cyklu pt. Seniorzy odpowiadają. W pierwszej zapytaliśmy doświadczonych developerów o to, jaki był największy problem, z którym się spotkali i w jaki sposób go rozwiązali. W drugiej części szukaliśmy odpowiedzi na pytanie, w jakim wieku dobry dev powinien zostać seniorem.