Jak poprawić juniora, ale zachęcić go do samodzielnego myślenia? [Zamknięte]

Jestem liderem małego zespołu, w którym każdy ma mniej niż rok doświadczenia w tworzeniu oprogramowania. W żadnym wypadku nie nazwałbym siebie guru oprogramowania, ale nauczyłem się kilku rzeczy w ciągu kilku lat, kiedy pisałem oprogramowanie.

Kiedy dokonujemy recenzji kodu, sporo uczę i poprawiam błędy. Powiem na przykład: „To jest zbyt skomplikowane i skomplikowane, a oto dlaczego” lub „Co sądzisz o przeniesieniu tej metody do osobnej klasy?” Szczególnie uważam, aby poinformować, że jeśli mają pytania lub zdania odrębne, jest to w porządku i musimy o tym porozmawiać. Za każdym razem, gdy kogoś poprawiam, pytam „Co myślisz?” lub coś podobnego.

Jednak rzadko, jeśli w ogóle, nie zgadzają się lub pytają dlaczego. A ostatnio zauważyłem bardziej rażące oznaki, że ślepo zgadzają się z moimi stwierdzeniami i nie formułują własnych opinii.

Potrzebuję zespołu, który może nauczyć się robić właściwe rzeczy samodzielnie, a nie tylko postępować zgodnie z instrukcjami. Jak poprawić młodszego programistę, a jednocześnie zachęcić go do samodzielnego myślenia?

Edycja: Oto przykład jednego z tych oczywistych znaków, że nie formułują własnych opinii:

Ja: Podoba mi się twój pomysł stworzenia metody rozszerzenia, ale nie podoba mi się, jak przekazałeś dużą złożoną lambdę jako parametr. Sonda lambda zmusza innych do zbytniej wiedzy na temat wdrażania metody.

Junior (po nieporozumieniu): Tak, całkowicie się zgadzam. Nie powinniśmy tutaj używać metod rozszerzenia, ponieważ zmuszają innych programistów do zbytniej wiedzy na temat implementacji.

Nastąpiło nieporozumienie, które zostało rozwiązane. Ale w jego wypowiedzi nie było nawet UNII logiki! Myślał, że zwraca mi moją logikę, myśląc, że to miałoby sens, gdyby naprawdę nie miał pojęcia, dlaczego to powiedział.

Krótka odpowiedź:

Zaangażuj ich (zapamiętaj puzzle), wzmocnij ich (zaufaj ich odpowiedziom).

To pytanie nas napędza! - Matryca.

Ogólnie, w moich spostrzeżeniach, że juniorzy mają swój własny świat - ich ograniczony pogląd na to, jak myślą, a po części własny entuzjazm / ulubione / opinie na temat rzeczy.

Nie ma nic złego w mówieniu im wprost, że się mylisz - ale najlepsze jest to, że każesz im myśleć. Dlaczego? Czy są jakieś inne sposoby? Czy są lepsze sposoby na zrobienie tego samego? Jedną z anegdot, których zawsze używam, jest: „Daj mi trzy rozwiązania (tego problemu)!”

Zanim pomyślą o tych rozwiązaniach, zaczynają zdawać sobie sprawę z wielu problemów. Zajmuje im to trochę czasu - ale z czasem mają tendencję do wizualizacji ograniczeń i wad ich myślenia. Zaczynają postrzegać to bardziej jako „Nie myślałem o tym!” co jest znacznie lepsze niż powrót do domu z poczuciem, że „się myliłem!” lub jeszcze gorzej „powiedziano mi / udowodniono, że się mylę, nawet gdy miałem ważne punkty widzenia” .

Ogólnie rzecz biorąc, bardzo małe dzieci będą wykazywały większą biegłość w kwestiach technicznych (takich jak to, który wzór projektowania działa lepiej!) W kwestiach związanych z procesem , ale z czasem, gdy je trenujesz, to działa.

Jednak rzadko, jeśli w ogóle, nie zgadzają się lub pytają dlaczego. A ostatnio zauważyłem bardziej rażące oznaki, że ślepo zgadzają się z moimi stwierdzeniami i nie formułują własnych opinii.

To na ogół jest wynikiem, że zrobić wziąć swoje propozycje, ale później uchylić je i są one równie przekonany o swoich poglądów; tylko dlatego, że jesteś starszy, unikają walki!

Najlepszą rzeczą, jakiej nauczyłem się od jednego z moich poprzednich szefów: najpierw poprosi członków zespołu o debatę (czują się tu dość równi) i, mam nadzieję, że po wyczerpaniu wszystkich argumentów, wejdzie do pokoju z jednym pytaniem - „Co to było? punkty niezgody? ” - Chodzi o to, że ludzie zawsze lubią brać udział w debatach i dyskusjach, ale jeśli ich (ważne) punkty nie zostaną podjęte następnym razem, uważają, że nie warto brać udziału w dyskusji.

