Sylwester już za nami, z nienacka nadszedł nowy rok. A nowy rok to czas noworocznych postanowień. Postarajmy się, aby w tym roku być lepszym developerem. Unikajmy 9 złych nawyków programistów.

Jako developerzy cały czas musimy się uczyć, cały czas się rozwijamy. Jednak jest grupa najpopularniejszych błędów, które cały czas popełniamy. W zasadzie błędy te są trywialne, każdy o nich wie, ale jednak nie udaje się nam ich unikać. Poniżej przedstawiam listę 9 złych nawyków programistów, które należy eliminować.

1. Nie robisz wystarczająco dużo przerw.

Wbrew pozorom jest to poważny problem. Wyjście na jedną czy dwie długie kawy dziennie nie rozwiązuje go. Chodzi tutaj o robienie regularnych, krótkich, nawet 5-minutowych przerw. Powiedzmy – co godzinę. Chwila spaceru po biurze, nawet po szklankę wody, chwila spojrzenia za okno (według badań poleca się patrzeć na zieleń) czy chwila po prostu niemyślenia o pracy. Pomaga to odświeżyć mózg, nabrać świeżego powietrza, zdystansować się od problemu. Po takich przerwach zwykle o wiele lepiej się nam pracuje.

Polecam tutaj technikę Pomodoro, o którym napisze obszerny artykuł niedługo. W skrócie – chodzi o to, aby pracować w cyklu:

  1. 25 minut pracy
  2. 5 minut przerwy
  3. 25 minut pracy
  4. 5 minut przerwy
  5. 25 minut pracy
  6. 5 minut przerwy
  7. 25 minut pracy
  8. 15 – 30 minut przerwy

4 cykle pracy po 25 minut, po 3 jest przerwa 5 minut, po czwartym jest przerwa od 15 do 30 minut. Pozwala to na bardzo ergonomiczną i wydajną pracę i jednocześnie cię nie zamęczy.

2. Nie prosisz o pomoc.

Błąd, który bardzo mnie dotyczył kiedyś i nad którym pracowałem bardzo długo. I nie tylko ja – bardzo dużo osób ma problem z proszeniem o pomoc. Jest po związane z naszą dumą, z naszym poczuciem własnej wartości i z tym, jak (w naszych myślach) wyglądamy dla otoczenia.

Każdy chce wyglądać profesjonalnie. Każdy chce być tą osobą, do której chodzi się po radę. Każdy chce być najlepszy w czymś. Nawet podczas nauki nowej rzeczy. Dlatego tez bardzo ciężko przyjmujemy policzek, jakim jest przyznanie się przed samym sobą, że czegoś nie umiem zrobić i potrzebuję pomocy.

Trzeba jednak spojrzeć na zespół jako ogół i cel, do jakiego dążymy. W zespole nie jesteś sam właśnie dlatego, że sam jeden nie dałbyś rady zrobić projektu w wyznaczonym czasie. Im więcej ludzi tym więcej doświadczenia, tym więcej różnej wiedzy i problemów, jakie się rozwiązało. Bardzo często w zespole już jest jakiś nieformalny podział na ludzi, którzy są najlepsi w X, inny w Y, inny lubią np. nie robić nowych rzeczy a posprzątać bugi i popracować nad jakością produktu i kodu.

I do tych ludzi powinieneś się zwracać z problemami. Jeżeli nad czymś schodzi ci za dużo czasu, zapytaj. Po pierwsze ty uzyskasz rozwiązanie lub radę, więc się nauczysz czegoś nowego. Po drugie, nie zawalisz terminu, przez co nie pogrążasz zespołu. Po trzecie, skoro się uczysz i rozwijasz, to zespół jest zadowolony z Ciebie. Same plusy 🙂

A nasza duma? Schowajmy ją do kieszeni, w końcu chcemy być lepsi. Prawda?

3. Tworzysz brzydki kod.

