Jesteś osobą, która dopiero uczy się kodowania albo stawia pierwsze kroki w pracy jako junior developer? Chcesz wiedzieć, jak przygotować się na feedback w code review? Jak wyciągnąć z niego lekcje? Ten wpis jest dla Ciebie!
Uważam, iż zaskakująco mało początkującym mówi się o tym, iż nie wystarczy, by kod działał. Kiedy taka osoba wrzuca swój kod w grupie na FB albo idzie do pierwszej pracy, może się zdziwić, jak wiele otrzymuje komentarzy, choćby do krótkiego kawałka kodu. I założę się, iż nie będzie tam komentarzy pozytywnych. Trudno się dziwić, wprawy w kodzie nabiera się z czasem.
Niestety, lawina sugestii, co w kodzie trzeba poprawić albo po prostu stwierdzeń, iż przecież to rozwiązanie jest do niczego, może skutecznie zniechęcić do dalszej nauki. A przecież nie o to chodzi! Każdy początkujący powinien zdać sobie sprawę, iż feedback, jaki dostaje podczas code review, jest ogromnie cenny. Trzeba się jednak nauczyć go przyjmować, aby wyciągnąć z komentarzy jak najwięcej.
Ten wpis jest początkiem serii o roli feedbacku podczas nauki programowania i pracy jako programista. jeżeli chcecie pomóc mi rozwijać tę serię, wejdźcie
i odpowiedzcie na pytanie tam zadane. To bardzo pomoże mi planować kolejne artykuły. A teraz zaczynamy rozmowę z moim gościem. Temat to: feedback w code review.
Do rozmowy zaprosiłam Michała Miszczyszyna, full-stack developera i leadera zespołu z wieloletnim doświadczeniem, założyciela firmy szkoleniowej Type of Web (pełne bio Michała znajdziecie na końcu wpisu). Michał udzielił naprawdę świetnych rad, które przydadzą się zarówno początkującym, jak i osobom, które sprawdzają kod, a tym samym udzielają feedbacku. Poczytajcie!
Załóżmy, iż dostajemy pierwszą pracę jako junior developer, piszemy pierwsze linijki kodu, oddajemy kod do code review i… sypie się lawina komentarzy. Wszystko jest nie tak! Mnie to spotkało podczas pierwszego code review i przyznam, iż byłam totalnie przerażona. Jak sobie poradzić z negatywnym feedbackiem, jaki dostajemy podczas code review?
Michał: Też mnie to spotkało w pierwszej pracy. Napisałem dosłownie kilka linii kodu w HTML-u i BUM! Dostałem lawinę komentarzy punktujących, co zrobiłem źle. Jak można sobie z tym radzić? Myślę, iż ważna jest świadomość, iż krytyka służy rozwojowi, a każdą negatywną opinię można zamienić w pozytywne działanie. To może być niezwykle trudne na początku, gdy brak nam jeszcze perspektywy, bo dopiero zaczynamy pracę. Warto jednak pomyśleć o tym, iż osoby, które dają nam taki negatywny feedback, wcześniej popełniały podobne, a często dużo gorsze błędy i swoimi uwagami chcą nam pomóc. Taka kolej rzeczy. I jeżeli kiedykolwiek pomyślisz „nikt nie zrobił nigdy czegoś tak głupiego, jak ja teraz” to na pewno się mylisz i to milion razy
Czy są według Ciebie jakieś sposoby, które pozwolą juniorom lepiej podejść do tematu? Czy np. wrzucanie swojego kodu na grupach na FB, zanim jeszcze dostaniemy pracę, jest dobrym pomysłem?
M.: Z grupami to jest świetny pomysł! Z jedną małą uwagą: bardzo często bardzo gwałtownie na tych najpopularniejszych grupach robi się w komentarzach bagno, a zamiast konstruktywnej krytyki dostajemy festiwal hejtu. Trzeba bardzo uważać, gdzie się wrzuca swój kod, żeby wynieść z tego coś pozytywnego i przydatnego. Polecam mniejsze grupy o wąskiej specjalizacji, nacelowane na dawanie feedbacku np. “Weekly WebDev Challenge” albo “Discord polski front-end i back-end” i kanał #code-review.
Jedną z pierwszych rzeczy, jaką usłyszałam w pierwszej pracy jako junior, gdy byłam dość przybita niezbyt pozytywnym code review, było “nie jesteś swoim kodem”. Jednak wiemy, iż często bardzo trudno nam się odciąć, od tego, co stworzyliśmy. Czy Ty, jako doświadczony programista, możesz powiedzieć, iż całkowicie “na chłodno” umiesz już przyjąć krytykę swojego kodu? jeżeli tak, co Ci w tym pomogło?
M.: Zawsze czuje się pewne emocjonalne przywiązanie do swojego kodu, ale z upływem lat jest ono zdecydowanie mniejsze. Najbardziej mnie początkowo przybijało, gdy to, co dopiero napisałem było wyrzucane do kosza albo wymagało całkowitego przepisania z powodu zmiany wymagań albo koncepcji. To bolało. Podobnie z code review, pierwsze z nich dotykały mnie osobiście. Każdy skomentowany błąd w kodzie wydawał się być wytykaniem mi jakichś wad. Trzeba próbować przerwać to przywiązanie do kodu, wdrażać poprawki i dbać o to, by kod był po prostu dobry, a nie tylko „nasz”.
Służy temu wiele różnych ćwiczeń, ale to absolutnie nie rola juniora, aby je przeprowadzać. To praca dla team leadów, aby stworzyć odpowiednią atmosferę pracy w zespole, wzajemnego zaufania i empatii.
A jeżeli chodzi o drugą stronę, czyli osoby bardziej doświadczone komentujące kod – co one mogą zrobić, aby feedback lepiej trafiał do juniora?
M.: Jestem Tech Leadem zespołu i wiem, jak niewłaściwie sformułowana krytyka może prowadzić do konfliktów, braku wiary w siebie, utraty motywacji i zaufania, a tego chyba żaden lider nie chce. Myślę, iż przede wszystkim trzeba spróbować postawić się na miejscu drugiej osoby — wspomniana empatia. Przychodzi mi do głowy kilka porad.
Po pierwsze, nie zrzucam na juniorów 30 pozbawionych emocji komentarzy na raz, bo to najgorsze, co mógłbym zrobić. Chyba nikt nie jest w stanie przyswoić tylu negatywnych informacji zwrotnych jednocześnie, a samoocena pikuje! Staram się przypomnieć sobie, jak kilka umiałem na początku i jak chciałbym, aby mnie ktoś wtedy traktował, i tak traktuję innych.
Po drugie, zawsze opisuję nie tylko *co* ma zostać poprawione, ale przede wszystkim *dlaczego* po zmianie kod będzie lepszy. Bez tej informacji moje komentarze byłyby całkowicie bezwartościowe, bo nie nauczyłyby drugiej osoby absolutnie niczego. Wymuszanie nawyków i zmian bez ich zrozumienia to tresura, a nie edukacja.
Wreszcie, po trzecie, automatyzuję jak najwięcej code review. Są takie błędy, które się często powtarzają — wtedy dopisuję je do naszego bota, wraz z linkami i informacjami o tym, dlaczego coś jest źle i jak to poprawić. Bot automatycznie wykrywa błąd w kodzie i zostawia komentarz. Oprócz tego, iż ułatwia to pracę mi, jest też druga ogromna zaleta: takie komentarze od bota nie zostaną potraktowane osobiście. Nie ma w nich żadnego ładunku emocjonalnego.
Pod linkiem “README” jest długi rozdział na temat tego, dlaczego, jak i co należy zrobić.
Na koniec, to co polecam i absolutnie uwielbiam, to organizowanie sesji pracy w parach lub wręcz grupach. To gwałtownie niszczy wszelkie bariery w zespole. Tym mniej doświadczonym osobom pozwala dostrzec, iż seniorzy też często mają problem z implementacją wymaganych funkcji i nie wszystko przychodzi im łatwo. Seniorzy zaś mogą gwałtownie zlokalizować części logiki biznesowej, które sprawiają trudności początkującym i wyciągnąć pewne wnioski. Czy kod jest nieczytelnie napisany? Czy dana część aplikacji nie jest zrozumiała dla nowych osób? Czy może w ogóle nie ma nigdzie informacji _po co_ nam dany fragment logiki? Takie sesje bardzo ułatwiają wyłapanie i poprawę tego typu problemów.
W code review zwykle szukamy błędów i niestety zdarza nam się tylko na tym skupiać. Czy według Ciebie pokazywanie pozytywów w kodzie ma sens? Czy nie jest to takie trochę “lukrowanie” rzeczywistości, szczególnie gdy w kodzie nie ma żadnych super nowatorskich rozwiązań? Co sądzisz?
M.: Zawsze komentuję rozwiązania w kodzie, które mi się podobają albo zaskakują. Każdemu należy się pochwała za dobrze wykonaną pracę! Jednak nie wydaje mi się, aby pisanie takich komentarzy na siłę miało sens. Mówię tu o samym code review, bo zupełnie inaczej jednak wygląda dawanie informacji zwrotnej komuś w czasie rozmowy 1:1. Tutaj pozytywna krytyka jest absolutnie niezbędna! Są różne typy charakterów i wierzę w to, iż każdy wnosi jakąś wartość do zespołu — trzeba tylko umieć ją odnaleźć.
Początkowo frustrowało mnie, gdy ludzie robili rzeczy inaczej, niż ja sam bym zrobił. Jednak po pewnym czasie zdałem sobie sprawę, iż to problem nie z nimi, tylko ze mną i wynikał on z niezrozumienia pracy w zespole oraz złego nastawienia. Każdy patrzy na świat inaczej, a różne rozwiązania mogą być tak samo dobre. Dla jednej osoby coś będzie banalne, a inna się na tym samym zadaniu zablokuje. Siłą zespołu jest to, iż razem możemy więcej. A krytykowanie bez słowa pochwały zabija morale i tę siłę zespołu niszczy.
Mam jeszcze dwie krótkie porady. Bardzo dobrą metodą dawania feedbacku jest metoda kanapki albo hamburgera. Polega ona na tym, iż zaczynamy od pozytywów, następnie dajemy konstruktywną krytykę i kończymy również pozytywnym podsumowaniem. Przykładowo: „Asiu, bardzo się cieszę, iż zaczęłaś pracę nad tym trudnym taskiem! Wydaje mi się jednak, iż lepszym podejściem byłoby XX, ze względu na to, iż YY i to sprawi, iż nasz kod będzie bardziej spójny. Ogółem świetna robota, nie mogę się doczekać, jak to wdrożymy na produkcję.”
Druga porada to unikanie słowa „ale”. To jedno krótkie sformułowanie może całkowicie zniszczyć wszystko, co chcemy przekazać. Przykładowo, zdanie „jesteś świetną programistką, ale musisz poprawić swoją aktywność na callach” zdecydowanie nie zostanie odebrane jako pochwała, mimo dobrego początku. Jak to naprawić, aby zmienić ten negatywny ładunek, ale jednocześnie dać wartościową informację zwrotną? „Pomimo Twojej małej aktywności na callach, uważam, iż jesteś świetną programistką”. Gotowe. Wilk syty i owca cała.
Michał Miszczyszyn – Zmotywowany full-stack, który nie boi się żadnej technologii. Doświadczony programista i leader zespołów. Przedsiębiorca, aktywista, bloger, prelegent i nauczyciel.
Twórca DevFAQ: Największej społecznościowej bazy pytań z technicznych rozmów rekrutacyjnych.
Założyciel firmy szkoleniowej Type of Web. Tworzy i prowadzi warsztaty z takich technologii, jak: JavaScript, React, Vue, Angular, Node.js, TypeScript, ReasonML i innych.
Twórca społeczności, prowadzi i zarządza największą siecią spotkań programistycznych w Polsce: meet.js. Organizator kilku edycji konferencji meet.js Summit z ponad 500 uczestnikami i uczestniczkami na każdej.
Uwielbia typy, języki funkcyjne, programowanie w parach i dzielenie pomysłami.
Macie coś do dodania w temacie feedbacku podczas code review? Podzielcie się w komentarzu! Przypominam, iż to pierwszy wpis w serii, więc warto śledzić fanpage i
, aby nie przegapić kolejnych części.
P.S. Jak pewnie widzicie, jestem bardziej aktywna na Instagramie, gdzie również Was zapraszam (super dyskusje ostatnio toczyły się
).
