W którym momencie „konstruktywna” krytyka twojego kodu staje się nieprzydatna?

Niedawno zacząłem jako młodszy programista. Oprócz tego, że jestem jedną z najmniej doświadczonych osób w zespole, jestem również kobietą, która ma wiele wyzwań związanych z pracą w środowisku zdominowanym przez mężczyzn. Ostatnio mam problemy, ponieważ mam wrażenie, że dostaję zbyt wiele nieuzasadnionej pedantycznej krytyki mojej pracy. Pozwól, że podam przykład tego, co się ostatnio wydarzyło.

Kierownik zespołu był zbyt zajęty, aby wcisnąć kilka gałęzi, które stworzyłem, więc dotarł do nich dopiero w weekend. Sprawdziłem pocztę, nie zamierzając wykonywać żadnej pracy, i odkryłem, że moje dwie gałęzie zostały odrzucone na podstawie nazw zmiennych, dzięki czemu komunikaty o błędach są bardziej opisowe i przeniesienie niektórych wartości do pliku konfiguracyjnego.

Nie uważam, że odrzucenie mojej gałęzi na tej podstawie jest przydatne. Wiele osób pracowało przez weekend i nigdy nie powiedziałem, że będę pracować. W rzeczywistości niektóre osoby prawdopodobnie zostały zablokowane, ponieważ nie miałem czasu na zmiany i ponowne przesłanie. Pracujemy nad projektem, który jest bardzo wrażliwy na czas i wydaje mi się, że nie jest pomocne całkowite odrzucenie kodu w oparciu o rzeczy, które są przezroczyste dla klienta. Mogę się mylić, ale wygląda na to, że tego rodzaju rzeczy powinny być obsługiwane w zatwierdzeniach typu patch, kiedy mam czas.

Teraz widzę, że w niektórych środowiskach byłaby to norma. Jednak krytyka nie wydaje się równomiernie rozłożona, co prowadzi do mojego następnego problemu. Podstawą większości tych problemów był fakt, że byłem w bazie kodu napisanej przez kogoś innego i starałem się być minimalnie inwazyjny. Naśladowałem nazwy zmiennych używane w innym miejscu pliku. Kiedy to stwierdziłem, otwarcie powiedziano mi: „Nie naśladuj innych, po prostu rób to, co słuszne”. To chyba najmniej przydatna rzecz, jaką mogłem powiedzieć. Jeśli kod, który jest już zarejestrowany, jest niedopuszczalny, jak mam powiedzieć, co jest dobre, a co złe? Jeśli podstawa zamieszania wynikała z kodu źródłowego, nie sądzę, że ”

W tej sytuacji czuję się naprawdę wyróżniona i sfrustrowana. Udało mi się znacznie lepiej postępować zgodnie z oczekiwanymi standardami i czuję się sfrustrowany, że na przykład, kiedy zmieniam fragment kodu w celu sprawdzenia, czy brakuje wcześniej sprawdzania błędów, słyszę tylko, że nie spraw, aby błędy były wystarczająco szczegółowe (a gałąź została odrzucona na tej podstawie). Co jeśli nigdy go nie dodałem? Jak to się stało, że kod był tak źle? Właśnie dlatego czuję się tak wyróżniony: ciągle napotykam ten istniejący problematyczny kod, który albo naśladuję, albo refaktoryzuję. Kiedy go naśladuję, jest to „złe”, a jeśli go zmienię, jestem zniesławiany za to, że nie robię wystarczająco dużo (i jeśli pójdę na całość, wprowadzam błędy itp.). Ponownie, jeśli jest to taki problem, nie rozumiem, w jaki sposób jakikolwiek kod dostaje się do bazy kodu,

W każdym razie, jak sobie z tym poradzić? Proszę pamiętać, że powiedziałem na górze, że jestem kobietą i jestem pewien, że ci faceci zwykle nie muszą się martwić o decorum, kiedy przeglądają kod innych facetów, ale szczerze mówiąc, to nie działa dla mnie i powoduje, że jestem mniej produktywny. Martwię się, że jeśli porozmawiam o tym z moim kierownikiem, pomyśli, że nie mogę poradzić sobie ze środowiskiem itp.