Problem dotykający dużo osób na początku drogi programisty, ale tez wielu doświadczonych tworzy nie najlepszy kod. Powoduje to po pierwsze dłuższy czas pracy kolejnych osób nad twoim kodem, brzydki wygląd repozytorium i bardzo często trudności w wyszukaniu bugów. Rozwiązanie? Czytać jak się robi dobry kod, czytać źródła np. bibliotek popularnych, gdzie kod jest na pewno dobry, dokształcać się, no i tworzyć. Tworzyć i pisać jak najwięcej, oczywiście jak tylko się nauczycie czegoś nowego to od razu to wdrażać w życie.

Polecam tutaj mieć swój projekt, średni wielkością, na którym się uczysz. Czytasz o czymś, wchodzisz w swój projekt, i refaktoryzujesz całość ręcznie, tak, aby ten kod poczyścić. Najlepiej zrób branch do czyszczenia kodu i tam po kolej wrzucaj commity ze zmianami pojedynczych rzeczy. Gwarantuje ci, że po 2 tygodniach takiej nauki jak porównasz sobie kod z początku i końca, to będzie niebo a ziemia.

4. Nie zachowujesz balansu między życiem i pracą.

Bardzo często na początku kariery dużo osób programuje 8 godzin w pracy, później 8 godzin w domu. Weekendy – programowanie. To wszystko po to, aby stać się lepszym. I samo pragnienie rozumiem, ale ten brak balansu, to poświęcenie wszystkiego tylko na programowanie jest szkodliwe. Po pierwsze, powoli stajecie się aspołeczni. W końcu przestaniecie kodzić po 16 godzin dziennie i okaże się, że mało kto chce z wami rozmawiać, bo nigdy nie masz czasu.

Po drugie, bardzo szybko się wypalasz. Programowanie prowadzi do wypalenia zawodowego, to jest fakt. Im więcej programujemy, tym szybciej nas dopadnie. Jeżeli już na początku poświęcasz wszystko dla kodowania, to ile czasu zajmie nim ciebie to dopadnie? 5 lat? 10? W końcu, w wieku np. 40 lat będziesz nienawidził tego, co robisz, a pracy nie zmienisz przez zarobki. I tak będziesz trwać w tym kole nienawiści.

Dlatego już od początku zadbaj o zdrowe podejście do pracy.

5. Nie uczysz się z błędów.

Dla mnie osobiście najpoważniejszy błąd. Jeżeli ciągle powtarzasz te same błędy, to jaki jest sens nauki. Jaki jest sens pomagania ci? Twój zespół może pomóc raz, drugi czy nawet trzeci z tym samym, ale jeżeli od roku powtarzasz dokładnie to samo, te same błędy, to w końcu ktoś się zdenerwuje. Tym bardziej nikt ci nie będzie chciał pomóc.

Dlatego zawsze, kiedy natrafiasz na problem i ktoś ci pomaga, a czegoś do końca nie rozumiesz, to czytaj, dopytuj, doucz się, drąż głębiej. Tak, abyś nie powtarzał tego samego błędu.

6. Za szybko się poddajesz.

Poważny błąd, który był moją przypadłością. Poddawanie się za szybko. Głównie dotyczy on nauki jakiejś technologii czy robienia swojego projektu, ale nie tylko.

Dlaczego tak się dzieje? Przeważnie, kiedy podejmujemy wysiłek, chcemy widzieć efekt od razu. Dlatego pokochałem frontend – zmieniałem parę linijek i widziałem, że cos się dzieje. Kiedy nasz efekt ma przyjść za parę dni, już średnio nam się chce. Kiedy nasz efekt ma przyjść za rok – nasza motywacja drastycznie spada. Aby temu zaradzić, polecam dwa sposoby.

Po pierwsze – dyscyplina. Trzeba w sobie wyrobić nawyk robienia czegoś. Przez pierwszy miesiąc może to być ciężkie, ale naprawdę się opłaca. W końcu przywykniemy do robienia czegoś o określonych godzinach czy w określonych warunkach i nie będziemy tego widzieli jako czegoś złego.

