"Hej, dokonałeś tej zmiany X w tej funkcji Y. Ta zmiana zepsuje mój kod, ponieważ nie bierze ona pod uwagę Z, a Z jest tym, co dzieje się po mojej stronie. Czy możesz zrobić K, aby naprawić? ”

Musisz uczynić to mniej osobistym. Nie ma mojego kodu i Twojego kodu . Oboje jesteście pracownikami firmy, która jest właścicielem kodu. Po prostu go napisałeś, ale przekazałeś własność intelektualną swojemu pracodawcy. Przejęcie własności jest ważne, ale nie mów o tym w ten sposób.

Zamiast tego pomyśl o całym kodzie jako o naszym kodzie i tak go sformułuj. Lub zostaw to. Kiedy nie skupiasz się na tym, co zrobili, ale raczej na obecnym stanie, będzie to mniej przypominać atak osobisty.

W wyniku zmiany X na Y ta inna funkcjonalność się zepsuła . Przyjrzałem się temu i stwierdziłem, że musimy również pomyśleć o Z.

Możesz wtedy zobaczyć, co mówią. Mogą odpowiedzieć czymś w rodzaju „pokaż mi”, „śmiało i napraw to” lub „och, nie myślałem o tym” i zaproponować, że naprawią to samodzielnie.

Idealnie, tak naprawdę ma jednak znaczenie, kto rozwiązuje problem. Ważne jest, aby istniał dialog i wszyscy współpracowali, aby cały produkt był stabilny i funkcjonalny. Posiadanie tylko jednej osoby odpowiedzialnej za konkretny element produktu jest samo w sobie niebezpieczne, a tego rodzaju sytuacja jest równie dobrą okazją do upewnienia się, że wszyscy są świadomi innych elementów produktu.

Z bardziej technicznego punktu widzenia wygląda na to, że naprawdę chcesz testy jednostkowe lub inną formę testów automatycznych przynajmniej dla tego konkretnego fragmentu oprogramowania. Jeśli istnieje ogólna infrastruktura, która je uruchamia i wyświetla wyniki, będzie oczywiste, że coś (nie ktoś (!), Chociaż jest oczywiście git blame ) zepsuło testy. Są tam jako siatka bezpieczeństwa i wszyscy mogą zauważyć, jeśli coś pójdzie nie tak.

Dodatkową korzyścią wynikającą z przeprowadzania testów jednostkowych dla krytycznych elementów systemu jest to, że tak naprawdę nie trzeba wychodzić i zwracać uwagę, że coś jest zepsute. Nie ma już osoby policji kodowej . Jeśli zajmie się tym łańcuch narzędzi, nikt nie dostarcza złych wiadomości i jest mniej złych wibracji w zespole, ponieważ jest mniej miejsca na kłótnie.

Z drugiej strony wiąże się to z koniecznością zaktualizuj również testy. Omawianie zalet i wad tego jest poza zakresem.

Po pierwsze - nie jest niczym niezwykłym, że kod zależności dzieli kod podrzędny. Istnieją praktyki programistyczne, które mogą to złagodzić, takie jak dobra specyfikacja, dokumentacja i testy. Ale to nie jest odpowiedź na twoje pytanie.

Hej, dokonałeś tej zmiany X w funkcji Y. Ta zmiana psuje mój kod, ponieważ nie bierze pod uwagę Z, a Z dzieje się po mojej stronie. Czy możesz zrobić K, aby to naprawić?

To, co powiesz, może zostać odebrane jako oskarżenie - zasadniczo mówisz „złamałeś mój kod” - a to sprawi, że ludzie w defensywie.

Lepszym sposobem jest utrzymanie tego mniej „złamałeś mój kod”, a bardziej „czy mógłbyś spojrzeć jeszcze raz na X?

Z drugiej strony, jeśli ta osoba jest zrzędą bez względu na to, jak do niej podchodzisz, musisz poinformować swojego szefa, że ​​twoja praca jest opóźniona, ponieważ musisz naprawić pracę zrzędą. Ponownie, nie wytykaj palcami, ale zostaw to jako „praca nad Z została opóźniona przez zmiany w X i musiałem najpierw zrobić K”.

