Co powinieneś zrobić, jeśli twój uczeń nie przyjął twojej sugestii? [Zamknięte]

Kieruję zespołem 3-4 młodszych programistów. Moim zadaniem - oprócz pisania kodu - jest zapewnienie nadzoru i wskazówek dla juniorów.

Ale w pełni rozumiem, jak bardzo programiści cenią sobie autonomię w swojej pracy, i nie chcę niszczyć ich wewnętrznej motywacji, karmiąc je łyżeczką moimi myślami i algorytmami; Chcę, aby zbadali problem na swój własny sposób i pomyśleli o tym sami i przyszli do mnie tylko wtedy, gdy naprawdę mają problemy nie do pokonania.

Kiedy do mnie przychodzą, czasami musiałbym zaproponować zupełnie inny algorytm, aby rozwiązać problem, ponieważ ich algorytm nie jest wystarczająco solidny (pamiętaj, że jestem starszy i widziałem więcej niż oni). Oczywiście wyjaśniłbym to w miły sposób, aby nie zranić ich uczuć, i delikatnie nakreśliłem, w jaki sposób moje rozwiązanie jest znacznie lepsze niż ich, bez protekcjonalnego tonu ani potępiających słów.

Mimo to czasami nie chcą zaakceptować mojej sugestii, częściowo dlatego, że zainwestowali tyle w swój własny algorytm, albo częściowo ze względu na obawę, że zastosowanie nowej metody pociągnie za sobą więcej czasu na naukę i sprawi, że będą wyglądać na kierownictwo tak, jakby nigdzie się nie wybierasz. Ale w głębi serca bardzo dobrze wiem, że mój algorytm jest znacznie lepszy niż ich i powinni go po prostu przyjąć.

Co powinienem zrobić, jeśli nie przyjęli mojej sugestii? Czy powinienem po prostu poprosić ich, aby podążyli moją drogą, czy też powinienem pozwolić im jeszcze raz uderzać głową o ścianę i czekać, aż wrócą do mnie? Robienie tego pierwszego czyni mnie dyktatorem, ale robienie tego później kosztowałoby nas cenny czas programowania i wiązałoby się z kosztami naprawy błędów. Naprawdę mam tutaj dylemat.

Pomóż im zrozumieć, dlaczego powinni dokonać sugerowanej zmiany. I posłuchaj ich, jeśli mają dobry powód, aby nie wprowadzać zmian. Dyskutuj i osiągnij porozumienie na podstawie tego, co najlepiej zrobić.

To podejście jest ważne z następujących powodów:

• Chcesz, aby wprowadzali zmiany z ważnych powodów biznesowych / technicznych. Ważne jest, aby wyjaśnić, co to jest (pamiętajcie, że możecie się również mylić, więc bądźcie pokorni ...).
• Naprawdę chcesz przekazać uzasadnienie swojej sugestii - w ten sposób odbiorca nauczy się samodzielnie rozwiązywać podobne problemy w przyszłości. Będziesz także mieć lepszy związek, jeśli Twoi juniorzy czują, że uczą się od ciebie dobrych spostrzeżeń.
• Nie będziesz szanowany, jeśli wykorzystasz swoje staż pracy i nie możesz udowodnić, że faktycznie masz dobre powody.
• Twój szef prawdopodobnie chciałby mieć pewność, że efektywnie wykorzystujesz czas juniorów na rzeczy, które tworzą prawdziwą wartość, a nie tylko „robi to po swojemu” ze względu na to.

Jeśli jesteś mądry, możesz też zachęcić ich do odpowiedzi, zadając pytania . Zrobione dobrze, twój junior sam dojdzie do właściwego wniosku (i dlatego będzie o wiele bardziej chętny do jego wdrożenia). Przykładowe pytania:

• Twój kod zakłada dostęp do produkcyjnej bazy danych. Jak możemy to zmienić, aby nadal działało i mogło być poprawnie przetestowane przez JUnit w odłączonym środowisku programistycznym? (potencjalna odpowiedź: ah! powinniśmy użyć zastrzyku zależności ....)
• Co się stanie, jeśli osoba atakująca celowo wyśle ​​sprytnie skonstruowany kod SQL w formularzu wprowadzania danych online? (potencjalna odpowiedź: ah! być może nie powinniśmy konstruować instrukcji SQL łącząc niezweryfikowany tekst z Internetu)

