Dobry programista

Co wyróżnia dobrego programistę od słabego lub średniego? Kiedy programista zasługuje na pięciocyfrową kwotę na fakturze, a kiedy na słabo płatny staż?

Kim jest dobry programista?

Dobry programista to osoba, która jest profesjonalistą, zna się na swojej specjalizacji, potrafi wybrać odpowiednie narzędzia do zadanego problemu. Zdecydowanie nie uczestniczy w wojenkach programistycznych o to, czy lepszy jest PHP czy Python, o wyższości jednego frameworka nad drugim.

Rozpoznanie takiej osoby w grupie jest przeważnie łatwe – jest to osoba otwarta, która potrafi wytłumaczyć na czym polega problem i jak go można rozwiązać. Nie ma dla niej problemu, żeby popracować chwilę w parach, ba, nie ma problemu, żeby pół dnia spędzić razem przy jednym komputerze. Dla profesjonalisty ważniejsze jest dobro zespołu niż rozwiązanie, które pozwoli na największe korzyści dla siebie samego.

Dobry programista nie wydziela kawałka systemu, którym tylko on może się zajmować, na którym tyko on się zna, dzięki któremu jest niezbędny w firmie i może „lepiej” wynegocjować warunki przy najbliższej podwyżce. Taka osoba jest otwarta do dzielenia się wiedzą, udostępnia linki do ciekawych artykułów, wpisów na blogu, bądź podcastów na firmowym komunikatorze.

Bycie dobrym programistą jest większości łatwiejsze niż nam się wydaje.

Jak stać się dobrym programistą?

Prozaicznie proste pytanie, i tak samo łatwe odpowiedzi 😉

Zasada 1 + 1/2

Osobiście bardzo lubię tę zasadę, według mnie jest podstawą, która wyróżnia dobrych programistów. Nie jest to sztywna zasada, a pole do modyfikacji jest dość spore. Ogólna zasada mówi, że jeśli poświęcamy tygodniowo ok. 40h na pracę na etacie/kontrakcie, to powinniśmy  poświęcić połowę tego na samorozwój poza pracą.

Dlaczego poza godzinami pracy?

Ponieważ gdy pracujemy, zleceniodawca płaci nam w większości za dostarczenie danych funkcjonalności, a nie naukę jak je zaimplementować. Wiadomo, nie jest to sztywne, ponieważ często się zdarza, że musimy nauczyć się czegoś w godzinach pracy i jeszcze mamy za to zapłacone, ale nie jest to podstawą naszej pracy.

Z początkowego punktu widzenia stajemy się takim przysłowiowym nerdem, który nie wychodzi ze swojej piwnicy i ciągle programuje. Po pierwsze, zasada jest płynna, więc nie musimy za każdym razem, każdego dnia po pracy siedzieć po 4h nad swoim własnym projektem. Dodatkowo, nie musi to być żaden projekt, może to być książka, konferencje, meetupy, podcasty czy blogi. W wolnej chwili, przy obecnej technologii możemy przeczytać kilka akapitów książki stojąc w kolejce przy kasie. Podczas dojazdów do pracy bez problemu możemy przesłuchać jakiś podcast, podczas śniadania przejrzeć najnowsze wpisy znanych osób i wybrać kilka na późniejsze przeczytanie.

Większość osób myśli, że ta zasada ma zastosowanie do swoich własnych projektów i zawsze po pracy musimy siedzieć dalej w kodzie. Prawda jest inna: te dodatkowe 20 godzin rozbite jest na 7 dni, a nie na 5 jak praca na etacie, i wlicza się w to każda, nawet najmniejsza część poznawania czegoś nowego.

Wzięcie sprawy w swoje ręce.

Szukanie wymówek od swojego własnego rozwoju jest najgorszą rzeczą jaką można zrobić. Usprawiedliwianie się faktem, że pracodawca nie chce kupić książki, żeby pracownik mógł się nauczyć czegoś nowego, jest całkowicie nie na miejscu. To tak samo, jakbyśmy szli do lekarza specjalisty z książką pod pachą, żeby mógł się nauczyć nowej techniki wyrywania zębów i po wszystkim za to jeszcze zapłacili. Jest to trochę śmieszne, dlatego też, jako programiści, nie możemy wymagać od pracodawców  budżetu na szkolenia, konferencje czy książki. Jest to zawsze dobry gest ze strony firmy ku programistom, ale nie obowiązek.

