Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

5 złych nawyków nieefektywnego programisty

Ravi Shankar Rajan Program Manager / SAP Delivery Manager
Poznaj nawyki i postawy, które mogą utrudniać Ci efektywne programowanie.
5 złych nawyków nieefektywnego programisty

Źli programiści nie są głupi. Po prostu mają złe nawyki. Wszystkich programistów można podzielić w taki sposób: niektórzy są absolutnie genialni, niektórzy dobrzy, większość jest co najmniej kompetentna, niektórzy są ledwo kompetentni, a pozostali naprawdę tragicznie pracują.

I różnica między dobrym i złym programistą niekoniecznie dotyczy umiejętności kodowania. Dotyczy czegoś prostszego - złych nawyków. A te trudno zmienić zarówno w życiu, jak i w pracy.

My, programiści, możemy często popadać w złe nawyki podczas kodowania, które będą powstrzymywać nas przed uzyskaniem pełnego potencjału. Podczas gdy niektóre przyzwyczajenia mogą pomóc nam przyspieszyć pracę, inne mogą wyrządzić szkody zarówno zawodowo, jak i życiu osobistym.

Często nawet nie zdajemy sobie sprawy z istnienia naszych destrukcyjnych postaw. Potrzebujemy wtedy kogoś, kto rzuci na nie światło. Podobnie jak w życiu, w programowaniu nie ma tylko twardych i niepodważalnych zasad. Czasami po prostu improwizujesz.

Przyjrzyjmy się złym nawykom programistycznym, których powinieneś pozbyć się jak najszybciej.


Mój kod jest NAJLEPSZY

Friedrich Nietzsche podsumował to idealnie:

“Za każdym razem, gdy się wspinam, towarzyszy mi pies o imieniu Ego.”

Ludzie, których potrzebuje każdy zespół, to ludzie pokorni, głodni rozwoju i inteligentni. Pokorni, czyli mający pokorne małe ego, skupiający się bardziej na kolegach z zespołu niż na sobie. Głodni, czyli solidnie pracujący, zdeterminowani, aby rozwiązywać wszelkie zadania i problemy i wnosić swój wkład w każdy możliwy sposób. Inteligentni, co oznacza nie intelekt, a inteligencję emocjonalną.

Nie krytykuj kodu innych. Zamiast tego staraj się dokonywać obiektywnych i profesjonalnych obserwacji bez zbędnych osądów. Bądź pokorny i staraj się uczyć od wszystkich wokół.

Zawsze pamiętaj, że Twoje ego jest przeszkodą w Twojej pracy. Jeśli zaczniesz wierzyć w swoją wielkość, będzie to śmierć Twojej kreatywności. Nauka kończy się w dniu, w którym zaczynasz wierzyć, że nie ma już niczego do nauki.


Naprawię to ekspresowo

Angela Duckworth powiedziała:

“Nie ma skrótów do prawdziwej doskonałości.”

Zrób sobie przysługę. Pozwól sobie na jak najlepsze wykorzystanie swojego życia. Jeśli spędzasz cały czas na “szorowaniu kątów” za pomocą szczoteczki do zębów, nie rozumiesz całości. Korzystanie ze skrótów nie oznacza przyspieszenia wyniku końcowego.

Pójście na skróty jest bardzo kuszące, wszyscy to robią. Są sytuacje, w których są one konieczne, ale mogą być niebezpieczne i należy ich unikać. Skrót, który będzie nieadekwatny, może zaoszczędzić początkowo kilka godzin, ale później powodować miesiące bólu i dodatkowo utratę reputacji.


Pamiętam wszystko. Nie potrzebuję dokumentacji

Dick Brandon powiedział:

“Dokumentacja jest jak seks - jeśli jest dobry, to bardzo bardzo dobrze. Jeśli jest zły, to nadal jest lepszy niż jego brak.”

Dokumentacja jest gorzkim lekarstwem programowania. Menedżerowie uważają, że jest dobra dla programistów, a programiści jej nienawidzą!

W przypadku najlepszych programistów, pisanie dokumentacji to nieodłączna część ich codziennej rutyny.

Zdają sobie sprawę, że podobnie jak w przypadku każdej funkcji biznesowej, zespoły programistów również się zmieniają. Programiści mogą przejmować inne zadania, przenosić się między działami lub odchodzić na emeryturę. W najgorszym przypadku choroba, uraz lub śmierć mogą odsunąć członków zespołu od projektu, gdy najmniej się tego spodziewasz.

