7 grzechów głównych programisty

Na błędach człowiek uczy się rozumu.

Hezjod

Słowa Hezjoda idealnie pasują do zawodu programisty. Bo gdzie, jak nie podczas pisania kodu pojawia się ich najwięcej?

Ale czy nie lepiej uczyć się na nieswoich błędach? Podczas rozmów z wieloma przedstawicielami naszej branży wielokrotnie poruszaliśmy temat błędów, jakie najczęściej popełniają programiści. Oto podsumowanie tychże dyskusji.

1. Zaniedbanie umiejętności miękkich

Programista – z definicji osoba, której celem jest stworzenie kodu aplikacji, która odzwierciedli wartość biznesową. Osobiście znam wielu świetnych programistów tworzących niemal perfekcyjny kod. Znam również osoby, które jak nikt potrafią rozłożyć na części pierwsze każdy algorytm bez użycia kartki i długopisu. Wszystko potrafią zrobić w swojej głowie. Nauka kolejnej technologii lub języka programowania zajmuje im znacznie mniej czasu niż przeciętnemu programiście.

Powiesz: WOW! Na pewno przebierają w ofertach pracy, a pracodawcy zabijają się o nich! Nic bardziej mylnego. Większość osób, o których pisałem powyżej, często nie potrafi zagrzać miejsca na dłużej w żadnej firmie. Nie dla tego, że dostali kolejną ofertę. Przeważnie wykazywali duże braki w umiejętnościach miękkich, takich jak chociażby praca zespołowa czy samomotywacja.

Jeśli jesteś programistą, to masz świadomość, że umiejętności pisania kodu, to nie wszystko, co potrzebne jest w tej pracy. Poza technicznym skillem istnieją inne ważne umiejętności, które są niezbędne do odniesienia sukcesu. Samomotywacja, umiejętność analizy i wyznaczenia sobie priorytetów oraz praca zespołowa to istne minimum, jakie powinien posiadać każdy programista.

Warto także pamiętać, że gdy za 10 lat znudzi Ci się pisanie kodu, umiejętności miękkie pozostaną i na pewno przydadzą się w następnym etapie Twojej kariery. Team leader, project manager czy jakiekolwiek inne stanowisko, które będzie wymagało pracy z zespołem lub kontaktu z klientem będzie od Ciebie wymagało soft-skilla.

Materiały na temat umiejętności miękkich znajdziesz w sieci mnóstwo . Jeśli natomiast szukasz książki, która bezpośrednio dotyka tego tematu w odniesieniu do zawodu programisty, ze swojej strony mogę polecić Ci: „Soft Skills:The software developer’s life manual” autorstwa Johna Sonmeza.

2. Zasiedzenie i job jumping

Dwa różne zjawiska dotykające jednego problemu. Jak długo pozostać w jednym projekcie / pracy? To pytanie jest bardzo często zadawane na forum. Głównie przez młodych programistów, którzy dopiero zderzają się z realiami pracy w zawodzie. Okazuje się, że odpowiedź jest bardzo prosta. Tak długo, jak trzeba i ani dnia dłużej. Problem pojawia się, jeśli chcemy wyznaczyć, gdzie jest ta granica. Jedno jest pewne, dla każdego jest to zupełnie inna wartość.

2.1 Zasiedzenie

Zacznijmy od zjawiska zasiedzenia. W obecnych czasach, rzadko zdarza się sytuacja, aby developer spędził w firmie więcej niż kilka lat. Jest to na pewno zaszczyt dla samego pracownika, ponieważ może być to swego rodzaju pokazanie wartości, jaką wnosi się do firmy. Lecz pozostanie na jednym stanowisku, zwłaszcza w jednym projekcie przez zbyt długi okres czasu prowadzi do stagnacji i monotonii. Jest to podejście wygodne, zarówno dla pracodawcy, który ma w projekcie osobę, po której wie czego może się spodziewać, która zna projekt i będzie potrafiła wprowadzić kolejnych programistów.

Dla pracownika jest to przede wszystkim bezpieczeństwo i stabilizacja. Z drugiej strony monotonia w pracy przy jednym projekcie jest bardzo męcząca psychicznie. Często powoduje szybsze wypalenie zawodowe lub nawet chęć zrezygnowania z zawodu programisty. Długi czas spędzony przy jednym projekcie przeważnie wiąże się także z zahamowaniem rozwoju. Firmy rzadko kiedy pozwalają sobie na zastosowanie nowoczesnych technologii w już istniejących projektach, co sprawia, że próżno szukać obszarów, w których moglibyśmy w jakikolwiek sposób się rozwinąć.