Nie tylko w oprogramowaniu, ale wszędzie ostatecznie tylko najbardziej upoważnieni członkowie drużyny odważą się odpowiedzieć, nie mówiąc już o kwestionowaniu systemu.

Jeśli chcesz, aby juniorzy myśleli sami, nie poprawiaj ich: poproś, aby poprawili siebie .

Zamiast mówić im, co według nich jest nie tak o ich rozwiązaniu, zadaj im odpowiednie pytania. W twoim przykładzie możesz zapytać go, co ktoś, kto użyłby metody rozszerzenia, musiałby wiedzieć, aby utworzyć lambda. Zadawaj takie pytania, dopóki nie zasugerują, że to problem. W ten sposób wiesz, że zrozumieli, dlaczego ich rozwiązanie może stanowić problem, a ponadto są bardziej skłonni do uczenia się na ich podstawie - jeśli po prostu powiesz im, że ich rozwiązanie jest złe, jest to zewnętrzny osąd i łatwo zignorować. Jeśli dojdą do realizacji na własną rękę (z niewielkim podszeptem), zdadzą sobie sprawę z tego, jak dobrze są ugruntowane i będą o wiele bardziej prawdopodobne, że wyciągną naukę z błędu.

Ponadto, daje swoim juniorach szansę obrony swoich design - być może oni nie myślał o problemie i mają dobre uzasadnienie, które rozwiązuje swoje obawy, co oznacza, że nie ma potrzeby, aby robić żadnych poprawiania. Zmniejsza to wszelkie postrzeganie (choć niezamierzone), że rządzisz fiatem wykonawczym.

Ponieważ masz wielu młodszych programistów, przeglądaj kody jako grupa, a nie 1 1.

Otwórz, pytając grupę „Jak inaczej można rozwiązać problem?” I pozwól innym młodym programistom najpierw zasugerować ich implementacje. Dodaj swoją implementację dopiero po tym, jak przemówili inni członkowie zespołu, i jeśli nikt nie zasugerował czegoś podobnego do twojego pomysłu.

Następnie poprowadź dyskusję przy okrągłym stole na temat względnych zalet i wad różnych wdrożeń z zamiarem poprowadzenia młodszych twórców do wyboru najlepszej implementacji bez mówienia, co to jest.

Jako budowniczy zaufania dla młodszych deweloperów możesz zacząć od kilku przypadków, w których wybrali to, co według ciebie było najlepszą opcją, i uczynić z twojej alternatywy słomianego, który ma półoczywistą wadę i skierować dyskusję na to, dlaczego oryginalna implementacja jest najlepsza.

Kiedy zacząłem pracować jako programista, zrobiłem dokładnie to samo, co opisałeś: kiedy powiedziano mi o czymś, co mogę robić, zawsze się zgadzam. Było tak głównie dlatego, że nie miałem wystarczającego doświadczenia, aby powiedzieć inaczej.

Tym, co umożliwiło mi omawianie metodologii i pomysłów, było uczenie się na podstawie doświadczenia, a także czytanie różnych podejść i nowych technologii. Aby Twój zespół mógł samodzielnie myśleć, musi wiedzieć, jakie problemy mogą wynikać z takich „zbyt skomplikowanych i skomplikowanych” kodów, a jedynym prawdziwym sposobem, w jaki się dowie, jest doświadczenie.

Dobrym sposobem na ułatwienie indywidualnego myślenia jest przeglądanie stron internetowych z programowaniem, takich jak Stack Overflow lub Programmers SE. Wiem, że pomogły mi one poznać różne techniki, które tam były i pozwoliły mi na rozmowy ze starszymi członkami zespołu, zamiast ślepo się z nimi zgadzać.

Chodzi o to, że bez doświadczenia sugestie starszych członków zawsze będą dla nich odpowiednie.

Interakcja z Twoim postem pokazuje kluczową zasadę nauczania prawie wszystkiego: poproś ich o wyjaśnienie tego, co według ciebie powiedziałeś , i uważne wysłuchanie odpowiedzi: powie ci dokładnie, co należy poprawić.

I bezczelnie skradzione kopiowane ten trick z moim nauczycielem matematyki około 25 lat temu i nie udało mi od. Użyłem go na zajęciach podczas mojej krótkiej pracy jako asystent nauczyciela, w pracy, gdy rozmawiałem o projektowaniu oprogramowania, oraz z moją ośmiolatką, gdy mówiłem o jej szkolnych zadaniach.

Oczywiście nie zawsze możesz być tępy, prosząc ich o powtórzenie tego, co właśnie powiedziałeś, więc musisz dostosować swoją strategię. Na przykład oto, w jaki sposób chciałbym ponownie sformułować twoje oświadczenie uzupełniające z PO jako pytanie „próbne”:

