Praca programisty jest super ale czasem coś uwiera. Drobne małe rzeczy, które wkurzają i nie za bardzo można coś z nimi zrobić.  To mogą być typowe programistyczne problemy jak i  typowo zespołowe problemy. Tak czy inaczej poniżej moja lista 10 najbardziej irytujących rzeczy w pracy programisty. Jeśli zauważysz, że jakiejś brakuje to dopisz w komentarzu dorzucę do artykułu. Zapraszam do czytania.

Brak zaangażowania

Uwielbiam programować, tworzyć kod i rozwiązania, podniecać się na kolejne wersji oprogramowania, testować nowe rozwiązania i  ciągle mi się wydaje, że własnie takie dobre zaangażowanie to podstawa w tej pracy. Jednak nie każdy tak ma.. Widzę młodych programistów, którzy może zachęceni wysoką kasą zamiast kombinować, szukać rozwiązań to idą na skróty i starają się wszystko zrobić szybko. Płytkie myślenie, praca ze StackOverflow i o 16 do domu. W domu tylko odpoczynek i rozrywki, następny dzień znowu, jeśli coś już muszą poznać to tylko uczą się w pracy a w domu już nie.

No cóż, nie każdy musi być zaangażowany i chętny do pracy ale i tak mnie to dziwi, że programista może nie lubić swojej pracy.

Trzeci rodzaj programisty

Kiedyś słyszałem na konferencji, że programiści dzielą się na 3 rodzaje. Pierwszy to RockStarProgrammer– super programista wszystko robi zawsze dobrze. Nikt nie może o sobie powiedzieć, że jest kimś takim, tylko ktoś Ci może powiedzieć, że nim jesteś. Drugi to dobry programista czyli taki, który robi ogólnie wszystko dobrze a gdy ktoś lepszy do niego zwróci mu uwagę, że robi coś źle to przestaje robić źle i robi już dobrze. Pewnie większość z Nas należny do tej grupy. No i tytułowy 3 rodzaj najbardziej wkurzający – robi coś źle, mówią mu, że robi źle a on nadal tak robi źle i nie zwraca na to uwagi.

No cóż brak komentarza. Jest to frustrujące, szczególnie jak przez takiego jego mościa, musisz poprawiać mnóstwo błędów. Zdarzają się tacy ludzi i ciężko czasem coś z tym zrobić, szczególnie w małych zespołach. Zdarza się to i u młodych i u starych.

Nie działające tutorial-e

Do tego się już przyzwyczaiłem ale jest to nadal wkurzające. Może kojarzycie – ciekawa biblioteka, siadacie z zaangażowaniem do poznawania jej, szybki start tutorial, punkt po punkcie wszystko robicie i nagle błąd. Nie wiadomo o co chodzi. Sprawdzacie czy się nie pomyliliście i wtopa, wszystko zrobiliście dobrze a rozwiązanie nadal nie działa.

Na końcu się okazuje, że albo wersja się zmieniła i nie został zaktualizowany tutorial albo autor pominął jakiś punkt w czasie tworzenia go. Na początku to mocno zniechęca ale jak się człowiek przyzwyczai to już da się z tym żyć.

Szef za plecami

To może nie jest typowa wkurzająca rzecz dla programisty ale dla każdego zawodu. Coś nie działa, przychodzi szef (z doświadczeniem programistycznym z lat 70), tłumaczysz mu co i jak on chce zobaczyć kod, pokazujesz mu a on zaraz się dopytuje co i jak i nagle ogłasza tezę – daje rozwiązanie „quick and dirty” i każe to zrobić. Ty mu mówisz, że to nie takie proste a on „no ale…” i każe Ci coś zrobić co wiesz, że może nie pomóc i do tego śmierdzi.

Do tego czasem się zdarza się, że szef patrzy jak piszesz kod, jest to mocno wkurzające (przynajmniej ja tego nie lubię). Jest to nawet nazwane jako mikro-zarządzanie i jest to zaburzenie w kierowaniu zespołem.  Siedzi za Tobą szef i mówi, „spacja”, „literówka”, „jeszcze średnik”, „dlaczego tak „, „zrób inaczej”. Koszmar.

Mam na to sposób: mówię wprost, że nie pracuje w taki sposób i jak chce abym to zrobił to ma mi dać spokój. Działa bardzo dobrze i reguluje relacje. Polecam!

Szef mówi jak to zrobić