Książki.

Będąc przy książkach i szkoleniach chciałbym dodać małą notkę odnośnie tego, jakie książki warto zakupić do swojej biblioteczki.

Wśród książek dla programistów mamy większości 4 typy literatury:

Książki techniczne: Są to książki omawiające dane cechy języka, frmeworka, czy biblioteki. Takie książki często opisują konkretną wersję systemu, np.: PHP 5.6, PHP 7.0. Przez to dosyć szybko się dezaktualizują, ale też wiedzę z ich stron możemy bardzo szybko wykorzystać w pracy.

Książki pojęciowe: Książki z tej grupy omawiają najczęściej dane zagadnienia w stopniu ogólnym, często z podejściem filozoficznym. Wiedza w nich nie dezaktualizuje się tak szybko, ale wykorzystanie ich w pracy często wymaga przeczytania dużej części książki, żeby poznać większy konspekt. Do takich książek zaliczamy książki na przykład o Domain Driven Design, TDD.

Książki behawioralne: Jest to bardzo ciekawa grupa książek, która często jest pomijana przez programistów. Są to książki, które nie są do końca związane z samym programowaniem, architekturą czy nawet informatyką. Pozwalają programistom zasięgnąć szerszego konspektu na tematy, w których większości ich wiedza nie jest duża. Do książek z tej grupy zaliczamy książki o np. Agile, Lean Startup, zarządzaniu czasem.

Książki przełomowe: Ostatnia grupa książek, czyli klasyka gatunku, kompletny must have do przeczytania przez każdego developera. Książki te są często ponadczasowe, pokazujące zagadnienia w najlepszy dostępny sposób. Do książek z tej serii zaliczamy np. Czysty Kod, Pragmatyczny Programista, Mistrzostwo czystego kodu.

Zasada Skauta.

Z tych wszystkich propozycji jest najłatwiejszym sposobem, żeby stać się lepszym programistą.

Zasada głosi:

Always leave the campground cleaner than you found it.

W wolnym tłumaczeniu, zawszę zostawiaj obozowisko w lepszym stanie niż je zastałeś.

Wprowadzenie jest dziecinnie proste: jeśli, dostając zadanie z dodaniem jednego pola do formularza, zauważasz, że jakaś zmienna nie jest dobrze nazwana, to w ramach tego jednego zadania popraw też i zmienną. Często takie małe niuanse pozwolą na wyeliminowanie całkowicie problemu z zastanym kodem. Nie w każdym przypadku mamy możliwość przetestowania poprawności działania, ale nie jest to problem –  dopisanie małego testu jednostkowego do jednej metody nie jest ciężkie, a w projekcie code coverege nie wyniesie w tej części 0% a np 1%, co już zmotywuje innych programistów do napisania kolejnego testu.

No more //TODO.

Nie ma nic gorszego od zaciągania długu technologicznego przy tworzeniu nowego kodu. Sytuacja często jest wywierana przez krótki termin dostarczenia danej funkcjonalności, w wyniku czego programista obniża jakość kodu i stara się dostarczyć coś, co ma nadzieję później poprawić. Niestety product owner nie czyta //TODO w kodzie, dlatego zamiast robić kolejne TODO, które zostanie zapomnianym dinozaurem, lepiej stworzyć taska do backloga  i w nim opisać dokładnie co zrobić. Zajmie to kilka minut dłużej niż klepnięcie //TODO, ale zobaczy go też product owner, a nie tylko developerzy. Plusem tego jest fakt, że jak się pozbiera więcej takich ticketów, to sam właściciel projektu stwierdzi, że trzeba coś z tym zrobić.

Jak widać, bycie dobrym programistą nie zawsze wymaga od nas poświęcenia ogromnej ilości wolnego czasu na wchłanianie wiedzy. Na powyższych kilku przykładach można zobaczyć, że często wystarczy po prostu chcieć.

Dodaj komentarz