Istnieje szansa, że ​​zostaniesz wyróżniony jako kobieta, ale możliwe jest również, że jesteś młodszym programistą i dopiero zaczynasz pracę.

Ważne są sprawdzanie błędów i ekspresyjne komunikaty. Jeśli zamierzasz coś dodać do kodu, upewnij się, że jest to zgodne z normami zespołu. Podobnie, jeśli modyfikujesz czyjś kod, spróbuj go poprawić tam, gdzie to możliwe - nie przerywaj przepisywania całego tekstu, ale postaraj się pozostawić go trochę czystszym, niż go znalazłeś.

Czy istnieje pisemna wersja standardów kodowania, których przestrzega Twój zespół? Jeśli nie, dobrym pomysłem może być spisanie tego wszystkiego. Możesz przewodzić wysiłkowi, zapisując popełniane błędy i tworząc z nich listę kontrolną, do której możesz się odwołać przed przesłaniem zmian do przeglądu. Jako efekt uboczny możesz użyć tego pisemnego standardu, aby odwołać się do przyszłych odrzuceń, jeśli są one sprzeczne.

Wygląda na to, że między tobą a kierownikiem zespołu może być brak zrozumienia. Pomocne może być poproszenie go na spotkanie indywidualne i omówienie, co możesz zrobić, aby poprawić. Możesz wprowadzić coś w rodzaju „Czuję, że wciąż brakuje mi wielu niuansów tego, co powinienem robić. Jako młodszy programista chcę się rozwijać i doskonalić. Czy możesz mi pomóc się tam dostać?” i zobacz co się stanie.

Wygląda na to, że bierzesz te rzeczy trochę zbyt osobiście. Nie; takie rzeczy zdarzają się cały czas.

Powody odrzucenia twojego zameldowania (nazwa zmiennej, jakość komentarza, lokalizacja konfiguracji) wydają mi się dość standardowe.

To była decyzja lidera twojego zespołu i nie martwiłbym się tym, gdybym był tobą. Jeśli ktoś zostanie zablokowany w weekend, kierownik zespołu może zezwolić na odprawę i poprosić o jej naprawienie. Jeśli uzna to za stosowne, aby go odrzucić, chociaż może to blokować innych programistów, to jest to jego odpowiedzialność.

Co do kierownika zespołu, który mówi, żebyś nie naśladował innych, ale robił to, co słuszne, wygląda na to, że próbuje dać ci inicjatywę, by ulepszyć bazę kodu. To dobry znak. Ufa, że ​​wykorzystasz swój osąd, więc idź dalej i rób to, co uważasz za słuszne. Nie oznacza to, że musisz zmieniać kod wszystkich innych, ale oznacza to, że powinieneś wziąć odpowiedzialność za jakość pisanego kodu.

Dodatek do innych odpowiedzi:

Jako główny programista jestem zazwyczaj bardziej wybredny w stosunku do młodszych deweloperów, ponieważ są znacznie bardziej plastyczni niż ludzie, którzy pracują od kilku lat. (Moje umiejętności ppl nie są już tak dobre ... jeszcze.)

Bardzo trudno jest zmienić kogoś, kto przez jakiś czas pracował (i zarabiał przyzwoitą pensję) i jest zadowolony ze swojego poziomu kodu (nawet jeśli jakość można poprawić). Ci faceci nie dbają o to, jeśli spróbujesz poprowadzić ich do zostania lepszymi / świetnymi programistami. Z przyjemnością pracują w fabryce kodów.

Nowi faceci, tacy jak ty, OTOH, zwykle tęsknią za wskazówkami i wiedzą, co jest dobre, a co nie. Są również w stanie przyswoić sobie słabość i zmienić swoje drogi na lepsze. Nie są ustawione na inne sposoby.

Jeśli weźmiesz te rady do serca i uczynisz je częścią swojego codziennego życia, przekonasz się, że w krótkim czasie nie będziesz pisać kodu, który jest lepszy od większości istniejącej bazy kodu.

Więc ...

.. może być tak, że dostajesz więcej opinii tylko dlatego, że masz potencjał, aby coś z tego zrobić. :)

Jest całkiem możliwe, że jesteś wyróżniony, ponieważ ... jesteś młodszym programistą.