EDYCJA : Jeśli uda ci się przekonać swojego juniora, że ​​właściwą rzeczą jest postępować zgodnie z twoją sugestią, ale nadal są niechętni, oto kilka dodatkowych porad:

• Dowiedz się, dlaczego są niechętni. Możliwe, że będą musieli zdać sobie sprawę, że nie ma znaczenia, czy wyrzucisz kod, pod warunkiem, że otrzymasz wynik. Być może odczuwają presję czasu z powodu pewnego terminu. Musisz wiedzieć, inaczej nie możesz im pomóc .....
• Możesz powiedzieć, że mogą potraktować zmianę jako sposób na poprawę swoich umiejętności refaktoryzacji. Gdy umiejętności refaktoryzacji są wystarczająco dobre, powinieneś być w stanie zmienić przeznaczenie nawet dość dużej i złożonej bazy kodu stosunkowo szybko.
• Powinieneś podkreślić, że wszystko będzie pod kontrolą źródła, więc w razie potrzeby zawsze mogą wrócić do starej wersji.

Nienawidziłem postawy apodyktycznej ostatniego lidera zespołu, ale szanuję go za to, że miał doskonałą wiedzę techniczną i wiele mnie nauczył bez wykładania. Co najważniejsze, nigdy nie zmusił mnie do realizacji swojego planu. Grałby adwokata diabła w moim planie, zmuszając mnie do udowodnienia, że ​​mój plan był bezbłędny. Szukał luk i czekał na moje wyjaśnienie, dlaczego nie jest to luka lub jest tańszym rozwiązaniem. Zapytałby mnie, czy są jakieś alternatywne rozwiązania i zaproponowałby jakieś pomysły, gdybym ich nie miał. Musiałbym ocenić jego pomysły i upewnić się, że jego plan nie był optymalny lub Gdyby był przekonany, że mój plan był słuszny lub przynajmniej miał taki sam stosunek ryzyka do zysku jak on, dałby zielone światło. Jeśli mój pomysł się nie powiedzie, będę musiał wypróbować jego rozwiązanie.

Musi istnieć kompromis między wolnością a terminami. Nie masz luksusu przedłużania terminu i nie możesz pozwolić, by jego juniorzy go przekroczyli. Musisz być uprzejmy, ale stanowczy wobec nich, że kiedy wypróbują swój algorytm i nie uruchomią go, mają obowiązek cię wysłuchać. Udowodnij na przykładzie, że znasz swoje rzeczy. Ale równie ważne jest, aby uczyli się, nie uczcie ich.

Jeśli jest to wymóg, zanotuj to w ten sposób. Jeśli jest to tylko sugestia, jak zauważasz, powinni mieć swobodę, aby zrobić to inaczej. Kilka pytań, które chciałbym zadać:

• Czy masz prawo naciskać na konkretne rozwiązania?
• Jaki jest zasięg tego organu?
• Czy istnieje rozwiązanie złe czy po prostu inne?

Jestem pewien, że możesz zapytać o więcej, ale dwa pierwsze skupiają się na twoim autorytecie, a ostatnie na tym, czy naprawdę warto popchnąć tę kwestię.

Poniższa odpowiedź zawiera kilka świetnych dodatkowych punktów i dodam tutaj, że musisz potraktować ją bardziej jako proces współpracy, w którym pracujesz przez co najmniej niektóre z nich ze swoim „zespołem”, a nie tylko wydajesz im dyktanda. Będą się uczyć podczas pracy nad problemami więcej niż tylko powiedziano im: „rozważ to zrobić w ten sposób”.

Uczenie się naprawdę dzieje się tylko tam, gdzie występują awarie, ponieważ porażka jest motywatorem i zapewnia wskazówki dotyczące pamięci do przywołania w przyszłości. To jest właśnie to, co nazywamy doświadczeniem, a dobre doświadczenie w miejscu pracy będzie wynikać z porażki i uczenia się z porażek. Jeśli twoi juniorzy byliby w stanie uzyskać wszystko poprawnie za pierwszym razem, albo nie mogliby się niczego uczyć, albo nie byliby juniorami.