W rzeczywistości to wspaniała okazja w przebraniu. Większość inżynierów nie docenia, jak wielkie jest to dla obecnego lub potencjalnego pracodawcy. Równolegle z umiejętnościami technicznymi jest Twoja zdolność do współpracy z ludźmi, akceptowania odpowiedzialności za błędy, pracy z innymi na własną rękę i taktycznego propagowania swoich myśli. Panuje powszechna zgoda co do tego, że najlepiej pokazać to podczas rozmowy kwalifikacyjnej, dzieląc się anegdotyczną historią. zazwyczaj ludzie splatają takie historie z perspektywy czasu, ale możesz być bardzo strategiczny i zdać sobie sprawę, że masz okazję napisać tutaj świetną historię, która odpowiedziałaby na pytania typu „jak radzisz sobie z konfliktem” i prawdopodobnie otworzyłaby zaskakujące możliwości u obecnego pracodawcy .

Coś do rozważenia to taktyka kontra strategia.

Taktyka

Twoja taktyka to podstawa systemy i działania, które zdecydujesz się pomóc w rozwiązaniu problemu. Na przykład, wybierając lepsze sformułowanie, które jest mniej osobiste, wybierając właściwy czas, zwracając uwagę na publiczność / osoby postronne, pomagając osobie, do której się zwracasz, lub używając automatycznych testów, aby wykryć błąd. Poświęć czas na naukę i ćwiczenie dobrych taktyk. To będzie Twój zestaw narzędzi, który możesz wykorzystać w swojej strategii.

Strategia

Problem, z którym się zmagasz, jest symptomem jeszcze większego problemu: ta osoba naprawdę cię nie lubi. Właśnie to chcesz strategicznie naprawić.

W miejscu pracy, szczególnie w zespole, nie masz kontroli nad tym, że masz osobiste relacje z każdym członkiem zespołu. Może ktoś cię nie lubi, a ty go nie lubisz, szkoda, że ​​jesteś zmuszony do związku, będąc w zespole. To twój wybór, czy te relacje są dobre, czy złe. Możesz włożyć wysiłek w innych ludzi lub nie. Prawdziwy rozwój zawodowy następuje wtedy, gdy wykraczasz poza myślenie o sobie jako o łamaczu kodu (co prowadzi do problemów z arogancją kodu), ale jako funkcjonującym członku zespołu i chcesz pokazać, że z tobą w zespole ten zespół jest większa niż suma jego części. Oznacza to dużą świadomość relacji.

Strategiczną decyzją jest zadanie sobie pytania, jak chcesz, aby wyglądał ten związek? Czy to możliwe? Czego brakuje lub jakie wyzwania mogą utrudnić związek? Co musisz zrobić, aby to się stało? Na przykład wiele problemów w związkach sprowadza się do zaufania. Tak więc strategia polegałaby na pokazaniu temu deweloperowi, że myślisz o jego / jej interesach, a nie tylko o własnych, i doprowadzenie twojego związku do punktu, w którym ta osoba ci ufa. Nie bądź stoikiem, wiedzącym wszystko, co nie stawia ludzi po twojej stronie, nawet jeśli masz rację i masz rację. Strategia polega na uświadomieniu sobie, że chcesz ludzi po swojej stronie i przemyśleniu, jak to się dzieje. Co działa, a co nie. Ważne jest również, aby zdać sobie sprawę, że skuteczna strategia często wymaga cierpliwości. Być może będziesz potrzebować więcej pracy i stawiania sobie wyzwań, niż chcesz, aby osiągnąć prawdziwy postęp.

Fajne w tym jest to, że jeśli rozwiniesz naprawdę solidne relacje z tym starszym programistą, taktyki, które cię tam doprowadziły, stają się znacznie mniej potrzebne i łatwiej jest być bardziej wydajnym i skuteczniejszym w swojej pracy. Dobra strategia może doprowadzić Cię do dobrych relacji, a dzięki dobrym relacjom znacznie łatwiej będzie Ci osiągnąć swoje cele. Pomyśl więc o pracy nad swoją relacją z tą osobą, gdy nie ma problemu, a to ułatwi, gdy pojawią się takie problemy.

Jak mam mu zakomunikować, że mam dobre środki, ale także sprawić, by zrozumiał (i zgodził się), że to on powinien wprowadzić wymagane zmiany, aby naprawić uszkodzony kod / moduł?