Z twojego opisu brzmi to tak, jakbyś nie przestrzegał standardu, jak postrzega go kierownik zespołu .

Rozwiązanie jest proste:

• Jeśli to standard, postępuj zgodnie z nim.
• Jeśli nie rozumiesz standardu, poproś o wyjaśnienie.
• Jeśli twoja interpretacja standardu lub instrukcji różni się od kierownika zespołu, poproś o wyjaśnienie

Nie rób z tego bitwy; jeśli spróbujesz sprawić, że zespół poprowadzi „złą”, to nawet jeśli wygrasz, przegrasz. Naucz się odpowiedniej lekcji i kontynuuj rozwój.

Notka autora

Kilka lat później; Zredagowałem to, aby dokładniej odzwierciedlić, co sądzę o sytuacji. Włożyłem więcej niuansów w swoją odpowiedź, ponieważ uczę się więcej o niuansach w tych sytuacjach. Łatwo jest uzyskać odpowiedź „czarną lub białą”, ale wszyscy wiemy, że nie jest to takie proste. Moja odpowiedź odzwierciedla to teraz.

Z tego, co opisałeś; Twoje zachowanie nie ma nic wspólnego z płcią. Nie oznacza to, że nie doświadczasz żadnego traktowania związanego z płcią (mam nadzieję, że nie), tylko to, co opisujesz, nie wydaje się być związane z płcią.

Kiedy byłem liderem zespołu, traktowałem wszystkich jednakowo. W technologii nie ma miejsca na złe traktowanie kogoś z powodu jego płci. Nie wiem, jak sobie z tym poradzić, jeśli ci się to przytrafia.

Ważne jest, abyś ufał, że kierownictwo Twojego zespołu traktuje mężczyzn i kobiety jednakowo. Jeśli istnieją dowody, że nie jest, wówczas stosuje się stare powiedzenie: Zmień swoje środowisko lub zmień środowisko.

Przez równe rozumiem, że traktuje wszystkich jednakowo, bez szacunku dla płci. Jeśli dobrze wykonuje swoją pracę, nie powinieneś widzieć go krytykującego kogokolwiek innego; i nie powinni widzieć, jak cię krytykuje. Przed innymi bardzo ważne jest, aby lider zespołu wykazywał pewność siebie, nawet jeśli spędził ostatnie pięć minut przed korektą zachowania na osobności.

Przejdźmy teraz do poruszonych problemów:

Zaewidencjonowałeś kod, który nie spełniał ustanowionego przez siebie standardu, więc odrzucił twój oddział. Gdybym był w jego butach, nie zrobiłbym tego samego w ten sam sposób, ale upewniłbym się, że moi podwładni (dziwne słowo; ponieważ nie uważam przywódcy za „przełożonego” za ludzi, których oni ołów, ale dokładnie (nie odpowiednio) opisuje sytuację) wiedzieć, co należy zrobić. Jeśli nie wiedzą, jakie są standardy, to moja wina jako lidera. To do mnie należy to naprawić. W tym przypadku mogłeś popełnić błąd, ale sam fakt, że tak się stało, oznacza, że ​​albo 1) nie powiedziano ci, co należy zrobić, albo 2) nie był odpowiednio mentorowany. Twoja wina też nie jest.

Jedną z najważniejszych części bycia programistą jest uświadomienie sobie, że podstawa kodu, nad którą pracujesz, musi być utrzymywana przez wiele różnych osób. Wszelkie zmienne komunikaty i inne rzeczy, które przeszkadzają w czytaniu kodu, nie są przezroczyste dla klienta , ponieważ naprawienie trudniejszych do odczytania problemów w kodzie zajmuje więcej czasu.

