TOP 5 największych grzechów doświadczonych programistów

• Programista
• Open Source
• Bezpieczeństwo w sieci

TOP 5 największych grzechów doświadczonych programistów

Najgrubsze błędy, popełniane przez doświadczonego programistę, nie muszą znajdować się w płaszczyźnie technicznej, wręcz przeciwnie. Nie stanowi problemu w ciągu 10 lat nauczyć się klepania kodu, lecz programowania – tak.

Witajcie na blogu informatycznym!

Napisz, proszę, w komentarzach czy Twoim zdaniem, lekarz który w ciągu 10 lat, na zlecenie spółek farmaceutycznych, wystawił pacjentom 3000 podobnych recept na paracetamol i jeden lub dwa rodzaje sterydów na przeziębienie, w opinii szeroko rozumianego społeczeństwa, jest bardziej wiarygodny od tego który ma tylko rok doświadczenia zawodowego i wypisał tylko 300 dokładnie takich samych recept?

Problem polega na tym że z reguły skupiamy się na ilości przepracowanych lat i mniej na osiągach i korzyściach, wynikających z wykonanej przez konkretną osobę pracy. Niestety, większe doświadczenie to nie zawsze większa wiedza, większa zdolność do rozwiązywania bardziej skomplikowanych problemów, do podjęcia lepszych decyzji itd. Czasem doświadczenie przychodzi w pojedynkę i pozostaje się tylko i wyłącznie liczbą lat. Ktoś może w parę lat osiągnąć znacznie więcej, nauczyć się znacznie więcej, nabyć znacznie więcej korzystnych nawyków niż inna osoba w 10...30...40 lat.

Jeśli chodzi o programistę - w publikacji na temat znalezienia pierwszej pracy dla programisty i o przebranżawianiu się na informatyka podkreślałem jak ważną, wręcz decydującą, jest rola pierwszej pracy informatyka. Najstraszniejszym scenariuszem dla programisty, testera lub administratora systemowego jest dłuższe zatrzymanie się w jednej firmie. Jeśli się okaże że u jedynego i pierwszego pracodawcy brak dobrych praktyk projektowych i programistycznych, brak ludzi od których można się uczyć (taka sytuacja występuje zaskakująco często), to od samego początku początkujący informatyk będzie czerpał złe doświadczenie, najczęstszej wyraźnie amatorskie.

Oto lista TOP-5 największych grzechów doświadczonych programistów.

1. Brak rozwoju programisty

Ciągła nauka i dokształcanie się dla programisty jest absolutnie kluczowe. Dla mnie, programista który przez ostatni rok nie nauczył się żadnej nowej dla siebie technologii, nie opanował nowego języka programowania itd - beznadziejnie stracił rok życia. Każdy rok w którym programista nie opanował nowych dla niego technologii można wykreślić z jego CV.

2. Zatrzymanie się programisty w jednej firmie

W sumie to koliduje się z poprzednim punktem. Programista który przez ostatnie 3 lata nie zmienił pracodawcy lub nie nawiązał współpracy przynajmniej z jednym nowym klientem (jeśli mówimy o działalności gospodarczej lub freelancerstwie) degraduje zawodowo. Brak wymiany zdaniami z kolegami o innych poglądach, o innym doświadczeniu itd, jest równoznaczne z przerwa w działalności zawodowej. Może na taśmie produkcyjnej, w rolnictwie albo w kuchni (szczególnie jak się jest szefem tej kuchni) zatrzymanie się przez dłuższy okres jest dobre, ale na pewno nie w IT, ponieważ IT to niezwykle dynamiczna branża.

Biorąc pod uwagę pkt. 1 i 2, czytając CV doświadczonego programisty warto brać pod uwagę najwyżej pierwsze 3 lata pracy w każdej firmie. Inaczej mówiąc, ten co pracował dla trzech firm mniej-więcej po 3 lata w każdej ma 9 lat wartościowego doświadczenia, a ten co przepracował 30 lat dla jednej firmy to tak naprawdę ma 3 lata wartościowego doświadczenia i to nabytego 27 lat temu (czyli dzisiaj nadaje się na pracownika muzeum informatyki).

3. Brak własnego zdania programisty

