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, że zaskakująco mało początkującym mówi się o tym, że 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, nawet do krótkiego kawałka kodu. I założę się, że 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ń, że 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ę, że 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śli chcecie pomóc mi rozwijać tę serię, wejdźcie na moje zapisane Stories na IG 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, że 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, że 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ę, że ważna jest świadomość, że 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, że 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śli 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 szybko 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, że często bardzo trudno nam się odciąć, od tego, co stworzyliśmy. Czy Ty, jako doświadczony programista, możesz powiedzieć, że całkowicie “na chłodno” umiesz już przyjąć krytykę swojego kodu? Jeśli 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śli 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ę, że 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 niewiele 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, że 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 szybko niszczy wszelkie bariery w zespole. Tym mniej doświadczonym osobom pozwala dostrzec, że seniorzy też często mają problem z implementacją wymaganych funkcji i nie wszystko przychodzi im łatwo. Seniorzy zaś mogą szybko 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 zazwyczaj 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, że 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ę, że 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, że 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, że zaczynamy od pozytywów, następnie dajemy konstruktywną krytykę i kończymy również pozytywnym podsumowaniem. Przykładowo: „Asiu, bardzo się cieszę, że zaczęłaś pracę nad tym trudnym taskiem! Wydaje mi się jednak, że lepszym podejściem byłoby XX, ze względu na to, że YY i to sprawi, że 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, że 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, że to pierwszy wpis w serii, więc warto śledzić fanpage i Instagram, 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ę pod postem o kryzysach w nauce programowania).
Faktycznie, problem podejścia do przeglądów kodu i zwracania uwagi na błędy lub niedoskonałości jest poważny. Szczególnie, że z jednej strony mamy zazwyczaj doświadczonych programistów i architektów, mających często mało czasu na przekazanie swoich uwag (a mających ich dużo), a z drugiej początkujących, którzy często nie wiedzą, jak dużo lepszy może być ich kod i faktycznie mogą odbierać co bardziej suche negatywne komentarze jako “znęcanie się”, a nie doskonalenie kodu i pomoc w uczeniu się.
Zdecydowanie polecam wtrącać do przeglądów pozytywne komentarze. Oczywiście nie można przesadzać, firmy nie są od niańczenia 😉 ale dobre słowa nigdy nie zaszkodzą.
O podobnych kwestiach pisałem już ze trzy lata temu:
* https://www.swiat-owocow.pl/1200.html
i zaproponowałem też nowy – może dla kogoś ciekawy – ale bardzo trudny sposób przekształcenia przeglądów kodu w narzędzie doskonalenia produktu:
* https://www.swiat-owocow.pl/1201.html
Chyba jednak nikt się nie zdecydował jeszcze na podążanie w tę stronę.
Dzięki za ten wpis, dał mi chwilę na refleksję jeśli chodzi o podejście do swojej pracy! Choć jestem otwarta na szczerą opinię i krytykę bardziej doświadczonych devów nadal największym katem jestem dla siebie ja sama. Łatwo się stresuję myślą, że mój kod mógłby byc napisany lepiej czy szybciej, albo, że robię jakąś błahostkę na tle innych tasków. Wiem, że to jeszcze kwestia czasu i praktyki, ale czasami nie jest łatwo.
To prawda, sami często jesteśmy swoimi najbardziej surowymi krytykami. A w sumie kod można poprawiać w nieskończoność, więc warto nauczyć się, że zrobione często bywa lepsze od doskonałego 😉
Dzięki za komentarz! Z doświadczenia powiem, że dobre słowa dla juniora naprawdę mogą wiele znaczyć, warto o tym pamiętać. Super, że podzieliłeś się wpisami, zaraz poczytam 🙂
Dzięki za ten artykuł! Każdy team lead powinien go przeczytać, bo wygląda na to, że czasem naprawdę drobne zmiany w komunikacji mogą bardzo pozytywnie wpłynąć na współpracę 🙂
Pozornie małe rzeczy są najważniejsze 🙂 Dzięki za miłe słowa, cieszę się, że artykuł się podoba!
Bardzo fajny artykuł. Wiele cennych kwestii jest w nim zawarte.
Podczas dawania feedbacku w CR ważne jest, aby był oceną kodu, a nie osoby, która go pisała. Warto też pisać komentarze w formie pytającej np. “czy nie uważasz, że X byłoby lepsze zamiast Y?”. Osoba, która pisała ten kod podczas czytania takich komentarzy będzie sobie odpowiadać na pytanie zamiast myśleć o tym, że to krytyka. Każdy programista musi mieć świadomość, że CR ma pomóc ulepszyć kod – a przy okazji wszystkie osoby biorące w niej udział mogą się czegoś nauczyć, poznać czyjeś spojrzenie na ten sam problem.
Czasami nawet doświadczony programista może mieć wiele komentarzy w CR – trzeba o tym pamiętać, ponieważ nikt nie jest nieomylny.
Trzeba o tym przypominać wszystkim cały czas – zarówno juniorom, mid i seniorom (tutaj raczej najmniej) – jeżeli dojdzie do takiej sytuacji w komentarzu. Kultura i szacunek w pracy (także w code review) są bardzo istotne.
Dzięki za miłe słowa i cenne uwagi! To prawda, celem code review jest jak najlepszy kod i tylko kodu powinny dotyczyć uwagi, nie osoby, która go pisała. Warto o tym pamiętać 🙂
Pamiętam swój feedback 🙂 wracanie do kodu po roku to jak wejście w zarośnięta dżunglę :)) nie wiadomo co jak gdzie… i dopiero wtedy jest nauka – ” po co jak tak pisze” …. Nawet analizowanie kodu innych osób jest mega plusem, w zasadzie w każdej formie czy jest to napisany przez dobra osobę czy prze lajka zawsze można wyciągnąć wnioski 🙂
O tak, przeglądanie własnego kodu po czasie też potrafi być bardzo ciekawe. I wtedy sami widzimy, co jeszcze mogliśmy poprawić 😉