Jeśli Twój zespół napisał wytyczne dotyczące kodowania, zastosuj się do nich. Jeśli nie, to powinna istnieć jakaś konwencja społeczności dla twojego języka (w .NET i C #, Microsoft ma standard, który przestrzega wiele firm).

Zapytaj swojego kierownika zespołu, gdzie znajdują się wytyczne dotyczące kodowania, aby upewnić się, że je przestrzegasz. Weź dwa meldowania na spotkania, na których dwóch innych programistów konsekwentnie nie postępuje zgodnie z wytycznymi, więc gdy mówi, że nie ma żadnych, możesz wskazać, że inni też mają z tym problem, a każdy skorzystałby na tym te wytyczne.

Jeśli traktuje cię uczciwie, to zobaczy to i powinno to być na szczycie jego listy rzeczy do zrobienia. Jeśli nie traktuje cię uczciwie, masz amunicję, jeśli tak się dzieje.

Mówienie „dojdę do tego później” jest złe. Później nigdy się nie zdarza. Poświęć czas, aby zrobić to dobrze. Nie ma już programowania.

Trudno jest być młodszym programistą. Czujesz presję, by występować, a wiele osób patrzy na ciebie, a każdy błąd, który popełniasz, jest związany z Twoim imieniem i kontrolą źródła na zawsze.

Nigdzie w swoim poście nie wspominasz o tym, jak inni są traktowani. Powtarzasz, że „czujesz”, że jesteś „wyróżniony”, ponieważ jesteś „kobietą”.

Myślę, że jesteś traktowany jak młodszy programista bez względu na płeć i powinieneś być za to wdzięczny, ponieważ to właśnie oznacza równość. Czuję też, że robisz ogromne zamieszanie w związku z drobnymi, 5-minutowymi zmianami estetycznymi kodu, które musisz teraz zrobić zamiast umieszczania ich na liście rzeczy do zrobienia i nigdy się z nimi nie dogadując.

Nigdzie w twoim poście nie wspomniałeś, że kazano ci robić te rzeczy w weekend. Poprawki mogą być sprawdzane w poniedziałek rano.

Twój zespół może być trochę pedantyczny jak na mój gust, ale z twojego postu nie widzę nic złego w jego prośbach.

Proszę przestać grać kartą płci za darmo . Uważam, że jest to niegodne i podważa koncepcję równości płci.

Nie uważam, że odrzucenie mojej gałęzi na tej podstawie jest przydatne. Wiele osób pracowało przez weekend i nigdy nie powiedziałem, że będę pracować. W rzeczywistości niektóre osoby prawdopodobnie zostały zablokowane, ponieważ nie miałem czasu na zmiany i ponowne przesłanie. Pracujemy nad projektem, który jest bardzo wrażliwy na czas i wydaje mi się, że nie jest pomocne całkowite odrzucenie kodu w oparciu o rzeczy, które są przezroczyste dla klienta. Mogę się mylić, ale wygląda na to, że tego rodzaju rzeczy powinny być obsługiwane w zatwierdzeniach typu patch, kiedy mam czas.

Trudno powiedzieć coś pożytecznego jako osoba, która nie widziała Twojego kodu ani nie wiedziała o harmonogramie twoich projektów. Ale jeśli twój lider zachowuje się odpowiedzialnie i wykonuje dobrą robotę, wie, że inni nie byli tak naprawdę zablokowani i sprint nie będzie spóźniony. Więc nie przejmuj się tym. Być może przeceniasz wpływ na swoje zatwierdzenie. W przeciwnym razie: jeśli twój projekt ma krytyczne znaczenie dla czasu i przejdzie wszystkie testy, byłoby zbyt wybredne, aby odrzucić kod, który można naprawić po wydaniu w mgnieniu oka.

Zrób to Zrób to zrób Zrób to szybko

Tak więc, jeśli twój przywódca podjął decyzję o odrzuceniu twojego zobowiązania, jako profesjonalista powinien wiedzieć, co robił.

Teraz widzę, że w niektórych środowiskach byłaby to norma. Jednak krytyka nie wydaje się równomiernie rozłożona, co prowadzi do mojego następnego problemu. Podstawą większości tych problemów był fakt, że byłem w bazie kodu napisanej przez kogoś innego i starałem się być minimalnie inwazyjny. Naśladowałem nazwy zmiennych używane w innym miejscu pliku. Kiedy to stwierdziłem, otwarcie powiedziano mi: „Nie naśladuj innych, po prostu rób to, co słuszne”.

Jako Junior trudno jest znaleźć drogę do bazy kodów firm.

Najlepsze: istnieją udokumentowane standardy kodowania - i mam nadzieję, że nauczysz się je opanowywać.

Zwykle: istnieją nieudokumentowane standardy kodowania - i musisz się uczyć metodą prób i błędów, czy powinienem powiedzieć „ zatwierdz i odrzuć”? Jest to często bolesne (jak w twoim przypadku). Jest to czasami niebezpieczne z punktu widzenia jakości kodu i może prowadzić do programowania kultowego ładunku , w którym nie tylko naśladuje się zmienne nazewnictwo, ale w dobrej wierze kopiuje i wkleja struktury i wzorce z bazy kodu, należy to zrobić. Nie rób tego! Nawet nie naśladuj istniejących nazw zmiennych.

Trzymaj się kodu Clean . Jest to dobra praktyka i zapewnia łatwą do obrony pozycję. Jeśli jest to czytelny, testowalny i możliwy do utrzymania kod, przeważnie wygrałeś jakąkolwiek dyskusję.

A to prowadzi do kolejnej (ostatniej) porady: kieruj się zasadą harcerza !

Zawsze zostawiaj bazę kodu w lepszym stanie, niż był. Nawet jeśli otaczający kod, z którym pracujesz, jest nieprzyjemny, wyczyść swój - i jeśli masz czas, napraw otoczenie.

Poświęć trochę czasu na poznanie różnych niuansów osobowości twoich współpracowników. Z mojego doświadczenia wynika, że ​​można uniknąć irracjonalnej, niepotrzebnej, niekonsekwentnej lub po prostu bezwartościowej krytyki, jeśli obejmie się dziwactwa współpracowników.

Na przykład niektórzy współpracownicy mogą być kacami w poniedziałki. Mogą być bardzo irytujące i zbyt chętne do odrzucenia niektórych gałęzi kodu lub zatwierdzeń. Jeśli musisz współpracować z kimś takim, unikaj wprowadzania kodu w poniedziałki.

Z drugiej strony kacik może być zbyt blady, aby przejmować się gadatliwością komunikatów o błędach ... więc poniedziałek rano może być idealnym czasem na zatwierdzenie kodu :-p

Dziwactwa osobowości w biurze lub miejscu pracy są dosłownie nieograniczone. Mamy nadzieję, że dowiesz się, kogo unikać i kiedy ich unikać. Nie bądź też dla siebie zbyt trudny :-) Zawsze możesz rzucić pracę i znaleźć inną pracę!

