Inspirujesz współpracownika do przyjęcia lepszych praktyk kodowania?

W odpowiedzi na moje przestarzałe pytanie współpracownika różne osoby omawiały strategie postępowania ze współpracownikami, którzy nie chcą zintegrować przepływu pracy z zespołem.

Chciałbym, jeśli to możliwe, nauczyć się kilku strategii „nauczania” współpracownika, który jest po prostu ignorantem nowoczesnych technik i narzędzi, i być może trochę apatyczny.

Zacząłem współpracować z programistą, który do niedawna pracował we względnej izolacji, w innej części firmy. Ma szeroką wiedzę dziedzinową, a co najważniejsze, wykazał się dobrymi umiejętnościami rozwiązywania problemów , czego wielu kandydatom wydaje się brakować.

Jednak rzeczywisty kod (C #), który widziałem, to powrót do dni VB6. Struktura proceduralna, notacja węgierska, zmienne globalne (nadużycie static), brak interfejsów, brak testów, niestosowanie generycznych, rzucanie System.Exception... masz pomysł.

Ten programista jest trochę starszy ode mnie i przynajmniej na podstawie pierwszych wrażeń nie aktywnie szuka pozytywnych zmian. Nie zamierzam mówić , że jestem odporny na zmiany, ponieważ uważam, że jest to w dużej mierze kwestia poruszenia tematu i chcę się przygotować.

Programiści zwykle są upartymi ludźmi, a płonące pistolety i wprowadzanie recenzji kodów rip-it-to-shreds i ściśle przestrzegane zasady prawdopodobnie nie przyniosą oczekiwanego rezultatu końcowego. Gdyby to było nowe zatrudnienie, młodszy programista, nie pomyślałbym dwa razy o przyjęciu stanowiska „mentora”, ale jestem wyjątkowo nieufny wobec traktowania doświadczonego pracownika jako nieświadomego początkującego (którego on nie jest - po prostu nie zrobił dotrzymał kroku pewnym postępom w tej dziedzinie).

Jak mogę podnieść standard jakości kodu tego dewelopera na sposób Dale Carnegie poprzez delikatne przekonywanie i niematerialne zachęty? Jaka byłaby najlepsza strategia przeprowadzania subtelnych, stopniowych zmian bez tworzenia sytuacji przeciwnej?

Czy inni ludzie - zwłaszcza główni programiści - byli już w takiej sytuacji? Które strategie skutecznie stymulują zainteresowanie i tworzą pozytywną dynamikę grupy? Które strategie okazały się nieskuteczne i których lepiej byłoby uniknąć?

Wyjaśnienia:

Naprawdę czuję, że kilka osób odpowiada w oparciu o osobiste uczucia, nie czytając wszystkich szczegółów pytania. Proszę zwrócić uwagę na następujące kwestie, które powinny być dorozumiane, ale wyrażam się wyraźnie:

• Ten współpracownik jest z mojego wieku tylko „starszy”. Nigdy nie powiedziałem, że jego tytuł, sfera wpływów lub lata w organizacji przekraczają moje, i w rzeczywistości żadna z tych rzeczy nie jest prawdą. Jest programistą LOB, który został zaabsorbowany głównym sklepem programistycznym. to jest to!

• Nie jestem nowym najemnikiem, młodszym programistą ani innym naiwnym idiotą z wielkimi planami przekształcenia firmy z dnia na dzień. W zasadzie jestem odpowiedzialny za proces tworzenia oprogramowania, ale jak wielu, którzy pracowali jako „potencjalni klienci”, będzie wiedział, że obowiązki nie zawsze są ściśle powiązane z tabelą organizacyjną.

• Ja nie pytając ludzi, jak dostać moją drogę, przyjdź piekło lub wysokiej wody . Mógłbym to zrobić, gdybym chciał, a wynik netto byłby taki, że ta osoba stałaby się urażona i / lub zrezygnowała. Spróbuj zrozumieć, że szukam społecznej , opartej na współpracy metody wprowadzania zmian.

• Wzmianka o „… zmiennych globalnych… bez testów… rzucaniu System.Exception” miała na celu wykazanie, że problemy nie są jedynie powierzchowne lub estetyczne . Praktyki, które mogą działać w przypadku stosunkowo małych aplikacji CRUD, niekoniecznie działają w przypadku dużych aplikacji korporacyjnych i w rzeczywistości żaden z dotychczasowych kodów nie przeszedł pomyślnie testów integracyjnych.

Proszę, spróbuj wziąć to pytanie za wartość nominalną, zaakceptuj fakt, że tak naprawdę wiem, o czym mówię i albo odpowiedz na pytanie, które faktycznie zadałem, albo przejdź dalej.

PS. Moja najszczersza wdzięczność dla tych, którzy - udzielili - konstruktywnych rad, zamiast spierać się z tym założeniem. Pozostawię to otwarte na dłużej, ponieważ mam nadzieję, że usłyszę więcej na temat doświadczeń w świecie rzeczywistym.

Punktem wyjścia jest poznanie odbiorców . Wydaje się, że już to rozumiesz, ponieważ znasz różnicę między mentoringiem młodszego współpracownika a wpływem na starszego współpracownika.

Nadal musisz dowiedzieć się, co motywuje tę konkretną osobę. To, co działa na jednym starym geezerze (takim jak ja), może nie działać dla twojego starego geezera.

Jeśli lubi mentorować / uczyć innych, możesz podejść do problemu, zadając pytania typu „dlaczego to robisz w ten sposób?” Może to prowadzić do dialogu, w którym możesz poprosić go o ocenę nowszych podejść i wyrażenie opinii.

Jeśli to nie zadziała, możesz wskazać błędy , których można uniknąć, stosując praktyki lub style, które chcesz zastosować. To wymaga dużo więcej pracy, ponieważ musisz znaleźć błędy i pokazać, w jaki sposób pomocne byłyby zachowania, które chcesz zachęcić.

Jeśli wydaje się chętny do pomocy innym, możesz odwołać się do jego chęci pomocy początkującym . Wyjaśnij, że „dzisiejsze dzieci” nie są przyzwyczajone do jego stylu kodowania i dlatego z większym prawdopodobieństwem złamie kod.

Czasami możesz po prostu zajrzeć mu w twarz i zmusić problem. Musisz starannie dobierać te bitwy. Upewnij się, że zaczynasz od tematu, w którym wiesz, że możesz mu udowodnić, że masz lepszy sposób.

Myślę, że masz właściwe podejście. Po prostu pamiętaj, aby powiedzieć wszystkie miłe rzeczy, które już powiedziałeś - Świetne umiejętności rozwiązywania problemów, lepsze zrozumienie biznesu itp. I po prostu poproś go o trochę czasu, aby pokazać mu obecne standardy, że grupa jest za pomocą i daj mu szansę zadawania pytań na ich temat.

Kiedy się spotkasz, przynieś mu kawę lub coś, i daj mu znać, że praca zgodnie ze standardami przyniesie mu korzyść, ułatwiając mu obsługę twojego istniejącego kodu, a także ułatwiając komuś pomoc, jeśli będzie mógł pomóc zostaje objęty pracą (duży plus dla osoby pracującej w izolacji) itp.

Upewnij się, że jest zaręczony i dostaje dobre wyjaśnienia, dlaczego robisz rzeczy, które robisz, i nie skupiaj się na tym, dlaczego nie powinien robić rzeczy, które robił, przyciągaj innych ludzi, jeśli musisz, i każ im to wytłumaczyć. Udostępnij się później, jeśli będzie miał jakieś pytania, i sprawdź kilka miejsc, do których można się odwołać w celu uzyskania przykładów twoich standardów.

Jeśli po tym nie jest zainteresowany, możesz odnieść się do pierwszego pytania, które podłączyłeś.

To naprawdę jest praca twojego menedżera

1. Zdaj sobie sprawę, że firma musi mieć standard kodowania. Każda dość profesjonalna firma ma to, bez względu na wielkość firmy.
2. Niech wszyscy usiądą razem i zaczną wypracowywać standard. W ten sposób każdy może zabrać głos, a następnie będzie bardziej zmotywowany do przestrzegania tego standardu.

Jeśli Twój menedżer nie zdaje sobie z tego sprawy, nie kwalifikuje się do pracy. A jeśli tak, powinieneś dać im troche powyżej powyższych dwóch. Zalety posiadania standardu kodowania jest tak wiele, że tak naprawdę nie ma argumentów przeciwko takim standardom. (Jeśli niektórzy programiści uważają, że są „artystami” i nie powinni być ograniczani granicami profesjonalizmu, powinni zamiast tego znaleźć pracę w dziedzinie sztuk pięknych).

Sam standard kodowania powinien przede wszystkim koncentrować się na zakazie niebezpiecznych praktyk i niebezpiecznych funkcji biblioteki. Pracuj nad bezpieczniejszym i czystszym podzbiorem używanego języka. Zachowaj standard kodowania wolny od „stylu kodowania”, ponieważ styl kodowania jest znacznie trudniejszy do uzgodnienia i nie jest tak ważny. To dość klasyczne, że firma decyduje się na stworzenie standardu kodowania, a następnie natychmiast utknie w gorącej bzdurnej dyskusji na temat tego, gdzie umieścić nawiasy klamrowe.

W celach informacyjnych sprawdź, jak zostały napisane standardy MISRA-C / C ++ i CERT C / C ++ / Java.

Przede wszystkim musisz wyjaśnić DLACZEGO chcesz zmienić sposób pracy tych osób. Jeśli to tylko ze względów estetycznych, myślę, że powinieneś się zastanowić, ponieważ ta osoba wykazała, że ​​jej sposób pracy faktycznie działa.

Jeśli jednak istnieje ku temu techniczny powód, powinieneś rozważyć skontaktowanie się z tą osobą z czymś w rodzaju:

Mam sugestię, w jaki sposób możesz zaoszczędzić nużącego czasu i pieniędzy dla firmy. Czy jesteś zainteresowany?

Należy pamiętać, że powinny to być nisko wiszące owoce, ponieważ najprawdopodobniej będą wymagać zmiany istniejących nawyków, które zawsze wymagają dodatkowego wysiłku.

Nawet jeśli masz mnóstwo sugestii, wybierz jedną lub dwie i pokaż , że będzie to zmiana na lepszą.

Albo to zadziała, a zostaniesz zapytany, czy masz więcej sugestii, albo tak się nie stanie, a obrażenia będą ograniczone do jednej lub dwóch sugestii.

Pamiętaj, że bardzo ważne jest, aby odniosła sukces i zrobiła to szybko.

Musisz też uważać. Mogą istnieć bardzo dobre powody, aby robić rzeczy tak, jak zostały wykonane, ale jesteś zbyt nowy, aby zrozumieć, dlaczego. Dlatego szanujcie starszego i zapytajcie, zanim założycie, że wasza sugestia jest lepsza. Możesz się czegoś nauczyć.

Chciałbym cię poważnie zniechęcić do stawania mu na twarzy, ponieważ spowodowałoby to bardzo pogorszenie sytuacji. Zdaję sobie sprawę, że został wprowadzony jako środek ostateczny, ale z mojego doświadczenia wynika, że ​​w tym momencie programista przestał funkcjonować.

Wymuszenie tego problemu może sprawić, że jednostka stanie się wrogiem, w którym walczy z każdą twoją czynnością. Miałoby to naprawdę negatywny wpływ na zespół i nie kończy się, dopóki ktoś nie odejdzie lub nie zostanie zwolniony.

Jeśli ta osoba naprawdę ma wiedzę domenową, której potrzebujesz / potrzebujesz, poproś ją o udokumentowanie tej wiedzy.

Zaczynając od delikatnego przekazania mu tego: nie wiem, jak doświadczony i jak dobrze znałeś swoje opinie. Możesz już wiedzieć, zatrudniać, a nawet odrzucić poniższe, ale i tak tu jest. Istnieją wytyczne dotyczące przekazywania opinii, gdy chcesz zmienić czyjeś zachowanie. Struktura konwersacji, o której pomyślałem i wciąż próbuję zastosować w sytuacjach, w których chcę wyrazić opinię (ponieważ działają):

1. Opisz zachowane zachowanie. To musi być konkretne zachowanie. Przykład: „Widzę, że używasz wielu zmiennych statycznych w kodzie”
2. Opisz, jak wpływa to na Ciebie / Twój zespół. Przykład: „Uważam, że taki kod jest trudny do utrzymania”
3. Zaproponuj rozsądne rozwiązanie. (możliwe rozwiązania są wymienione w innych odpowiedziach, a ja zagłębię się później w tę odpowiedź).
4. Daj mu możliwość omówienia rozwiązania. Zapytaj go, co myśli o rozwiązaniu. Przyjmij jego odpowiedź za wartość nominalną. Przekazałeś mu swoją opinię, a on może ją zaakceptować lub nie. *

Szybki zasób informacji zwrotnych można znaleźć na przykład na stronie http://managementhelp.org/communicationsskills/feedback.htm (choć w Internecie jest mnóstwo takich rzeczy)

Teraz w części dotyczącej rozwiązania, z tego, co czytam w twojej odpowiedzi, uważam, że jest on sprytny i ma właściwy sposób myślenia, ale jest tuż za nowoczesnymi dobrymi praktykami. Te wymagają czasu i wysiłku, aby je opanować, oprócz faktycznej wiedzy na ich temat, więc będziesz musiał dać mu taką możliwość. Prawdopodobnie oznacza to zebranie zasobów edukacyjnych (sieci, czasopisma, książek itp.) Jako punktu wyjścia i zapewnienie mu wolnego czasu na ich przestudiowanie. Mógłbym sobie wyobrazić dawanie mu w każdy piątek popołudnia, aby poszerzać swoje horyzonty w zakresie stylu programowania, w którym może robić, w co wierzy, postęp w realizacji tych celów. Ludzie dziedzicznie chcą się poprawić. Podaj materiały i czas, a oni z niego skorzystają.

Być może najważniejsze, nie oczekuj zmian z dnia na dzień. Robi to po swojemu od dawna i zapewne całkiem nieźle sobie z tym poradził. Zajmie to trochę czasu, aby stać się tak dobrym w nowym sposobie robienia rzeczy i przez pewien czas prawdopodobnie nie zobaczy dużej wartości na nowe sposoby, ponieważ na początku nie ma takiej wartości. Jego stary sposób będzie przez pewien czas bardziej skuteczny.

* Uwaga: zabawne jest to, że rozmowy są bardzo trudne do modelowania. Mają swoje własne życie, więc chociaż na papierze ładnie wygląda, to ma tendencję do nieco mętnienia.

Wyjaśnij, jak chcesz, aby rzeczy były zrobione i pokaż mu, jak to działa, przy projektach i wyborach architektonicznych dokonanych dla projektu na początku projektu, nad którym będzie pracował. Usiądź jeden na jednego (i prywatnie) i wyjaśnij problemy, które widziałeś w jego poprzednim kodowaniu i dlaczego stanowią one problem dla tego projektu. Zapytaj go, czego musi potrzebować, aby się poprawić, ale wyjaśnij, że nie ma poprawy.

Następnie użyj przeglądu kodu jako narzędzia, aby zmusić go do dostosowania metod pracy. Zaplanuj dobry czas na pierwszy i naprawdę powiedz, dlaczego wolisz to od tego, i pozwól mu wyjaśnić swoje rozumowanie. Upewnij się, że naprawdę go wysłuchasz, ludzie są bardziej skłonni do zmiany, gdy czują, że ich obawy zostały rozwiązane. Spodziewaj się w swoim planie (ale nie mów mu tego), że ma przerobione pierwsze zadanie i nie akceptuj go, dopóki nie spełni standardów twojego zespołu. Gdy będzie wiedział, czego oczekujesz i że nie pozwolisz, aby przesuwało się to w interesie czasu, prawdopodobnie podejdzie do twojego sposobu pracy. Ale możesz użyć recenzji kodu jako narzędzia edukacyjnego dla kilku iteracji. Nie musisz być nieprzyjemny, gdy nie akceptujesz pracy, dopóki nie spełni ona twoich standardów, ale musisz się jej zdecydowanie i konsekwentnie trzymać. Don'

Pytanie o wartości 64 000 $ dotyczy tego, czy realizuje projekty na czas i spełnia wymagania funkcjonalne. Jeśli tak, robi to dobrze. W tworzeniu oprogramowania nie ma obiektywnych prawidłowych ani niewłaściwych sposobów. Ostatecznie chodzi o rozwiązywanie problemów. A jeśli problemy zostaną rozwiązane w sposób zadowalający dla klienta / klienta, z definicji tworzenie oprogramowania odbywa się poprawnie.

Oczywiście staje się zupełnie inną kwestią, jeśli jego projekty nie zostaną ukończone. W tym momencie twoi przełożeni muszą dokonać zmian, być może dzięki twojemu wkładowi. Ale tylko dlatego, że narusza twoje osobiste poczucie estetyki kodu lub dzisiejszej konwencjonalnej mądrości, nie oznacza, że ​​to, co robi, jest „złe”. Nie jesteś arbitrem definicji „dobrego kodu”. W końcu może mieć niską opinię o twoim kodzie.

Więc ... chyba że rzeczywiście jest problem z jego pracą (o której nie wspominałeś), nie rób nic. Sukces programisty polega na nauczeniu się łączenia kodu ze stylami innych programistów.

Mógł przecież przyjść tutaj i zadać podobne pytanie o kontakt z mniej doświadczonym programistą, który jest bardziej zainteresowany utrzymywaniem mody i kończeniem projektów. Chodzi o perspektywę.

Jako młodszy programista rozmawiający ze starszym programistą, jest zbyt ryzykowne, abyś spróbował podejść do niego z lepszymi pomysłami niż z jego własnymi.

Najlepszym sposobem, aby sobie z tym poradzić, jest przekonanie szefa o lepszej praktyce i sprawdzenie, czy wyda dekret, że cały kod musi spełniać określone standardy i być egzekwowany zgodnie z tymi standardami poprzez wzajemne oceny kodu.

Znaczna część ludzi jest (nawet jeśli na poziomie podświadomości) mściwa, egoistyczna i defensywna, nawet jeśli zupełnie nie zdają sobie sprawy z własnych podświadomych motywów, obrażą się, jeśli spróbujesz je zmienić lub sugerować, że się mylą tak czy inaczej.

Łańcuch dowodzenia jest najbezpieczniejszą drogą, ponieważ musi słuchać swojego szefa, ani nie musi go lubić. Niech szef będzie złym facetem, po to jest.

Jeśli nie możesz sprzedać bossa lub on jest szefem, po prostu poradzić sobie z jego błędami, ale dawaj przykład w swoim kodzie.

Nie możesz

Nie możesz inspirować ludzi do robienia rzeczy, których nie są świadomi przy tworzeniu oprogramowania. Mówię z doświadczenia, ponieważ starałem się to robić często w mojej karierze i za każdym razem efektem końcowym jest to, że mój własny status maleje w oczach firmy; Zostałem nawet wyrzucony z pracy lub sfrustrowany, gdy nic się nie wydarzyło, po prostu za próbę ulepszenia kultury rozwoju wokół mnie do nowoczesnych praktyk.

Jeśli twój współpracownik nie był ignorantem, możesz im to pokazać. Ponieważ jednak nie są w stanie nic zrobić, ponieważ nie są w stanie lub nie dbają wystarczająco o tworzenie oprogramowania, aby dążyć do przyjęcia lepszych praktyk kodowania. Są szanse, że jeśli spróbujesz, albo zignorują to, albo zmanipulują, nie do końca rozumiejąc, co z dźwięków jest tym, co już robią („Trial and Error Development”, tj. Po prostu włamują się w kodzie, dopóki błędy nie ustaną) .