Lepiej upewnij się, że twój szef / zespół zgadza się, że tak powinno być. Idealnie w środowisku programistycznym jest jakiś zautomatyzowany system testujący, więc jeśli kod, który ma być sprawdzany w przerwach, jest odrzucany, dopóki nie zostanie naprawiony. Zwykle jest to osoba, która to zmieniła. Każdy powinien być dumny ze swojej pracy, która wiąże się z odpowiedzialnością za naprawianie rzeczy, które psują.

Twój szef może uznać, że marnowanie czasu starszych programistów na naprawianie każdego drobnego błędu, który wprowadzają system. Uważają, że zadanie to pozostawiono młodszym programistom; Nie zgadzam się z tym. Musisz dowiedzieć się, jak to powinno działać.

Moje podejście do tego rodzaju problemów polega na upewnieniu się, że istnieje wystarczająca metodologia i narzędzia, aby problem był techniczny, a nie osobisty.

Na przykład upewnij się, że masz zautomatyzowane kompilacje i testy dymne. Jeśli te się zepsują, zastosuj zasadę, że łamacz musi zapewnić jedzenie na następnym spotkaniu zespołu.

Czasami ludzie po prostu śmiało rzucają wyzwanie status quo w samolubnym dążeniu do osobistego postępu. W pewnym sensie jest to normalne. W najlepszym przypadku jest przedsiębiorczy. Jednostka idzie naprzód w ramach, które na to pozwalają. Więc zmień ramy. Tym typom ludzi nie przeszkodzi, będą robić postępy na różne sposoby. Jako menedżer Twoim celem jest wykorzystanie tego ducha i kierowanie nim w sposób pozytywny dla zespołu i celów.

Częścią tej strategii wykorzystania woli jest upewnienie się, że ludzie nadal czują rozsądek własności. Najpopularniejsza odpowiedź, jak dotąd, opowiada się za filozofią wyrzeczenia się własności. Myślę, że to może przynieść efekt przeciwny do zamierzonego. Pozwól ludziom z pasją posiadać swój obszar. Ale upewnij się, że nie naruszają innych ”.

To pytanie prawdopodobnie w dużej mierze zależy od kultury firmy.

Są firmy, w których „błędy się nie zdarzają”. A raczej nie możesz o nich mówić, a menedżer, który pozna kogoś, kto popełnił błąd, będzie „uważnie obserwował tę osobę”.

W takiej sytuacji osobiście ujawniasz problem tej osobie w ten sposób kierownik słyszy o tym tylko wtedy, gdy jest to absolutnie konieczne, mówiąc im dokładnie, co chcesz, aby zrobili lub naprawili, po tym, jak sam spróbujesz to naprawić. (Oczywiście powinieneś też biegać, czerwone flagi yada yada.) Powinieneś także powiedzieć im, że jest między tobą a nimi i że jesteś fajny.

W każdej działającej firmie musisz upewnić się, że ujawnienie nie brzmi jak oskarżenie.

Nadal musisz się upewnić, że powiesz im dokładnie, czego od nich chcesz i dlaczego nie możesz tego zrobić sam (ponieważ jeśli możesz to naprawić, to dlaczego narzekasz, szybko to naprawiaj i idź dalej, nie zrobili tego, aby stworzyć dla Ciebie pracę, musieli rozwiązać swój własny problem).

Upewnij się również, że ich kierownik lub kierownik projektu jest świadomy i zgodził się, aby to naprawić.

Nie mogą zdecydować, co zrobić z własnym czasem i otrzymać zlecenie od swojego menedżera / kierownika projektu.

Przyjście i rozmowa o błędzie w bilecie, który powinien być już zrobiony, bez robienia tych rzeczy wcześniej i bezpośredniego adresowania ich spowoduje stres i wrażenie, że chcesz, aby wykonali pracę w czasie, w którym są przypisani do czegoś innego lub w wolnym czasie.

Większość konfliktów lub problemów z ludźmi wynika z podstawowych procesów. Z pewnością tak jest w tym przypadku.

Ty, Twoi koledzy, Twoja firma i, co gorsza, Twoi ostateczni klienci jesteście ofiarami nieudanych procesów, które powinny być wdrożone, aby zarządzać jakością i integralnością połączonego kodu.

Myślenie a działanie z tej perspektywy jest kluczem do rozwiązania podstawowych problemów z jakością, które bezpośrednio doprowadziły do ​​problemów, których doświadczasz. Jest to również klucz do znalezienia wspólnej płaszczyzny z kolegami (np. Łatwo będzie Ci dojść do porozumienia w kwestii procesów, które sprawiają Ci cały ból).