Nigdy nie pracowałem w środowisku, w którym kod jest odrzucany z powodu nieprzestrzegania pewnych konwencji. Gdybym był w twoich butach, miałbym pokusę, by szukać pracy w miejscu, w którym jestem bardziej upoważniony do podejmowania właściwych decyzji i gdzie klient jest najważniejszy, a nie kod.

Nie twierdzę, że czysty kod i standardy nie są ważne, ale klient i oś czasu produktu nie powinny cierpieć z powodu błędu ortograficznego w czymś, czego nie zobaczy żadna osoba nietechniczna, klient ani kierownictwo.

Powiedziawszy to, brzmi to tak, jakbyś pracował w środowisku, w którym oczekiwania nie są jasne lub nie rozumiesz w pełni wymagań z jakiegokolwiek powodu.

Niezależnie od sytuacji to Ty musisz przejąć kontrolę i zadać wyjaśnienia. Bądź proaktywny, jeśli jeszcze tego nie zrobiłeś. Członkowie zespołu i kierownicy zespołu prawdopodobnie będą cię bardziej szanować za zadawanie pytań w celu wyjaśnienia zasad meldowania się. Możesz również poprosić o „przegląd po działaniu”, w którym ty i lider zespołu dyskutujecie o tym, co powinniście zrobić i jak to zrobić umie odróżnić, o ile należy podjąć określone działania, a kiedy nie.

Proponuję dać czas, ponieważ jesteś nowy, aby sprawdzić, czy możesz pokonać wszelkie przeszkody i rozwiązać te problemy dzięki doświadczeniu, komunikacji i poznaniu standardów. Jeśli jednak po kilku miesiącach sytuacja się nie zmieni, a otoczenie nadal jest nękane przez dwuznaczność, może być czas na poszukiwanie pracy w innej firmie.

Nie każda organizacja jest tak drakońska i może się okazać, że inne środowiska pracy będą bardziej dostosowane do twojej osobowości, stylu i wymagań komunikacyjnych.