2.2 Job jumping

Z drugiej strony mamy zjawisko całkowicie odwrotne. Job jumping – czyli częste zmiany firm lub projektów. Takie podejście na pewno pozwoli zdobyć większą wiedzę techniczną, ponieważ zetkniesz się z większą ilością projektów, zupełnie różnych od siebie. Niestety niesie to za sobą spore niebezpieczeństwo. Po pierwsze: nie będziesz miał okazji obejrzeć całego cyklu życia projektu. Przeważnie zostaniesz wrzucony do już istniejącego zespołu, który wprowadzi Cię pobieżnie do tematu. Zanim zdążysz poznać o co tak naprawdę chodzi, znajdziesz się w zupełnie nowym środowisku. Nie poznasz projektu od strony użytkownika (co też jest bardzo potrzebne przy dużych projektach).

Drugą istotną rzeczą, na jaką należy zwrócić uwagę, jest perspektywa potencjalnego pracodawcy. Jeżeli w Twoim CV zobaczy, że w ciągu ostatnich 2 lat byłeś w 5 różnych firmach, a najdłuższy staż to 6 miesięcy, najprawdopodobniej nie będziesz rozpatrywany jako faworyt. Firmy rzadko szukają tymczasowych rozwiązań (zwłaszcza jeśli prowadzą duże i złożone projekty). Pracodawca widząc „skoczka” raczej nie będzie chciał zainwestować w taką osobę, wiedząc, że będzie to raczej krótkotrwałe.

W szukaniu idealnego rozwiązania, warto zwrócić także uwagę na kwestie finansowe. Częste zmiany pracy przeważnie wiążą się ze wzrostem płacy. Firmie łatwiej jest zapłacić więcej nowej osobie, która dopiero dołączyła do projektu, niż osobie z większym stażem w danej firmie. I nie chodzi o ich umiejętności. Tak po prostu jest. Z założenia osoba, która spędziła w firmie na przykład 8 lat, nie odejdzie tak łatwo, nawet gdy w innej firmie dostanie znaczną podwyżkę. Ale tak jak mówię, warto na to zwrócić uwagę, ale nie brać tego jako wyznacznika.

3. Brak promocji własnej marki

Budowanie własnej marki to proces długofalowy, często trwający lata. Możesz zmienić projekt, pracę lub technologię w jakiej pracujesz, ale musisz pamiętać, że Twoje imię oraz marka jaką uda Ci się stworzyć, zostaną z Tobą do samego końca.

Twoja marka to niezwykle potężne narzędzie, które wielu programistów pomija. Odpowiednie budowanie reputacji pozwoli Ci bez problemu na znalezienie nowej pracy lub pozyskanie klienta. Osobiście znam wielu programistów, którzy nigdy już nie będą musieli martwić się o pracę. Poświęcili oni swój czas i wysiłek na stworzenie solidnej marki, która teraz przynosi profity.

Musisz pamiętać, że na rynku pracy jesteś produktem (nie tyle Ty jako osoba, ale Twoja wiedza i czas), a potencjalny pracodawca to konsument. Zbudowanie odpowiedniej marki to nic innego jak reklama „produktu”, czyli Ciebie. Im lepsza, tym konsument chętniej za nią zapłaci.

Jak zbudować własną markę? Jest wiele opcji. Możesz zacząć jak wielu programistów (w tym ja) od założenia bloga. Znajdź temat, który Cię interesuje i zacznij pisać. Pamiętaj, że nie musi być to blog stricte programistyczny. Lubisz fotografię? Nie ma problemu. Piłka nożna? To też dobry pomysł. Wrzuć od czasu do czasu jakiś temat związany z zawodem, a między czasie 4 inne posty o tym, co Cię interesuje. Być może zasłyniesz jako pierwszy programista, który wrzuci w poście jakiś majestatyczny widok drzewa i dorzuci tutorial dla początkujących o algorytmie drzewa. Bo czemu nie?

Blog to jedna z wielu opcji. Nie lubisz pisać? Wolisz nagrywać filmy? Otwórz kanał na YouTube, gdzie będziesz zamieszczał swoje materiały. To też nie dla Ciebie? Do dyspozycji masz również podcasty czy prezentacje na wydarzeniach branżowych.