Jeśli masz zbyt wielu juniorów, którzy psują rzeczy, być może Twoja firma zatrudniała niepoprawnie pracowników, ze zbyt dużą liczbą programistów młodszych klas, gdzie ograniczenia czasowe wymagają bardziej doświadczonych ludzi, aby zminimalizować ryzyko, ale nawet wtedy możesz mieć problemy i opóźnienia, ponieważ starsi programiści popełniają błędy uczyć się również.

Twoi juniorzy będą musieli się uczyć i zdobywać doświadczenie, aby móc radzić sobie w środowisku, w którym terminy są napięte. Jako lider zespołu Twoim zadaniem jest dawanie przykładu i inspirowanie juniorów do wydajnej pracy, jednak w rzeczywistości musisz odłożyć na bok obawy o osobistą dumę i obawy o napięte harmonogramy, jeśli chcesz, aby juniorzy czegoś się nauczyli i dlatego musisz pozwolić im upaść. Dlatego Twoim zadaniem jest nawiązanie połączenia. Czasami musisz dać dziecku miejsce na porażkę, a następnie cierpliwie przejść przez proces przeglądu, aby pokazać im, gdzie mogą poprawić swoje pomysły. Innym razem musisz postawić stopę, ale rób to w sposób, który pozwoli ci pokazać, że robi to z prawdziwej potrzeby, która nie odbija się źle na umiejętnościach juniora per se.

Jeśli chodzi o kwestię napiętych terminów, to tutaj musisz zaplanować i przydzielić pracę zgodnie ze względnymi mocnymi i słabymi stronami w zespole. Ostatecznie złotówka zatrzymuje się na tobie. Kiedy kierujesz innymi, nie jesteś przyjacielem wszystkich, jesteś w stanie wykonać trudną pracę w trudnych okolicznościach. To, w jaki sposób utrzymujesz wszystkich po swojej stronie, sprowadza się do rozmawiania przez ludzi o twoich obawach i problemach, uzasadniając to tym, dlaczego potrzebujesz członków zespołu, aby zrobić coś w określony sposób.

Z moich osobistych doświadczeń wynika, że ​​musisz zarezerwować określony czas ze swoim młodszym uczniem, aby omówić mocne i słabe strony obu pomysłów, a następnie wspólnie szukać najlepszego rozwiązania, które rozwiąże dany problem - nawet na ryzyko pozwolenia sobie na udowodnić, że się mylą - a następnie iść do przodu. Jeśli oboje nie zdołacie osiągnąć konsensusu przed upływem wyznaczonego czasu, wówczas musicie zakończyć spotkanie podsumowaniem, które uwzględnia omówione obawy i zauważa, że ​​nie osiągnięto konsensusu. Niezależnie od wyniku spotkania dziękujesz juniorowi za poświęcony czas i zaznaczasz, że wrócisz swoją decyzjąwkrótce. Po starannym rozważeniu dyskusji będziesz mieć możliwość przydzielenia dodatkowego czasu na dalszą dyskusję lub poinstruowania juniora, aby wybrał plan, który ustaliłeś, w zależności od wyniku spotkania.

Tak, czas jest czasem cenny, jednak kiedy decydujesz się na przyjęcie juniorów, musisz zaakceptować fakt, że bierzesz na siebie odpowiedzialność za inwestowanie i wspieranie ich rozwoju zawodowego, i musisz to zaakceptować, przez pewien czas przynajmniej kosztują twój czas.

Chciałbym zapytać, czy faktycznie przedstawiasz swoją sugestię w sposób, który nie jest protekcjonalny. Gdy używasz wyrażeń takich jak:

moje rozwiązanie jest znacznie lepsze niż ich

i

głęboko w sercu bardzo dobrze wiem, że mój algorytm jest znacznie lepszy od ich i powinni go po prostu przyjąć.

