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

24

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.

Aaronaught
źródło
9
Byłem w tej sytuacji i nigdy nie widziałem, żeby naprawdę udało się to rozwiązać. Wiele osób, które opisałeś, przestało myśleć o programowaniu lata temu; w tym momencie są zainteresowani tylko rozwiązaniami dla swojej domeny biznesowej. Nie zamierzam dołączać do bandwagonów na tej stronie, którzy potępiają takich ludzi; rzeczywiście myślę, że są solą ziemi. Jeśli działają w twoim kodzie, powinieneś naciskać, aby przynajmniej przestrzegać twoich konwencji. Nie miałem trudności ze sprzedażą, że ludzie powinni przestrzegać obowiązujących konwencji, jeśli przyczyniają się do projektu.
Jeremy
1
Co powiedział twój szef, kiedy podniosłeś z nim tę troskę?
2
@Aaronaught, ponieważ jego kod działa, nie jest to problem techniczny, ale polityczny i prawdopodobnie należy go narzucić z góry, jeśli chcesz coś zmienić. Innymi słowy od twojego szefa. Przygotuj dobre argumenty!
2
@Thor: Więc uważasz, że jest absolutnie niemożliwe, aby jego styl był po prostu wynikiem niskich oczekiwań, braku recenzji i intensywnego życia, które nie nadaje się do samodzielnego uczenia się w czasie osobistym? Brak troski nie jest cechą osobowości, jest produktem środowiska i można ją zmienić. Nie wiedząc nawet łatwiejsze do zmian, ale wciąż musi podchodzić z pewnym poziomie dyplomacji.
Aaronaught
1
@Aaronaught, albo nie udało ci się być nędzną inspiracją (czego nie można wykluczyć), albo nie chce on być inspirowany. Czy zastanowiłbyś się nad kodowaniem testów jednostkowych w Lisp lub Haskell, gdyby młodszy kolega powiedział ci, że jest to znacznie mądrzejsze niż to, co robisz teraz?

Odpowiedzi:

10

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.

jimreed
źródło
Wydaje się, że są to dobre ogólne strategie. Powinienem jasno powiedzieć, że jest to po prostu VB6, a nie COBOL. Może 5-7 lat wstecz, a nie 20-30 lat. Więc nie geezer / dinozaur.
Aaronaught
1
Nie zapytałbym: „Dlaczego to robisz w ten sposób?” Może to mieć negatywny wpływ - natychmiastowe postawienie go w defensywie. Możliwe, że współpracownik po prostu nie wie i nie chcesz, aby poczuł się ignorantem. Zamiast tego zapytaj „czy zastanawiałeś się nad tą metodą?”
IAbstract
@IAbstract Jeśli lubi uczyć, nie uzyska defensywy, spodoba mu się możliwość nauczania. Ton i postawa zrobią dużą różnicę. Jeśli brzmi, jakbyś mógł łatwo dodać „Idiota” na końcu pytania, to nie robisz tego dobrze? :-) Z mojego doświadczenia wynika, że ​​większość ludzi chętnie odpowiada na szczere pytania.
jimreed
@IAbstract: Jestem pewien, że gdybym zapytał coś takiego: „czy rozważałeś tutaj zastrzyk zależności?” odpowiedź brzmiałaby „co?” Oczywiście jest szansa, że ​​mogę być mile zaskoczony, ale myślę, że Jim ma rację, lepiej jest rozpocząć rozmowę z pytaniem „co skłoniło cię do skorzystania z Fooobiektu o zasięgu globalnym ?” Nie przewiduję, że będzie to interpretowane jako atak; to ja próbuję zrozumieć istniejący projekt.
Aaronaught
@Aaronaught: dość uczciwy;) Chociaż reakcja na DI może być „huh?”, Może zainicjować interesującą rozmowę, taką jak: „no cóż, słyszałem o tym, ale ...” ... moją obawą jest głównie ton (jak wskazuje jimreed) Oczywiście, jak mówi jimreed, musisz wybierać swoje bitwy - czasem oznacza to noszenie dużego kija, a czasem wspólne granie w piaskownicy.
IAbstract
4

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ś.

DKnight
źródło
4

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.


źródło
To sprawia, że ​​(niepoprawne) założenie, że pracuję dla wydawcy oprogramowania o strukturze pionowej. Mniej niż 10% programistów pracować dla wydawców oprogramowania i to nie koniecznie w gestii dyrektora lub kierownika średniego do micromanage twórcy.
Aaronaught
2
@Aaronaught Cóż, to jest prawdziwe źródło twojego problemu. Jeśli nie jesteś w zespole ze standardem kodowania i przynajmniej jednym doświadczonym programistą, który przewodzi innym i kieruje nimi, to zła organizacja. Wszyscy będą kodować losowo, myśląc, że są „artystami”, wymyślając mierne, niestabilne, niemożliwe do utrzymania wyniki i nie ucząc się, jak je poprawić.
2

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ć.