Jeśli jesteś osobą, która jednak preferuje bardziej pragmatyczne podejście, możesz zbudować swoją markę opierając się o swój kod. Stwórz jakieś darmowe open source-owe biblioteki. Wypełnij swoje repozytorium publiczne projektami, które pokażą światu jakim jesteś programistą. Ale o tym szerzej w następnym puncie.

4. Poza społecznością

Społeczność (community) to coś, wykraczającego poza jednostkę, zrzeszające grupę ludzi o podobnych zainteresowaniach, poglądach lub dążących do tego samego celu. Programiści często zapominają o tym, jak wielka siła leży w community, ograniczając się jedynie do szukania rozwiązań na Stackoverflow lub grupach na FB.

Jeżeli masz wrażenie, że Twój rozwój utknął w martwym punkcie, a zdobywanie nowej wiedzy z pustych poradników czy książek nie jest tym czego szukasz to właśnie odpowiedni moment na otworzenie się na społeczeństwo programistyczne.

Konferencje

Ale jak to zrobić? Opcji jest naprawdę dużo. Zacznij brać udział w konferencjach i wydarzeniach z branży. Organizowane są regularnie i na pewno znajdziesz coś dla siebie. Jedną z najpopularniejszych na pewno jest 4Developers. Nawet gdybyś miał uczestniczyć tylko jako słuchacz, znajdziesz wykłady, które Cię zainteresują.

Meetup

Nie chcesz wydawać pieniędzy na bilety lub uważasz, że jazda na drugi koniec Polski nie jest dla Ciebie? Sprawdź Meetupy. Być może w Twojej okolicy jest już grupa zapaleńców, którzy chcą się spotkać i pogadać o Waszych wspólnych zainteresowaniach. Nie ma? To może sam stwórz taką grupę?

A coś innego?

Są jeszcze Hackathony i konkursy, w których możesz wziąć udział. A co jeśli preferujesz ograniczony kontakt z ludźmi? Tutaj też jest rozwiązanie. Stackoverflow, grupy na Facebooku, blogi czy fora. Branie czynnego udziału w dyskusjach, zadawanie pytań i odpowiadanie na nie pomoże Ci w rozwoju.

Jeżeli do tej pory nie uczestniczyłeś w życiu społeczeństwa programistycznego, bardzo chciałbym zachęcić Cię do zaangażowania się w nie. Samo bycie częścią community da Ci sporo doświadczenia, pozwoli na zdobycie cennych kontaktów i w pewien sposób ukształtuje jako programistę.

5. Pośpiech w awansie

Każdy z nas marzy o awansie. Wiąże się z tym nie tylko profit w postaci wyższych zarobków, ale także podniesienie prestiżu. Niestety zbyt szybkie i częste awanse powodują, że możemy znaleźć się w sytuacji, gdzie nie możemy już pójść wyżej. I co wtedy? Zmieniamy pracę, aby znów móc zaczynać od pewnego pułapu i piąć się w górę? Ale nie na tym chciałbym się skupić. W środowisku programistycznym występuje także inne zjawisko, które według mnie jest bardziej niepokojące.

„Poszukiwany Senior Developer. Min 2 lata doświadczenia komercyjnego”. Któż z nas nie widział podobnie brzmiącego ogłoszenia na LinkedIn, GoldenLine lub grupie na Facebooku. Już od dawna można zaobserwować zacieranie się granic pomiędzy mid, a senior developerem. Można to porównać do sytuacji sześciolatków, którzy idą do pierwszej klasy. Może umieją już liczyć, pisać i czytać, ale czy aby na pewno są już gotowi na pójście do szkoły? Czy są przygotowani emocjonalnie i psychicznie? Podobnie jest z developerami, którzy już umieją na tyle dużo, aby „bawić się” ze starszymi, ale czy są gotowi, aby pójść do szkoły?

Możliwe, że taki junior ma większą wiedzę teoretyczną od seniora. Być może przeczytał więcej książek i potrafi napisać hello world we wszystkich frameworkach JavaScriptowych (nawet tych, które ktoś właśnie pisze). Ale należy zadać sobie pytanie – czy jest gotowy pracować bez nadzoru osoby z większym stażem? Czy samodzielnie będzie w stanie rozwiązywać problemy. Należy pamiętać, że programowanie to nie bezmyślne klepanie kolejnych linijek kodu, implementowanie skomplikowanych algorytmów sortowania czy użycie jednego wzorca projektowego. To przede wszystkim przedstawienie wartości biznesowej produktu, który tworzymy.