W tej branży (w sumie jak i ogólnie w życiu) brak własnego zdania jest równoznaczny z byciem agentem obcego wywiadu, przy czym dosłownie. Chodzi o to że największe korporacje z branży IT, same albo pośrednio (udając że to nie oni) wymuszają na osobach bez własnego zdania i kręgosłupa moralnego, stosowanie coraz bardziej otwartych technik śledzenia wszystkiego i wszystkich. Korporacje na potęgę promują swoje szpiegowskie technologie, wydając je za całkiem pomocne narzędzia, czasem pod własną marką, a czasem pod pozorem innej marki. Wybór, albo w najbardziej hardkorowych przypadkach, zrobienie własnego, systemu operacyjnego jak i innego oprogramowania - to, przede wszystkim, kwestia bezpieczeństwa (nie rzadko - narodowego).

Kwestia bezpieczeństwa to jedno, ale dochodzi też kwestia wydajności, kosztów wdrażania i utrzymania tego czy innego rozwiązania itd.

Jeśli programista nie potrafi zbadać co rzeczywiście jest niezbędne dla projektu, a czego da się uniknąć, albo jeśli poprostu bezmyślnie wykonuje czyjeś polecenia i nie potrafi zrozumieć co tak naprawdę robi to czy inne narzędzie, nasycając oprogramowanie technologiami szpiegowskimi - szkoda użytkowników (którzy z reguły też nie wiedzą co mają poinstalowane w swoich telefonach i komputerach).

Można mieć dwucyfrową liczbę lat doświadczenia w CV i nie rozumieć czym tak naprawdę są niektóre "bezpłatne" narzędzia promowane przez wielkie korporacje. Wiele programistów o bogatym (liczbowo) doświadczeniu dalej nie rozumieją gdzie i dlaczego jest darmowy ser... Owszem, w branży IT rzeczywiście jest dużo darmowych rzeczy, ale niestety korporacje nauczyły się pod pozorem OpenSource pod osobnymi markami promować swoje szpiegowskie narzędzia.

4. Jestem tu najmądrzejszym programistą

Czyli optymalne rozwiązania VS upartość. To jest trochę przeciwstawienie zagadnieniu opisanemu wyżej w pkt. 3. Sam wielokrotnie byłem ofiarą tego sposobu myślenia: no przecież wszystko wiem, jestem tu najmądrzejszy...

A tak naprawdę, dopiero jak człowiek nauczy się słuchać i słyszeć innych, szczególnie tych z kim się nie zgadza (i wyciągać z tego wnioski), przestanie być "najmądrzejszym" - to dopiero początek osoby doświadczonej i przynajmniej trochę mądrej. Jeśli chodzi o programistów, to jest szczególnie wyraźne, ponieważ wielu z nas jesteśmy introwertykami i nie bardzo umiemy słuchać innych. Z reguły albo bezmyślnie słuchamy innych (czyli to co opisałem w pkt. 3) albo upieramy się tam gdzie tego robić nie warto.

Często-gęsto inżynier (w tym programista) podświadomie wybiera te technologie które lubi, które zna, zamiast tych które są optymalne dla projektu. A w przyszłości to skutkuje wysokimi kosztami albo niemożliwością (nieopłacalnością) utrzymania i/lub rozwoju produktu.

Kiedyś w jednym z wywiadów Pan Profesor Jerzy Bralczyk dostał pytanie dlaczego czasem słucha jednego z polityków poglądy którego są zupełnie przeciwne poglądom Pana Profesora. Na co odpowiedział (z góry przepraszam jeśli nie zbyt dosłownie): "A po co słuchać tych z kim się zgadzam? Przecież wiem co powiedzą. To od tych z kim się nie zgadzamy czerpiemy najwięcej informacji."

5. Nauka własna programisty kosztem klienta

To zjawisko jest powszechne dla początkujących programistów, ale też stosowane przez doświadczonych kolegów. Z resztą sam też nie raz tak robiłem, aż zrozumiałem w którymś wieku że to jest bardzo zła praktyka.

Chodzi o to że nie znamy jakiegoś framework'a, języka programowania, bazy danych czy innej technologii i... po raz pierwszy stosujemy tę technologię na żywym projekcie u klienta. No nie.

Jeśli pracujemy na etacie i mamy dobrego mentora w pracy - ok, jak najbardziej. To jest idealny sposób nauki własnej. Natomiast jeśli działamy jako freelancer albo przedsiębiorca i sami obsługujemy klienta - najpierw warto nauczyć się nowej technologii na własnych projektach, a dopiero po nabyciu doświadczenia w danej technologii używać ją na produkcji u klientów.

To podejście robi się szczególnie niebezpieczne jeśli chodzi o programowanie sprzętu medycznego, bankomatów i podobnych sprzętów. Oto przykład stosowania nie do końca przemyślanej technologii, nad którą programista średnio zapanował:

Błąd spowodowany słabym doborem technologii