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

Nie jestem moim kodem

Chris Cooney Principal Software Engineer / Sainsbury's
Oto, co powinienieś sobie zapamiętać, jeśli chcesz być dojrzałym programistą.
Nie jestem moim kodem

Nie jestem bitami i bajtami, przecinkami i nawiasami, ani spacjami i tabulatorami. Wszelkie próby zmiany mojego kodu nie dotykają mnie personalnie i nie traktuję ich jako atak na moje dobre imię. Jest to normalne, jeśli nie piszesz kodu tylko “do szuflady”. Kod zmieni się tak, jak nie zamierzałem go zmieniać. Długo po tym, jak przestanę zajmować się projektem, inni inżynierowie będą próbowali zrozumieć, o co mi do diabła chodziło. Mój kod będzie poważany, wyśmiewany, ponownie zmieniany i recyklingowany, dopóki nie trafi do garbage collectora. NIE JESTEM MOIM KODEM.


Dlaczego to ważne, aby mieć tę świadomość?

Dużo mówi się o bezpieczeństwie psychicznym. Popularne publikacje, takie jak Raport DevOps 2019, poświęcają temu całe sekcje. W raporcie znajduje się następująca treść zaczerpnięta z Google Project Aristotle:

Pracownicy, będąc częścią zespołu, czują się bezpieczniej podejmując ryzyko.

— Raport o DevOps 2019

Członkowie zespołu czują się bezpiecznie podejmując ryzyko. Istnieje słowo kluczowe - bezpieczeństwo. Jak zdefiniować bezpieczny w tym szczególnym kontekście? Jak wygląda bezpieczne zachowanie przy omawianiu czyjegoś kodu?

Słownikowa definicja bezpieczeństwa pomaga zrozumieć zagadnienie dokładniej:

Stan bycia chronionym przed lub niskie prawdopodobieństwo wystąpienia niebezpieczeństwa, ryzyka czy urazu.

— Lexico

Co więc następuje, gdy przywiązujesz się zbyt mocno do kodu i traktujesz go emocjonalnie? A każda jego zmiana, czy rada albo pytanie z nim związane traktujesz jako atak? Odczuwasz niebezpieczeństwo.


Traktujesz bezpieczeństwo jako broń

Ale jak zrobić broń z bezpieczeństwa? Wygląda jak oksymoron. Jak wykorzystać stan unikania szkody, aby wyrządzić szkodę? Cóż, nie jest tak trudne, jak mogłoby się wydawać. Prześledź następującą rozmowę.

Inżynier 1: Widziałem rekurencję w tej funkcji. Martwię się tylko, co stanie się z dużymi zestawami danych?

Inżynier 2: Słuchaj, zrobiłem to najlepiej, jak potrafiłem. Powiedziano mi, że nie będzie dużych zbiorów danych.

Inżynier 1 zachował się odpowiednio. Powiedział zdanie grzecznie i kulturalnie, bez zarzucania winy. Przez ton odpowiedzi Inżyniera 2, oboje odczuwają teraz nieprzyjemne emocje. Albo będą kontynuować rozmowę, która raczej nie będzie przyjemna, albo zostawią sprawę tak jak jest, z prawdopodobnie błędnym kodem.

Inżynier 2 odrzucił uzasadnioną krytykę i zakończył dyskusję. Inżynier 1 już nie czuje się bezpiecznie. To nic innego jak gaslighting”, czyli forma przemocy psychicznej. Przy wystarczającej liczbie takich odpowiedzi, Inżynier 2 będzie miał dokładnie to, czego chce, czyli niepodważalny kod.


Nie ma znaczenia, kim jesteś

Nawet jeśli deweloper jest najbardziej uczonym z programistów, najbardziej doświadczonym, nie obchodzi mnie to. Jeśli nie chce, aby ludzie rozmawiali o jego kodzie i podsuwali mu rady, jest kiepskim inżynierem (i najprawdopodobniej niefajną osobą). Otwartość na opinie jest cechą dobrego inżyniera i dojrzałej, pewnej siebie osoby.


Nie pozwól, aby Ego zainfekowało Twoją bazę kodu

Jeszcze raz, zdecydowanie: Nie jestem moim kodem.

Lubisz dzielić się wiedzą i chcesz zostać autorem?

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

Dowiedz się więcej