Zanim będziesz rozważał zmianę przedrostka w swoim CV z junior na senior, pamiętaj, że z tą zmianą wzrasta również odpowiedzialność, jaka na Tobie będzie ciążyć. Jeżeli robisz to tylko ze względów finansowych, nie rób tego. Większe wynagrodzenie jesteś w stanie wywalczyć bez awansu (oczywiście do pewnego stopnia). Ja po blisko 5 latach programowania, wciąż uważam, że do seniora brakuje mi jeszcze kilkudziesięciu kubków kawy. Dlatego nie śpiesz się i czerp garściami od bardziej doświadczonych, abyś to Ty kiedyś mógł przekazać swoją wiedzę innym.

6. Zaniedbanie samorozwoju

Przeważnie, gdy programiści rozmawiają między sobą, zadają sobie pytania w stylu „Gdzie teraz pracujesz?”, „Przy jakim projekcie?”, „Jakiej technologii używasz?”. Pytania te mają odniesienie do teraźniejszości, do tego co aktualnie robimy. Mało kiedy ktoś zapyta nas „A co masz zamiar robić za rok?” (ok, to pytanie zada nam każdy rekruter, ale nikt z naszej branży), albo czy przeczytaliśmy ostatnio jakąś książkę lub artykuł, który polecilibyśmy każdemu.

Niewielu programistów ma własny plan samodoskonalenia. Poszerzania swojej wiedzy w konkretnym kierunku i dążenia do wyznaczonych sobie wcześniej celów związanych z samorozwojem. To częsty obszar, do którego nie przywiązujemy większej wagi. Ważne to co tu i teraz.

Niewiele osób również wie, w jaki sposób to robić. Od czego zacząć. Jeśli jesteś w tej grupie, zacznij od czegoś prostego. Wyznacz sobie krótkoterminowy cel. Naucz się nowej technologii, frameworka lub narzędzia. Zacznij czytać blogi lub tutoriale zamieszczane w internecie. I w końcu – czytaj książki. Jakie? Dowolne z branży. Znajdź swoją nisze, która pochłonie Cię do końca. Kup lub pożycz książkę od kolegi z pracy i przeczytają ja. Nie mówię oczywiście od razu, żebyś czytał 5 książek w miesiącu. Zacznij od jednej. Przeciętnie książka ma około 200 stron, czyli około 7 na dobę. Jeśli poświęcisz 15 minut dziennie np. w drodze do pracy (jeśli używasz komunikacji miejskiej) to wystarczy.

Pamiętaj, że stawiając małe kroki przez długi okres czasu, możesz daleko zajść.

7. Brak jasnych celów

Bez jasno określonego celu, jaki chcesz osiągnąć w swojej karierze, będziesz niczym chorągiewka na wietrze. Bez tego, jesteś jak pirat , który dryfuje na morzu bez mapy i kompasu i nawet nie wie czego szuka.

Musisz wyznaczyć sobie cel, co chcesz osiągnąć jako programista i dążyć do niego każdego dnia. Jeśli po kilku latach spędzonych jako programista, nadal nie wiesz, co jest Twoim celem, to znaczy, że gdzieś popełniłeś błąd. W takim przypadku jedynym winnym jesteś Ty sam, nikt inny!

Co można z tym zrobić? Znajdź odrobinę czasu, nie koniecznie dziś, nie rzucaj wszystkiego, co właśnie robisz i co najważniejsze, przygotuj się. Zrób rachunek sumienia, zastanów się i określ swój cel. Jeśli nie potrafisz stworzyć planu długoterminowego, nic nie szkodzi. Określ cele krótkoterminowe. Gdy (a raczej kiedy) je osiągniesz, będziesz mógł wyznaczyć kolejne. Takie podejście pozwoli Ci po pewnym czasie określić kierunek w jakim zmierzasz. To ułatwi Ci wyznaczenie tego najważniejszego celu. Aby sobie pomóc dowiedz się czym jest OKR.

Podsumowanie

Mam nadzieję, że tym artykułem zachęcę Cię do działania. Do przeanalizowania swojej dotychczasowej kariery i sprawdzeniu, czy Ty sam nie popełniłeś jakiś rażących błędów, których można było uniknąć.

A może sam znalazłeś “grzechy”, o których ja nie napisałem? Podziel się nimi w komentarzu.