Aaronaught
źródło
Dzięki za konstruktywną odpowiedź - choć myślę, że można by to zrobić bez pierwszego akapitu.
Aaronaught
@aronaught, przepraszam, ale w rzeczywistości jest to dość ważne.
Nie, to naprawdę nie jest ważne. Odpowiada na zupełnie inne pytanie, a ja już przedstawiłem kilka wyjaśnień i zmian, które wskazują, że nie jest to istotne. Brak możliwości użytkowników na tej stronie (i głównie tylko na tej stronie) do oddzielenia pytania „powinienem” od „jak to zrobić” jest aktywnie szkodliwy dla ogólnej jakości i spójności dyskursu tutaj. Twoje zastrzeżenie jest ważne, ale nieistotne i nieco obraźliwe. Jest nawet bardzo wysoko głosowane meta pytanie dotyczące tego konkretnego tematu.
Aaronaught
1
@aronaught, jedynym powodem, dla którego twierdzisz, że chcesz zmienić ten styl kodowania osób, jest to, że różni się on od reszty zespołu, a następnie odłożyłeś jego styl, domyślając się, że twój jest lepszy. Stąd mój komentarz. Jeśli nie możesz zaakceptować jego obecnego stylu kodowania w bazie kodu, spotkaj się z nim osobiście i powiedz to, i że jesteś gotów włożyć duży wysiłek, aby pomóc mu dowiedzieć się, jak potrzebny jest jego kod.
1
@Aaronaught, dla osoby, która mogłaby się obejść bez akapitu pierwszego, uważam, że wybór sformułowania jest zaskakująco obraźliwy. Czy uważasz, że nazywanie innych żałosnymi jest przykładem do naśladowania?
1

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.

Ken Brittain
źródło
1
-1 Pytanie już stwierdza, że ​​PO nie ma zamiaru podejść do tego w sposób konfrontacyjny. Proszę dokładnie przeczytać pytanie PO i odpowiedzieć na to konkretne pytanie , zamiast ogólnie omawiać ten temat.
HedgeMage
1

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.

Martijn
źródło
0

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'

HLGEM
źródło
-1

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ę.

Grandmaster B.
źródło
2
Z tego powodu wskazałem, że pochodzi on z innej części firmy. Nie miał problemu ze spełnieniem ich wymagań, ale ich wymagania nie są naszymi wymaganiami. W szczególności ich wymagania nie stały się znacznie bardziej zaawansowane niż CRUD. I tak, jest problem z kodem; może działać dobrze w izolacji, ale nie przejdzie testów integracji, wydajności lub niezawodności. Nie wierzę w ścisłe metodologie, takie jak XP, TDD itp., Ale nie jest to kwestia estetyki ani konwencjonalnej mądrości, to kwestia wymagań konserwacyjnych.
Aaronaught
3
Głosuję również za tym nie z powyższych powodów, ale dlatego, że przyjmujesz kilka nieuzasadnionych założeń. (a) nie jestem mniej doświadczony, (b) żadna z rzeczy, o których mówię, nie są słusznie nazywane „modami”, oraz (c) to jest najbardziej rażąco absurdalne założenie - nie jest najbardziej produktywnym deweloperem zespół, a na pewno nie jest bardziej produktywny niż ja.
Aaronaught
Jeśli rzeczywiście jest problem z tym, co produkuje, to jak powiedziałem , jest to problem dla twojego przełożonego lub kimkolwiek jest twój wspólny przełożony. Ale nie pokazałeś, że jest problem z tym, co dostarcza klientowi / klientowi, tylko że nie podoba ci się to, co on ci dostarcza. O to mi chodzi, nie pisze dla ciebie oprogramowania. Więc zanim zaczniesz wywoływać zamieszanie, upewnię się, że nie jest mniej zbędny niż ty.
GrandmasterB
Jeśli chodzi o mody, poczekaj chwilę w branży, a zrozumiesz, że tak, dzisiejsze najlepsze praktyki to jutro złe praktyki w stylu VB6. Jeśli chodzi o głosowanie w dół, na pewno nie krępuj się. Po prostu odpowiadam na pytanie w formie, w jakiej zostało opublikowane. Nie mogę odpowiedzieć na szczegóły, których nie podałeś.
GrandmasterB
1
Nie znam twojego CV, ani twoich współpracowników. Wiem tylko, co postawiłeś w pytaniu. Jeśli była to ważna informacja, powinnaś ją dołączyć. Na podstawie twoich odpowiedzi na inne odpowiedzi możesz uznać, że pozostawiłeś dość nieobecny, co wymaga wielu założeń ze strony osób udzielających odpowiedzi. Ale jeśli chcesz uzyskać odpowiedź, zakładając, że nie jesteś jego przełożonym, to problem przełożonego lub twojego wspólnego przełożonego martwi się tym, jak nie wywołać zamieszania. Po prostu odrzuć kod, który powoduje problem podczas testowania, i zgłoś problem współpracownikowi.
GrandmasterB
-1

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.