Po drugie – kontrak ze sobą. Podpiszcie sami ze sobą kontrakt, najlepiej na papierze, w którym zobowiążecie się, tylko przed samym sobą, do zrobienia czegoś. Niektórzy lubią deklaracje publiczne, przed kimś, i to jest ok. Jednak deklaracja przed samym sobą pozwala na jawne i klarowne postawienie się w sytuacji, gdzie nie ma wymówek i ucieczek. Miałem zrobić X, nie zrobiłem, moja wina. I przed tym uczuciem będziemy sami się chronili, co napędzi nas do działania.

7. Próbujesz nauczyć się wszystkiego naraz.

Kolejny błąd popełniany zwłaszcza na początku pracy jako programista. Próba nauki wszystkiego naraz. Jest to skazane na porażkę. Próbowaliście kiedyś uczyć się jednocześnie tańczyć i gotować? Nie? To, dlaczego próbujecie uczyć się 2 zupełnie różnych technologii? Że niby i tu, i tu klikasz w klawiaturę? No nie do końca, klikanie to samo, ale myślenie całkowicie różne. Przykład – próba nauki reacta i angulara jednocześnie. Całkowicie różne podejścia do komponentów, przekazywania danych, renderowania. Kompletnie różne światy. Dlatego, zamiast próbować np. w 100 godzin nauczyć się jednocześnie X i Y, poświęć najpierw 50 godzin na X a później 50 na Y. Gwarantuje ci, że efekty będą większe, kiedy będziesz się uczył po kolei niż jednocześnie.

8. Nie przyjmujesz konstruktywnej krytyki.

Najpopularniejszy błąd większości developerów. Kod traktujemy jako coś osobistego. Jak nasze wspaniałe dzieło. A później przychodzi ktoś i mówi, że do dzieło jest do wyrzucenia. I od razu odpala się nam agresja i postawa zamknięta. Uważamy też, że nasza godność, czyli poczucie własnej wartości, zostało zmniejszone. W tym wypadku mam jedną rade – pytaj. Zadaj pytanie klucz:


Co przez to rozumiesz?


Pytanie, które otwiera nam dwie drogi. Nawet największy hejter, zapytany o to, co rozumiem przez to, że twój kod jest do niczego, może:

  1. Chcąc niechcąc, wytłumaczy ci, dlaczego tak myśli. A wtedy i masz szanse porozmawiać, wybronić się, czy powiedzieć, dlaczego tak zrobiłeś, i uczysz się, bo pewnie od razu dostaniesz rady jak to poprawić.
  2. Hejtuje dalej i unika odpowiedzi. W takim wypadku – ignoruj i rób swoje, a jeżeli dalej jesteś atakowany – interweniuj wyżej. Bo jak to tak, ktoś cię obraża, a na prośbę wytłumaczenia dalej to robi? Nie ma to nic wspólnego z krytyką, a jest to zwykłe wyżycie się na kimś innym, i takie postawy trzeba tępić.

Oczywiście bardzo często dostajemy odpowiedź już w komentarzu i wtedy nie pozostaje nam nic innego, niż przełknąć ta gorzką pigułkę, uznać przed samym sobą, że jeszcze wiele masz do nauki, wyciągnąć lekcję i pracować dalej. Pokazuje to, że naprawdę jesteś dobrym człowiekiem i dobrym, profesjonalnym developerem.

9. Za bardzo się upierasz przy swoim.

Bardzo często upieramy się za bardzo przy swoim. Jesteśmy pewni swojego i nie przyjmujemy ani rozmowy, ani krytyki od innych osób. Ma być tak, jak mówisz i koniec, albo nie pracujesz. Taki szantaż.

Jeżeli ktoś zwraca ci uwagę, to albo czegoś nie wie i można by go czegoś nauczyć, wytłumaczyć, pomóc, albo ma lepsze rozwiązanie, albo ma wiedzę, której ty nie masz (np. inny algorytm, który działa o 5% szybciej). Szkoda, że zaprzepaszczasz te szanse przez swój upór. Przecież w projekcie nie chodzi, żeby było twoje rozwiązanie, tylko żeby projekt był dobry, działający, bez błędów, z czystym kodem. Jeżeli ktoś chce cos ulepszyć kosztem twojego kodu, to jeżeli tylko ma to podstawy, trzeba to zrobić jak najbardziej.