Kod też się starzeje. Programiści mogą łatwo zapomnieć o zawiłościach własnego kodu, jeśli nie dotykają go przez rok lub dłużej.

W każdym z tych scenariuszy, posiadanie lub nie posiadanie dokumentacji projektowej, specyfikacji API, manuali i komentarzy do kodu, może oznaczać różnicę między dostarczonym produktem a przekroczonym terminem/deadlinem.

Nie staniesz się „niezastąpiony” przez celowe pomijanie dokumentacji. Wszystko, co uzyskasz, to ciężki do usunięcia ciężar dla Twojego zespołu.


To nie ja!

Bruce Lee miał rację mówiąc:

Błędy można zawsze wybaczyć, jeśli ktoś ma odwagę się do nich przyznać.

Powyższego stwierdzenia nie można lekceważyć i być może jest to jedna z najważniejszych cech naprawdę świetnego programisty.

Zawsze mamy usprawiedliwienie... To tak, jakbyśmy mówili, że w innych warunkach nigdy nie popełnilibyśmy błędu, co nie ma tak naprawdę sensu.

Źli programiści obwiniają klientów za niewłaściwe używanie produktu. Zły programista nie bierze odpowiedzialności za cały produkt i jego błędy. Zapewnia, że to kto inny popełnia błędy na różnych etapach. A co dokładnie osiąga, obwiniając innych? Nic.

Zdrowe podejście, w którym możesz po prostu powiedzieć coś w stylu: „tak, przepraszam, teraz musimy zrobić to, aby rozwiązać ten problem, moja wina”, pomoże Ci zbudować reputację i być poważanym przez współpracowników.

Im wcześniej przyznasz się do swoich błędów, tym więcej czasu będziesz mieć na naukę i ich naprawę.


Twoje “GOTOWE” nie zawsze jest gotowe

Rick Lemons powiedział:

“Nie zmuszaj użytkownika do podawania informacji, które system już zna.”

Gdyby programowanie było seksem, byłoby wiele niezadowolonych komputerów. Nie możesz po prostu wejść, zrobić czegoś tylko w połowie, a potem zasnąć. Jedną z koncepcji, z którą możesz się zmagać, jest koncepcja, że coś jest gotowe.

Pamiętaj, że “gotowe” oznacza: przetestowane i zatwierdzone przez użytkownika, zgodnie z jego wymaganiami. Twoje zakończenie pracy nie wystarczy, aby uznać produkt za gotowy.

Dobry programista chętnie uczy się nowych rzeczy. Stara się zrozumieć, w jaki sposób wszystkie elementy architektury współpracują ze sobą i w jakim są stanie. Kwestionuje projekt i idee stojące za funkcjami całego rozwiązania. Rozumie, co daje wygodę użytkowania.

Natomiast zły programista jest przywiązany do swojej ulubionej technologii. Uważa, że ta jedna metoda lub proces są „idealne”, a doświadczenie użytkowników i jego sytuacja nigdy nie powinny determinować rozwiązania. Wprowadza niepotrzebne zależności do projektu, aby dopasować je do swoich preferencji.


Podsumowanie

Jakim jednym słowem można podsumować przekaz tego tekstu? To słowo to nastawienie.

Dobre nastawienie przewyższa posiadanie nawet wielu lat doświadczenia. Sama praca to za mało. Poza posiadaniem odpowiednich umiejętności, ważne jest właściwe podejście.

Dobre i otwarte podejście do pracy oraz pozytywne myślenie determinują to, co robisz i sprawiają, że jesteś bardziej produktywnym pracownikiem. To może określić, jak dobrze wykonujesz swoje projekty, a także jak postrzegają Cię inni. Dobre podejście jest zaraźliwe - wpływa na Twoje miejsce pracy.

Podsumuję to słowami Ziga Ziglara:

“Twoje nastawienie, a nie Twoje zdolności decydują, jak wysoko zajdziesz.”


Oryginał tekstu w języku angielskim przeczytasz tutaj.

Masz coś do powiedzenia?

Podziel się tym z 120 tysiącami naszych czytelników

Dowiedz się więcej