wałek klonowy
źródło
1
Odpowiada to na zupełnie inne pytanie niż to, które zadałem. (a) Nie jestem młodszym programistą, (b) mój szef przekazuje mi już większość ważnych decyzji dotyczących projektowania i kodu, (c) jego kod nie jest błędny, po prostu nie jest dobrze zorganizowany dla OOP C # / funkcjonalny paradygmat mieszany, i (d) istotą mojego pytania było to, jak podejść do tematu w taki sposób, aby się nie obraził.
Aaronaught
1
@Aaronaught, a) „Ten programista jest trochę starszy ode mnie”. Z tego stwierdzenia wywnioskowałem, że jesteś jego „młodszym”. b) Wygląda na to, że jesteś wtedy liderem technologicznym, powinieneś umieścić tę informację w swoim pytaniu, to znacznie zmienia rzeczy. c) Jeśli nie przestrzega najlepszych praktyk, a jego kod nie zawiera błędów, to w czym problem? Po co do niego podchodzić? Nie naprawiaj tego, co nie jest zepsute. d) Ponownie nie zbliżaj się do niego, jeśli nie powoduje błędów ze słabym kodem jakości. Prawdziwy problem polega na tym, że nie masz standardów kodowania i rozwoju, których wszyscy muszą przestrzegać.
maple_shaft
Myślałem, że było to dość wyraźnie sugerowane przez moje odniesienie do (nie) „bycia z płonącą bronią i ustanawiania recenzji kodów rip-it-to-shreds i ściśle egzekwowanych zasad” - dlaczego miałbym nawet wspominać, że gdybym był młodszy ? A kto powiedział, że nie mamy standardów? Po prostu nigdy wcześniej nie pracował z naszym zespołem, a ja próbuję wprowadzić standardy, nie martwiąc się tym .
Aaronaught
-1 Nie odpowiedział na zadane pytanie.
HedgeMage
-1

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ą) .

Wayne Molina
źródło
4
Doceniam odpowiedź, jednak trudno mi w to uwierzyć głównie dlatego, że byłem dokładnie tego typu programistą „po prostu zrób to” kilka lat temu. Nikt mi nie pokazał - sam musiałem to wszystko odkryć - ale jestem pewien, że wystarczająco przekonujący przywódca (gdyby taki istniał) byłby w stanie dokonać tej samej zmiany. To, że niektórzy ludzie uczą się tego wszystkiego niezależnie, niekoniecznie oznacza, że wszyscy inni są straconą przyczyną.
Aaronaught
2
To prawda, ale z mojego doświadczenia wynika, że ​​jeśli ludziom zależy na ulepszaniu, potrzebują małej motywacji, aby czerpać inspirację, ponieważ pragnienie już istnieje - mogą potrzebować troski lub porady, ale rozumieją i chcą poprawić, potrzebują jedynie wskazówek. Byłem taki sam; Nauczyłem się złych sposobów robienia rzeczy i pomyślałem: „Musi być lepszy sposób” i rozpocząłem badania. Widziałem jednak ludzi, którzy nie ulegają poprawie lub wykazują chęć poprawy, utraconymi przyczynami, ponieważ nie chcą się poprawiać. To powiedziawszy, powodzenia w udowodnieniu, że się mylę :)
Wayne Molina
1
Myślę, że takie stwierdzenia wymagają uzasadnienia. Z pewnością chciałbym usłyszeć (i chętniej głosować) pewne doświadczenia w świecie rzeczywistym, w odniesieniu do tego, czego próbowaliście bezskutecznie (i dlaczego nie powiodło się).
Aaronaught
1
Jest to czasami prawdą, np. „ Stary pies, nowe sztuczki ” - spróbuj wyjaśnić komuś, w jaki sposób techniki zwiększyły wydajność pobierania danych o 800%, a współpracownik tylko wzrusza ramionami.
IAbstract
2
Chodzi o to, że możesz to zrobić, a ludzie będą cię śledzić, ale musisz zająć wyższą pozycję w hierarchii. W większości zespołów nie można tego zrobić jako prostego programisty. Wielu współpracowników może jedynie uzyskać niezapowiedziane porady od kogoś z wyższego szczebla w hierarchii. Jeśli jesteś na tym samym poziomie, poczują się zranieni i zaatakowani. Pamiętaj, że zdobywasz szacunek. Jeśli traktujesz je dobrze i komunikujesz to ładnie i przyjemnie, może działać, jeśli jesteś na tym samym poziomie.
Falcon