Nie zdarza się to często ale jednak. Programiści z większym doświadczeniem już takich sytuacji nie mają. Tak czy inaczej… zdarzają się czasem przełożeni, którzy oprócz tego, że powiedzą Ci CO masz zrobić to mówią Ci jeszcze JAK to masz zrobić. Niektórzy co ciekawe są bardzo dokładni w mówieniu JAK to zrobić. Potrzebujesz klasy i tam musi być metoda, która sprawdzi w tej zmiennej to i tamto.

Jest to wkurzające, bo młodzi się słuchają i robią tak, co w większość przypadków prowadzi do degeneracji kodu i problemów. Ja miałem na początku taka taktykę, że kiwałem głową i robiłem to inaczej a, że potem wszystko działało to i wilk syty i owca cała. Zrezygnowałem z tego.

Lepiej jest jednak zapytać czy możesz to zrobić po swojemu, bo po prostu będzie lepiej.

Programista = informatyk

To już klasyk z rzeczy, które wkurzają. Teraz może ten efekt jest mniejszy. Tak czy inaczej… Jeśli jesteś programistą to na pewno wg znajomych i rodziny umiesz: składać komputery, znasz się na kartach graficznych, pamięci ram, drukarkach i tonerach (no jak to nie). Na konfiguracji laptopów i oczywiście instalacji sterowników. Dodatkowo zawsze wiesz gdzie można ściągnąć najnowsze filmy, kodeki (kiedyś z tym był zawsze problem) i napisy. Wiadomo no dobrze być ogarniętym w te tematy ale bez przesady. Nie każdy programista to administrator albo cieć komputerowy.

Wymagania biznesowe

Cóż to jest trudny i złożony temat – najbardziej wkurzające jest to, że czasem dostajesz wymagania, które są spójne i sensowe. Piszesz rozwiązania, starasz się, robisz to zgodnie z najlepszymi praktykami a  za jakiś czas, przychodzą zmiany koncepcji i z perspektywy klienta zmiana jest niewielka ale z perspektywy kodu to koszmar. Najlepiej by było napisać od nowa. Czasu nie ma no i powstają długi programistyczne : )

Budowanie aplikacji z repozytorium

Ściągam aplikację  z git-a nad którą pracuje cały zespól. Kompiluje i 2300 błędów. To jest wkurzające, że niby ciągła integracja ale i tak nie sposób czasem normalnie jak człowiek ściągnąć aplikacji i odpalić. Generalnie jasne, nie każda aplikacja tak powinna od razu chodzić ale czasem tylko „tajemna wiedza”, któregoś z pracowników pozwala pokonać te 2300 błędów. A gdzie dokumentacja, szybki start?

Osobiście staram się albo utrzymać aplikacje tak aby po ściągnięciu świeżej odpalała się bez problemu lub pisze jasną dokumentacje jak ją odpalić. Co ważne staram się aby ta instrukcja była widoczna i dostępna. Super się do tego sprawdza „Readme.md” w repozytoriach, które ładnie się formatuje i organizuje tekst.

Rozproszenia

Pracujesz, kod się w głowie kreci, rozwiązanie się układa, wzorce powstają, jesteś na 3 poziomie właściwej warstwy, masz w pamięci 4 schowki z potrzebnymi danymi i nagle… „Cześć, widziałeś może ten nowy artykuł?”. Wszystko uchodzi z pamięci.

Myślicie sobie, że słuchawki pomagają?! Tak, pomagają się wyłączyć ale i tak zdarza się co jakiś czas jakieś ręce  machają i chcą się wyciągnąć ze strefy komfortu programistycznego.

Najchętniej ogłosił by etykietę, gdzie ustalona by momenty gdy można przeszkadzać programistą i momenty gdy nie wolno im przeszkadzać.  Myślę, że w obrębie zespołu by to mogło zadziałać.

Aby się skupić używam Pomoro. Używam też narzędzia Kanbanflow i mam statystyki, kto kiedy mi przeszkadza.

Drobne błędy

Nich rzuci ten kamieniem, kto nie robił małych, malutkich błędów. Wiecie, wszystko działa i się okazuje, że brakuje jakiegoś jednego tłumaczenia, że gdzieś jest za dużo jedna spacja, że zabrakło średnika. I ta myśl, że sama zmiana zajmie 100ms a klikania po jirze, testowania na ciągłej integracji i aktualizacja pół dnia. Ta świadomość, ze wszystko jest prawie dobrze, prawie perfekcyjnie. Tak to czasem jest, szczególnie gdy pracy dużo a czasu mało.

Podsumowanie

Bez komentarza.

Coś na polepszenie humoru gdyby komuś się popsuł po przeczytaniu tego posta: https://joemonster.org/art/27817

A tu inny artykuł w podobnej tematyce: https://techbeacon.com/14-things-developers-love-hate