Chociaż prawdopodobnie chcesz po prostu wykonać swoją pracę i rozwijać się w swojej karierze, jeśli jesteś postrzegany jako osoba, która chce zmierzyć się z bardziej doświadczonymi współpracownikami, zniszczysz swoje relacje zawodowe z tymi, którzy są najlepiej przygotowani aby ci pomóc.

Moją radą byłoby zaproponowanie poprawki, albo w szczegółach (na przykład jako pull request), albo w zarysie ogólnego podejścia, które zaproponowałbyś jako rozwiązanie. Zanieś to osobie, której kod uważasz za złamany i poproś o opinię. A co najważniejsze posłuchaj odpowiedzi .

To przedstawia współpracownikowi, któremu być może właśnie przerwałeś, rozwiązanie, a nie problem, a tym samym dodatkową pracę. Nie tylko prawdopodobnie dowiesz się czegoś z otrzymanej odpowiedzi, ale będziesz postrzegany jako pomocny i działający w zespole.

Jak sugerowali inni, musisz to spersonalizować. Powinna istnieć zbiorowa własność kodu. Mniej „zepsułeś moje zmiany!” i bardziej jak „w jaki sposób możemy sprawić, by obie zmiany dobrze ze sobą współpracowały?”

Możesz również zastanowić się, czy można poprawić komunikację podczas codziennych konfrontacji (jeśli je masz - lub zasugeruj wprowadzenie ich, jeśli nie), więc ogólnie rzecz biorąc, istnieje większa świadomość tego, nad czym ludzie pracują, a tym samym mniejsze prawdopodobieństwo konfliktu lub przełamania zmian.

Zapewnienie odpowiedniego poziomu szczegółowości podczas stand-upów jest trudne, ale jeśli Twoi koledzy nie są nie zdając sobie sprawy z szerokiego obszaru kodu, w którym pracujesz, możesz rozważyć podanie nieco więcej szczegółów.

Coś innego, o czym należy pamiętać - jako młodszy, ale mniej doświadczony programista jest całkiem możliwe, że potrafisz kodować szybciej niż Twoi bardziej doświadczeni koledzy (młodszy, bystrzejszy mózg to czasami prawdziwy atut!), jednak powinieneś zdaj sobie również sprawę z tego, że Twoi starsi koledzy mają przewagę dzięki doświadczeniu i mogą być bardziej rozważni w swoim podejściu na podstawie ich wieloletniego doświadczenia. Rzeczywiście, większość projektów rozwojowych bardziej przypomina maratony niż sprint na 100 metrów. Najlepsze zespoły mają doświadczenie na każdym poziomie.

Jak mam mu przekazać, że przychodzę z dobrymi intencjami, ale także sprawić, by zrozumiał (i zgodził się), że to on powinien wprowadzić wymagane zmiany, aby naprawić uszkodzony kod / moduł?

Zgadzam się z większością z tego, co zostało już powiedziane. Różni ludzie różnie interpretują ten sam komunikat, a to, co jedna osoba postrzega jako całkowicie normalną, skuteczną komunikację, dla innej jest irytujące lub onieśmielające - z jakichkolwiek powodów. Ta osoba prawdopodobnie komunikuje (pośrednio), że uważa twój styl za nieprzyjemny. Następnym razem spróbuj czegoś innego. Spróbuj zmienić ustawienie - złap go raczej przy fontannie niż przy jego siedzeniu. Usiądź obok niego, zanim zaczniesz rozmowę, zamiast stać nad nim. Wypróbuj różne podejścia - kieruj się zdrowym rozsądkiem.

I jeszcze jedna rzecz, którą mogę zasugerować, spróbuj zrównoważyć twoją z nim komunikację. Jeśli jest wrażliwy na to, że wytykasz jego błędy, znajdź okazje, by (szczerze) pochwalić go za sprytne projekty lub skuteczne wykonanie - w przypadku większości ludzi to bardzo dużo.

Najłatwiej sobie z tym poradzić. Zamiast tego pozwól deweloperowi dyskutować z zakończeniem niepowodzenia testu. Zapytaj ich, jak kod ma działać, a następnie zbuduj wokół niego test. Daj im test i powiedz, że się nie udał.