sprawia, że ​​myślę, że możesz mieć podejście „moja droga jest lepsza”. Nikt nie lubi takiej postawy. Kiedy otrzymałem go w przeszłości, aktywnie starałem się użyć innego algorytmu, aby udowodnić, że dana osoba się myli. Możliwe, że twoi juniorzy robią to samo.

Lepszym sposobem powinno być usiąść z osobą i przedyskutować jej algorytm. Wskaż, dlaczego uważasz, że to nie zadziała, i słuchaj odpowiedzi, które dają ci z otwartym umysłem. Sprawdź, czy ich algorytm można zmodyfikować, aby działał poprawnie.

Jeśli to, co masz młodszy na pewno nie zadziała, to wytłumacz im, dlaczego to nie zadziała. Które części są niepoprawne lub będą wymagały późniejszego przepisywania lub nie będą pasować do modelu biznesowego. Upewnij się, że dobrze rozumieją twoje powody. Następnie wyjaśnij im swój algorytm, wskazując fragmenty, w których mógłby działać, a ich kod zawodzi.

Po pierwsze, czy znasz prawdziwy powód, dla którego twój uczeń nie przyjął twojej sugestii?

Czasami wiesz, że junior może napisać coś lepszego niż jego starszy ze względu na nowsze perspektywy i bardziej aktualną edukację CS. Chociaż jako starszy mógłeś widzieć więcej przykładów z prawdziwego świata. Ale złą pułapką, którą często widzę, kiedy moi seniorzy wpadają, jest zapominanie, że najlepsze praktyki mogą się z czasem zmienić. Jestem pewien, że nie dotyczy to Ciebie, ponieważ aktualizujesz się na takich stronach. ;)

Proponuję spróbować zbliżyć się do swoich juniorów bez jakiejkolwiek (lub małej) „aury” seniora, spróbować rozmawiać z nimi na poziomie, okazywać ciekawość w napisanym przez siebie kodzie. Zadawaj pytania, słuchaj ich odpowiedzi. Nie pytaj w sposób oskarżający, taki jak:

„Twój kod jest dość nieelastyczny, musisz go zmienić na ten ...”

zamiast tego zapytaj

„Zastanawiam się, co jeśli ktoś… czy twój kod sobie z tym poradzi?… Myślę, że wzorzec strategii może tu pomóc. Co myślisz?”

Wierzę, że to pomoże ci zaangażować się w zdrowsze rozmowy z nimi niż jak profesor / wykładowca spoglądający na nich z góry. Pomoże Ci również lepiej poznać ich uzasadnienie i perspektywy.

Czy kontrolujesz dostęp push do repozytorium?

W open source dostęp push jest zawsze kontrolowany przez strażnika odpowiedzialnego za egzekwowanie jakości. Jeśli aktywnie monitorujesz zmiany, które oni popychają, powinieneś być świadomy tego, gdzie mogą się poprawić.

Czy mogą włamać się lub poprawić kod? Jeśli będą mieli okazję zobaczyć elementy wewnętrzne dotyczące działania kodu, mogą dowiedzieć się, jak lepiej dostosować się do Twojego stylu. Jeśli wysyłasz swoje sugestie bez przyjmowania sugestii z otwartym umysłem, będą one mniej skłonne do wysłuchania Twojej opinii.