Moja rada – słuchaj. Rozmawiaj. Szukaj głębi w tych propozycjach czy pytaniach. Nie zakładaj, że tylko ty wiesz, co się dzieje, a reszta nie. To bardzo krzywdzące i dla innych, i w szczególności dla Ciebie.

Podsumowanie

Te 9 błędów najczęściej powtarza się w programowaniu. Wyeliminowanie ich wszystkich będzie bardzo trudne, jeżeli nie niemożliwe. Postaraj się jednak, gdyż praca nad sobą i nad tymi błędami sprawi, że będziesz lepszym programista, lepszym kolega z zespołu, i lepszym przyjacielem.

Spotkałeś się kiedyś z innymi popularnymi błędami? A może chciałbyś opowiedzieć swoją historię związaną z jednym z tych wyżej? Zapraszam do komentowania!



3 KOMENTARZE

  1. O tak! Kto nie popełnił żadnego z tych błędów w pracy, musiał zacząć programować jeszcze w podstawówce i to razem z grupą kolegów, żeby je z nimi popełnić!:P Opory przed pytaniem i proszeniem o pomoc w imię samodzielności i szanowania cudzego czasu pracy, były powodem mojego zwolnienia z pierwszej pracy w IT… Swój czas też warto traktować jak cenny i nie marnować na wynajdowanie koła po raz setny! Prosić o pomoc się opłaca 🙂

  2. Do tych błędów dopisałbym jeszcze awersję do korzystania z gotowych rozwiązań. Był to problem, który występował przynajmniej u mnie – na przykład miałem starszną niechęć do bibliotek pokroju bootstrapa, ponieważ miałem w głowie przekonanienie, że „przecież to cudzy kod, nic się nie nauczę jak go po prostu użyję…. muszę napisać coś swojego”.
    Nie można też przegiąć w drugą stronę i nie załatwaić każdego problemu w JS dodatkową paczką, czy dodoatkową wtyczką w WordPressie.
    Dzięki za wartościowy artykuł! 🙂
    Pozdrawiam

    • Prawda. Ta niechęć do gotowych rozwiązań jest częsta i ma różne podłoża. Czy to przekonanie, że niczego się człowiek nie nauczy, czy twierdzenie, że samemu się napisze lepiej, czy zbytnia oszczędność transferu. Czasami lepiej jest ściągnąć bootstrapa i go użyć niż samemu stracić parę dni, żeby osiągnąć to samo. Zwłaszcza, jak bootstrapa się ściągnie jako SCSS i samemu się skompiluje tylko to, czego się używa, przykładowo system Grid i np. modale. Inna sprawa, że przeglądarki same sobie casheują najczęstsze biblioteki z CDNów, więc jak używasz najnowszego bootstrapa na stronie, to jest spora szansa, że większość użytkowników już wchodziła na strony z tym bootstrapem i twoja strona załaduje się szybciej mając CDNowy lnk do bootstrapa, niż jakbyś stworzył swój build. Ale to taki smaczek 😀
      Co do pisania samemu lepiej – czasami się zdarzało i mi tak myśleć. A później wchodziłem w źródła bibliotek i je czytałem, i sam pisałem swoje odpowiedniki tych bibliotek, i jakbym nie kombinował i tak zawsze osiągnę max ten sam rezultat. Bo naprawdę rzadko jeden random z internetu budujący bibliotekę po godzinach zrobi ją lepiej niz zespół programistów przeznaczony tylko do tego i mający parę tygodni 😀
      A co do nauki – uważam że lepiej nie uczyć się pisania czegoś, co ci się mozliwe, że nigdy nie przyda (część bibliotek jest używana w 90% projektów, takie d3, jQuery, bootstrap, react czy angular) niż nauczyć się, ale stracić czas, który można przeznaczyć na naukę rzeczy bardziej w tym momencie wartościowych.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.