Podoba mi się pomysł stworzenia metody rozszerzenia, ale nie podoba mi się, jak przekazałeś dużą złożoną lambdę jako parametr. Czy widzisz, w jaki sposób ta złożona lambda zmusza innych do zbyt dużej wiedzy na temat implementacji metody?

Odpowiedź na to pytanie jest niemożliwa bez zrozumienia problemu, który próbujesz podkreślić. Odkryłem, że zakończenie moich wyjaśnień pytaniem, które wymaga analizy tego, co właśnie powiedziałem, przyspiesza proces uczenia się i daje mi informację zwrotną, że muszę wprowadzić poprawki.

Zwykle, gdy ludzie nie mówią, co chcesz, oznacza to, że musisz popracować nad słuchaniem. Słuchanie oznacza zapoznanie się z uzasadnieniem ich projektu przed wydaniem wyroku. Oznacza to nie tylko powiedzenie im, że można się sprzeciwiać, ale udowodnienie tego poprzez uczciwe rozważenie tego, co mają do powiedzenia, a nie tylko ich poprawienie. Poszukaj dobrych rzeczy na temat ich rozwiązania i zmodyfikuj swoje rozwiązanie, aby uwzględnić te rzeczy.

Musisz także dawać przykład. Nie mam na myśli pisania niesamowitego kodu, mam na myśli poproszenie ich o opinię na temat twoich własnych projektów. Nie czekaj na recenzje kodu po fakcie, ale pracuj razem przez cały czas. Powiedzmy na przykład: „Mój interfejs wydaje się zbyt skomplikowany, ale nie jestem pewien, jak najlepiej go uprościć”. I daj im czas na odpowiedź bez uprzedzania ich o własne pomysły.

Kiedy musiałem sobie z tym poradzić, powiedziałem (szczerze) takie rzeczy jak:

Wiesz, to naprawdę kreatywne rozwiązanie, o którym nigdy bym nie pomyślał. Jak się skaluje? / Czy uważasz, że może istnieć podejście, które jest koncepcyjnie prostsze, aby przyspieszyć rozwój lub konserwację? / Niestety, nie sądzę, że tak naprawdę pasuje do reszty architektury projektu. / Co będzie konfiguracja wygląda?

Zazwyczaj wystarczało to, aby wskazać ludziom nowy kierunek.

Odpowiedzialność to jedna rzecz, która może im pomóc.

W przeszłości prowadziłem zespół lub dwa, a jedną z rzeczy, które sprawiały, że juniorzy świeciły, był ciężar osobistej odpowiedzialności. Kiedy ktoś zdaje sobie sprawę, że jego działania mogą w pewnym momencie mieć na niego wpływ, zwykle popełnia nieco więcej siebie w tym, co robi. Nie wspominając, że kiedy czują swoją pracę, dobre wyniki są znacznie bardziej satysfakcjonujące.

Nie martwiłbym się zbytnio faktem, że ślepo podążają za tobą, to właśnie powinni robić jako juniorzy. Chodzi o to, że prawdopodobnie nie zrozumieją prawdziwych przyczyn elementów, które omawiasz w recenzjach kodu, dopóki nie znikną i nie pracują w innym miejscu, w którym znajdują się okropni twórcy oprogramowania, okropne zarządzanie i okropny kod.

Do tego czasu nauczyli się dobrych praktyk z przyzwyczajenia i będą musieli żyć z błędami w kodowaniu i projektowaniu, które popełniają inni, i są zmuszeni do tego, aby musieli teraz pracować na źle zaprojektowanym i zaimplementowanym oprogramowaniu.

W pewnym momencie ich kariery będzie to nieuniknione. Robisz im świetną usługę, przyzwyczajając się do dobrych standardów i praktyk kodowania. Niestety większość z nas musiała nauczyć się na własnej skórze.

Opierając się na podanym przykładzie, powiedziałbym, że najlepszym rozwiązaniem byłoby śledzenie twoich komentarzy za pomocą pytań. Jeśli zadajesz pytanie wraz z komentarzami, nie pozostawia im to po prostu zgodzić się lub nie zgodzić, że przynajmniej muszą pomyśleć o tym, jak mogą coś zaimplementować.

np. „Podoba mi się pomysł stworzenia metody rozszerzenia, ale nie podoba mi się, jak przekazałeś dużą złożoną lambdę jako parametr. Siła lambda zmusza innych do zbyt dużej wiedzy na temat implementacji metody. Czy możesz wymyślić lepszy sposób na wdrożyć tę metodę rozszerzenia, która nie ujawnia tylu informacji? ”

To pozwala im zobaczyć błędy w tym, co rozwijają, a jednocześnie daje im możliwość rozwiązania problemu, który wprowadzili do aplikacji.