Istnieją pewne okoliczności, w których nie ma właściwej odpowiedzi (takie jak preferencje stylu kodowania). W takim przypadku spróbuj ustanowić (lub egzekwować) zasady obowiązujące w całej firmie, aby zrozumiały, że styl kodu powinien być dostosowany do głównej bazy kodu. Korzystanie z ustalonych już wytycznych dotyczących stylu (takich jak przewodnik po stylu Microsofts dla C #) jest najlepszym sposobem, szczególnie dla nowych programistów w zespole.

Jeśli wypowiadasz się ogólnie o ich technikach kodowania, istnieje spora szansa, że ​​nie rozumiesz całkowicie uzasadnienia ich wyborów. Sam ton twojego pytania sprawia, że ​​brzmisz arogancko. Co zyskujesz / poświęcasz, popychając swoje podejście do młodszych programistów?

Kluczowym pytaniem, które musisz sobie zadać, jest to, czy twoje sugestie mają na celu utrzymanie / poprawę jakości bazy kodów lub potwierdzenie dominacji / wyższości nad rówieśnikami? Pierwsza z nich to prosta kontrola jakości i może być uzasadniona jako taka, drabina jest szkodliwa dla dynamiki zespołu, niezależnie od tego, czy masz rację.

Tak czy inaczej, jeśli chcesz przeforsować swoje rozwiązanie na swoich rówieśnikach, powinieneś mieć konkretny dowód, że w rzeczywistości jest on lepszy. Wzrost wydajności powinien być łatwy do poprawienia, nic mniej nie jest warte wysiłku (z wyjątkiem aplikacji krytycznych pod względem wydajności). Zmuszanie twojej pracy do usprawiedliwienia twojego osobistego poczucia wyższości skończy się tym, że zostaniesz wyróżniony jako „sprośny starzec”.

Uwaga: Najlepsi i najbardziej utalentowani programiści, z którymi zetknąłem się przez lata, zawsze wydawali się tymi, którzy byli gotowi zatrzymać się i wyjaśnić historię, z której pochodzą.

Cóż, wydaje się to interesujące i bardzo naturalne w przypadku młodych programistów bardzo przywiązanych do kodu, który napisali, być może spędzili sporo czasu na dotarciu do tego samego lub wybrali go z dobrej strony (tak, hej Jon skeet napisał to mężczyzna ! !).

Niemniej jednak dołączony tutaj podstawowy ciąg zawiera załącznik z kodem, w którym należy skoncentrować się i myślę, że trzeba by włożyć znaczny wysiłek, aby zrozumieć, że wykonanie i oczekiwany wynik ma większe znaczenie niż ich nazwa wyryte w repozytoriach źródłowych do wypychania tego kodu. Będziesz musiał narysować linie wyjaśniające, dlaczego Twój kod jest lepszy, a także dobry z punktu widzenia zachowania go do przyszłych prac.

Weź pod uwagę, że kilka porażek jest znaczących (potrzeba kilku złamań serca dla każdego przywiązania), ale ze stopniowym wysiłkiem myślę, że się pojawią i będą w stanie lepiej docenić twoje wysiłki. Myślę, że potrzebujesz trochę czasu i kilku awarii. Narzucenie im tego byłoby odwrotnością kilku historii sukcesu, a następnie zguby i buntu.

Każdy ma inny styl. Jeśli znajdziesz 10 różnych osób i przedstawisz im nietrywialny problem, zaproponują ci 10 różnych podejść przy użyciu 10 różnych stylów „standardów kodowania”.

Chodzi o to: wybierz rzeczy, które mają znaczenie. Jeśli coś jest prezentowane przez juniora, który nie daje właściwego rozwiązania, robi to rażąco nieefektywnie (+1 rząd wielkości, nie ma instrukcji tu czy tam) lub tworzy lukę w zabezpieczeniach, następnie wyjaśnij swój problem i dlaczego. Jeśli jest to komentarz „Zrobiłbym to”, to świetnie, zrobiłbyś „to”, a ona zrobiła „coś innego”, ale problem jest nadal wystarczająco rozwiązany (patrz powyższe punkty). Przejdź do następnej funkcji lub poprawki.

Częścią uczenia się bycia dobrym liderem jest umiejętność rozpoznawania tego, co naprawdę ma znaczenie, a co naprawdę nie. Ponadto usuwasz siebie jako potencjalne wąskie gardło w wydajności grupy, jeśli będą musieli sprawdzać wszystko przez ciebie.

EDYCJA: upewnij się, że twoje sugestie są prawdziwe i nie zawoalowane. Sugestia jest po prostu sugestią, którą można dowolnie zastosować lub nie. Jeśli jest to wymóg, podaj go jako taki.

Jak zauważyli niektórzy inni, jeśli naprawdę udowadniasz młodszym programistom sugestie i są one tak sformułowane, to naprawdę nie masz zbyt wielu powodów, aby się na nich denerwować, jeśli nie zastosują się do nich, ponieważ mogą nie widzę wielu powodów, aby to robić. Podobnie, naprawdę nie możesz ich zganić za to, że nie zastosowali się do twoich sugestii, ponieważ nie są one właściwym kierunkiem do robienia rzeczy w określony sposób.

Jeśli chodzi o próbę nakłonienia młodszych programistów do robienia rzeczy, które wolisz:

• Kontroluj swoją terminologię, sugerowanie nie jest tym samym, co zalecanie, które zdecydowanie nie jest tym samym, co udzielanie wskazówek . Stosuj terminologię odpowiednio, aby uzyskać punkt, a jeśli uważasz, że twój sposób robienia czegoś jest lepszym sposobem, powiedz im, że jest to twoja rekomendacja. Podobnie, jeśli absolutnie krytyczne jest, aby rzeczy były wykonywane w określony sposób (tj. Nie mogą wytrzymać opóźnienia czasowego), po prostu bądź tępy i daj im wskazówki, jak to zrobić.
• Młodsi programiści wciąż przechodzą proces uczenia się, niezależnie od tego, w jaki sposób frazujesz rzeczy, zawsze przedstawiając uzasadnienie tego, co im mówisz, chyba że istnieje konkretny powód, dla którego nie możesz tego zrobić. Nawet w takim przypadku większość ludzi zrozumie, jeśli powiesz coś w stylu „To musi być zrobione w ten sposób, sam nie dbam o to, ale decyzja już została podjęta”. wydają się być dość rozsądne.
• Jeśli naprawdę jest to tylko sugestia, upewnij się, że Twój pomysł jest rzeczywiście lepszy niż w jaki sposób. Jeśli nie uważasz, że tak jest, usiądź z deweloperem i dokonaj przeglądu kodu i koncepcji, aby uzasadnić swoje rozwiązanie. Może się zdarzyć, że gdy zaczną wyjaśniać to komuś innemu - a ty zadasz właściwe pytania - zobaczą lepszy sposób i będą chcieli sami przepisać różne rzeczy.
• Nie spieraj się o szczegóły, jeśli ich rozwiązanie jest podobne do tego, co pierwotnie zasugerowałeś, może być tak, że wzięli pod uwagę to, co im powiedziałeś, i zrobili coś nieco inaczej lub zmienili pierwotną koncepcję w oparciu o twoją sugestię.

Jest to idealne wprowadzenie do testów jednostkowych. Jeśli twoi młodsi deweloperzy mają rozwiązanie, powinno być możliwe do przetestowania. Poproś, aby przygotowali test jednostkowy w celu obciążenia kodu. Następnie przejrzyj test jednostkowy . Jeśli możesz wykazać dziury w teście, łatwo jest je ponownie uruchomić i zobaczyć, jak ich roztwór pęka pod ciśnieniem.

Pozwala to pokazać im, dlaczego Twoje rozwiązanie jest lepsze, daje test jednostkowy, którego można użyć ponownie, gdy zmienia się kod, i zapewnia młodym programistom cenne doświadczenie edukacyjne. I kto wie, może się okazać, że ich rozwiązanie jest w porządku.

W pewnym momencie musisz być odpowiedzialny. Brzmisz tak, jakbyś starał się wyrazić swoją opinię. Twoje sugestie mogą nie być idealne. Inni deweloperzy mogą nie rozumieć / zgadzać się z tobą. Prawdopodobnie nie zgadzają się ze sobą. Jeśli dowodzisz, nie jest to demokracja. Wiedzieli to, kiedy podjęli pracę.

Jeśli nie ma sytuacji, w których muszą iść za tobą, nie zasługujesz i nie służysz jako ich szef. Zmień swoją rolę w zespole, aby była zasobem, a nie organem, jeśli nie planujesz go używać. W pewnym momencie musisz wysłać najlepszy kod, jaki możesz w ramach ograniczeń czasowych, które są dostępne i nie mogą debatować, badać i debatować ponownie w każdym wierszu kodu do końca czasu.

Wydawaj rozkazy. Żyj z konsekwencjami. Ucz się z doświadczenia. Szacunek to ulica dwukierunkowa. Demonstrujesz to, a oni nie.