Jak sprawić, by ludzie przestali jeździć rowerem (koncentrując się na trywialnościach)?

139

Zadanie polegało na nauczaniu innych zespołów nowej bazy kodu, ale ciągle napotyka problem. Ilekroć wchodzę do kodeksu z ludźmi, nie docieramy zbyt daleko, dopóki całe ćwiczenie nie przekształci się w trening rowerowy (członkowie organizacji przykładają nieproporcjonalną wagę do trywialnych problemów). Ponieważ nie znają bazy kodu, ale myślą, że muszą pomóc ją ulepszyć, skupiają się na rzeczach, które mogą zrozumieć:

Why is that named that? (2 minuty na wyjaśnienie, dlaczego tak się nazywa, ponad 10 minut debatowania nad nową nazwą)

Why is that an abstract base class rather than an interface? (2 minuty na wyjaśnienie, ponad 10 minut omawiających względne zalety tej decyzji)

...i tak dalej. Nie zrozumcie mnie źle - dobre nazwiska i dobry, spójny projekt są ważne, ale nigdy nie rozmawiamy o tym, co właściwie robi kod ani jak zaprojektowano system w jakikolwiek znaczący sposób. Zrobiłem sędziowanie na spotkaniach, aby wyciągnąć ludzi z tych stycznych, ale ich nie ma - rozproszony przez to, jaki kod będzie / powinien być, gdy ich banalna trywialność zostanie naprawiona, i brakuje im szerszego obrazu.

Więc próbujemy ponownie później (lub z inną częścią bazy kodu), a ponieważ ludzie nie mieli wystarczającej wiedzy, aby przezwyciężyć efekt rowerowego roweru, powtarza się.

Próbowałem mniejszych grup, większych grup, kodu, tablicy, diagramów Visio, gigantycznych ścian tekstu, pozwalając im po prostu argumentować to na śmierć, natychmiast zmniejszając argumenty ... niektóre pomagają bardziej niż inne, ale nic nie działa . Do diabła, próbowałem nawet wytłumaczyć to innym osobom z mojego zespołu, ponieważ myślałem, że być może źle mówię.

Jak zatem edukować innych programistów na tyle, aby przestali się skupiać na trywialnościach i mogli znacząco przyczynić się do projektowania?

Telastyn
źródło
44
Nienawidzę tego mówić, ale wydaje mi się, że to zjawisko ilustruje więcej problemów z bazą kodów niż z nowymi.
Nicole,
30
Czy próbowałeś odłożyć pytania do końca? „Poczekaj jeszcze kilka minut, a ja wyjaśnię na końcu”, a następnie przejrzyj resztę treści. Być może niektóre z tych pytań same sobie odpowiedzą
jozefg
21
@NickC, uważam, że to, czy kod jest dobry, czy nie, nie ma nic wspólnego z tym, jak go rozumiesz, jak sobie z nim poradzić. Marnowanie czasu na drobne szczegóły od samego początku bez poświęcania czasu na pierwsze duże zdjęcie jest złe i nigdy nie pomoże w naprawie tego potencjalnego złego kodu.
Shivan Dragon,
11
Jaki jest cel nauczenia kogoś bazy kodu? Być może możesz przekazać ten cel jaśniej i dlaczego jest to ważne, aby mogli zobaczyć, że debata nad nową nazwą obiektu odwraca uwagę od tego celu i powinna być zarezerwowana na kolejne spotkanie.
LarsH
56
W tych odpowiedziach znajduje się dobra rada. Chciałbym krótko dodać: rozważ użycie „procesu” jako swojego sojusznika. Kiedy ktoś mówi „ten projekt jest nieoptymalny”, prawidłowa odpowiedź jest „doskonała, cieszę się, że to zauważyłeś. Po tym spotkaniu wpisz błąd w bazie danych śledzenia ze szczegółowym opisem problemu i proponowaną poprawką. Zespół triage przejrzy twoją propozycję, uszereguje ją priorytetowo względem pozostałych elementów pracy i przydzieli do odpowiedniego programisty, aby ją naprawić, gdy wszystkie elementy o wyższym priorytecie zostaną naprawione. Przechodząc ...
Eric Lippert

Odpowiedzi:

159

Myślę, że problemem jest zadanie: „Zadanie polegało na nauczeniu innych zespołów nowej bazy kodu”.

Otrzymałeś niewłaściwą pracę, a może źle zinterpretowałeś otrzymaną pracę.

Prezentując się na poziomie kodu, zapraszasz do myślenia na poziomie kodu.

Zacznij od poziomu systemu i przedstaw projekt oraz dokonane wybory projektowe. Nie zezwalaj na dłuższą dyskusję: nie recenzujesz jej. Pozwól na pytania: chcesz, aby rozumieli system. Jeśli ludzie „zrobiliby to inaczej”, w porządku. Może się zgadzam. Albo nie. Ale idź dalej. Tak jest teraz.

Gdy przejdziesz do poziomu kodu, będziesz już mieć je zalane terminologią systemu. Nazwy (zakładam) będą miały sens. To samo co powyżej: brak przedłużonej dyskusji, pytania do zrozumienia. Pójść dalej.

Teraz ustaw niektóre problemy klasowe do rozwiązania. Jak możemy ulepszyć X? Wybierz coś, co nie jest trywialne, a które „idzie w parze” z projektem systemu i pracuj nad tym, co chcesz zmienić. Powinni teraz uzyskać uzasadnienie systemu. Wybierz inne ulepszenie, które może uszkodzić system, jeśli zostanie wykonane nieprawidłowo, i pokaż, jak można to zrobić poprawnie. To powinna być dla nich chwila Ah Ha . Niektórzy mogą cię nawet pobić!

To trudny koncert, zwłaszcza po fałszywym starcie, który miałeś. Wygląda na to, że zainwestowałeś już dużo czasu i wysiłku, a może jest trochę ja w stosunku do nich. „Odwal się i zacznij od nowa. Zakładamy, że są to mądrzy ludzie. Podejmij wyzwanie myślenia na wyższym poziomie. I rozbić grupy, które już istnieją, wybierając różne przekroje zespołów dla nowych sesji.

andy256
źródło
3
Najpierw wykonałem trochę instrukcji projektowania na wysokim poziomie, a także przeszkoliłem w zakresie nowych / nieznanych technologii (pojemniki IoC, dynamika), aby pomóc w przygotowaniu. Trening poszedł całkiem dobrze. Dobrze jest podnieść.
Telastyn
+1 fot, nie próbując walczyć z ludźmi z „psychicznymi hackami”, takimi jak „Odpowiem na twoje pytania poza tematem w twoim czasie!” ale raczej zmieniają punkt widzenia
Buksy
3
Fantastyczna odpowiedź. Szczególnie podoba mi się sugestia, aby skupić się na tym, co robi, a nie na tym, jak nazywają się jego wewnętrzne komponenty.
Daniel Hollinrake
66

„Zaparkuj je”. Na początku lekcji wyjaśnij, co chcesz omówić, i jasno wyjaśnij, co jest uważane za nie na temat. Jeśli zostanie zadane pytanie, które jest wyraźnie OT, powiedz tak i przejdź dalej. Jeśli wrócą, napisz pytanie na tablicy (jest to bardzo ważne) do późniejszej dyskusji i przejdź dalej. Pod koniec lekcji, kiedy są w swoim czasie, a nie twoim, obserwuj, jak szybko te pytania zostaną rozwiązane.

mattnz
źródło
8
+1 W ten sposób ludzie czują, że nie są ignorowani.
andy256,
Zgadzam się z tym. JEŻELI problemem jest zbyt długie omawianie nieistotnych rzeczy, nie dyskutuj o nieistotnych sprawach ...
Chris,
7
Może zamiast poświęcać czas wszystkim, pisząc pytania OT na tablicy, poproś pytającego, aby to zanotował (na wyznaczonej stronie wiki, problem JIRA, gdziekolwiek).
LarsH
14
Myślę, że fizyczny moment poświęcenia chwili na napisanie pytania na tablicy wyraźnie pokazuje pytającemu, że odkładasz ich pytanie (zamiast go ignorować) i pokazuje reszcie publiczności, która zadaje wszystkie pytania, a tym samym opóźnia postęp.
JBRWilkinson
1
@LarsH - dokładnie. Po włożeniu białej tablicy rozmowa zostaje zatrzymana. Jeśli pojawi się ponownie, instruktor po prostu wskazuje pytanie i mówi: „Obiecuję, że do niego wrócimy”.
mattnz
21

Ustaw poprawnie oczekiwania i bądź uczciwy, otwarty i otwarty.

Upewnij się, że Twoje cele są otwarte i przejrzyste.

Rozpocznij dyskusje od widoku wysokiego poziomu promowanego przez andy256 (+1), ale upewnij się również, że podałeś swoje cele, np.

„... gdy patrzymy na ten problem, upewnijmy się, że nie skupiamy się na x, y i z. Upewnijmy się również, że nie patrzymy na szczegóły implementacji, takie jak a, b, c lub szczegóły trywialne takie jak j, k, l. Wiem, że w kodzie musi być wiele szczegółów i szczegółów, które można rozwiązać, ulepszyć lub uczynić bardziej standardowymi, ale najpierw spróbujmy sprawdzić, co naprawdę osiąga na wyższym poziomie „

Michael Durrant
źródło
+1 za pierwsze 2 zdania. Jednak mówienie ludziom, aby nie myśleli o czymś, nie jest dobrym sposobem na nakłonienie ich, aby o tym nie myśleli. „Cokolwiek robisz, nie myśl o różowych jednorożcach”. Zanim wspomniałem o różowych jednorożcach, myślałeś o nich? Prawdopodobnie nie. Gdybym zamiast tego powiedział: „Nie rozpraszajmy się wyobrażonymi zwierzętami i skupiajmy się na zwierzętach australijskich”, to koale i kangury mogły przyszło ci do głowy, ale prawdopodobnie nie różowe jednorożce.
Michael Shaw,
Słuszna uwaga. Jednak nie chodzi o to, aby ludzie przestali myśleć (i nie powiedziano), ale aby nie wdawali się w przedłużające się rozmowy, w których spotykają się zabójcy i frajerzy morale. Ludzie zawsze będą myśleć o wielu niewypowiedzianych rzeczach. W porządku. W profesjonalnej sytuacji biznesowej mówi się niektóre rzeczy, a wielu nie.
Michael Durrant
17

Jak zatem edukować innych programistów na tyle, aby przestali się skupiać na trywialnościach i mogli znacząco przyczynić się do projektowania?

Po pierwsze, nie myśl o ich obawach jako o „trywialnościach” lub „rowerach”. To są osądzające słowa i obraźliwe. Ich obawy są aktualne. Nie są w tej chwili ważne.

Kluczem do każdego dobrego spotkania jest, aby każdy wiedział:

  • dlaczego masz spotkanie i
  • co masz nadzieję z tego wyciągnąć
  • jak długo to powinno trwać

Podaj te rzeczy z góry, wyraźnie i wyjaśnij cele.

Na przykład możesz powiedzieć: „To spotkanie ma na celu zapoznanie cię z pakietem Foo i jego wykorzystaniem w naszym module raportowania. Moim celem jest, abyś zrozumiał wystarczająco dużo o Foo, abyś mógł pracować nad projektem Bar Reports w przyszłym tygodniu. Chciałbym, żebyśmy skończyli w ciągu następnych 90 minut. ”

Następnie, gdy pojawia się temat, może wyglądać tak:

Nowa osoba: „Dlaczego FooWidget jest implementowany jako wzór fasady?”

Ty: „Myślę, że to dlatego, że (krótkie wyjaśnienie decyzji projektowej)” lub „Nie wiem”.

Jeśli odpowiedź wystarczy, to świetnie. Jeśli nie, i kontynuuje:

NP: „Nie sądzisz, że lepiej byłoby to zrobić jako singleton?”

Ty: „Naprawdę o tym nie myślałem, ale chciałbym kontynuować wyjaśnianie, jak działa FooWidget”.

NP: „Ale jeśli zrobimy to jako singleton, możemy…”

Ty: „Przepraszam, że przeszkadzam, ale muszę skupić się na tym, jak działa FooWidget. To spotkanie jest zaplanowane tylko do godziny 11:00 i mamy wiele do przejścia. Dyskusja na temat projektu będzie musiała poczekać jeszcze raz . ”

Po przejściu tego raz lub dwa razy możesz skrócić to do „To jest poza zakresem tego spotkania”.

Pamiętaj, że jesteś nie mówiąc: „To głupi się martwić o” lub „To nie ma znaczenia” czy „Shut up” lub „Jesteś zbyt nowy mieć wejście.” Po prostu koncentrujesz się na tym, co należy zrobić i na zaangażowanym czasie.

Andy Lester
źródło
1
Łatwo jest stwierdzić, kiedy prezenter naprawdę nie jest zainteresowany opiniami. Te spotkania przebiegają szybko. Nikogo to nie obchodzi.
chux,
4

W niektórych organizacjach nigdy nie będziesz w stanie tego osiągnąć. Wiele organizacji ceni polityczną walkę i wspinanie się po drabinie bardziej niż zdolności intelektualne, pracowitość i lojalność. A dlaczego by nie mieli. Wspinaczka po drabinie stawia ludzi na pozycjach władzy, pozwala im poprawić swoje życie osobiste dzięki bardziej dyskrecjonalnym dochodom i naprawdę nigdy nie staje się przestarzała.

Porównaj to sprzeczanie się z władzą z faktycznym rozwiązywaniem problemów, abstrakcyjnym myśleniem i podejmowaniem decyzji w trudnych kwestiach, które mogą być odpowiedzialne za konsekwencje później, a wielu pracowników jest ciężko po stronie próbowania jazdy na rowerze jak najwięcej.

Jedyna rada, którą sugeruję, to wyjaśnienie, w miarę możliwości, w kontekście organizacji, że osobisty los tych uczestników zależy od ich zrozumienia, wkładu i wysiłku w kierunku rzeczywistego problemu, który próbujesz rozwiązać. Jeśli taka jest architektura korporacyjna, wyrażona w tej bazie-błędów i to wszystko zawodzi, to tyle. Wyjaśnij im, że muszą wnieść znaczący znaczący wkład w tej sprawie . Żadna inna przypadkowość, która okazuje się być wkurzoną przez kogoś w starszym wieku lub kogoś innego i zdobędzie dla nich niezłe punkty za porozumienie ze wspomnianym kimś starszym.

Jest to często trudne, ponieważ starszy ktoś zwykle nie rozumie technologii, nie jest zainteresowany i niestety kontroluje surowce: czas pracownika; wynajem i ogień, polityka sal konferencyjnych, promocje itp. itd. poważnie, i tak dalej.

Andyz Smith
źródło
3

To, co nazywasz bikeshedding, nazwałbym przekształceniem czyjegoś przepływu myśli w nasz. Omawiając nazwy, wzorce, rozumieją kod na własnych warunkach i nie ma sposobu, aby temu zapobiec, jest to potrzebne.

Poza tym nie ma potrzeby przechodzenia do bardzo szczegółowego przewodnika po całej bazie kodu, ponieważ szczegóły zostaną zapomniane na długo zanim zaczną nad tym pracować.

Opierając się na tych dwóch pomysłach, sugerowałbym rozbicie bazy kodu na jednostki, a uczniów na dwie osoby. Dla każdej jednostki kodu każda grupa będzie miała, powiedzmy, 25 minut ( oczywiście zależy od LOC ), aby móc przejść 5-10 minutowy kod dla innych. Trzy minuty pytań i powtórz z następną jednostką. Wyjaśnij to słowo kluczowe; muszą upewnić się, że inni to wszystko zrozumieli.

Będziesz tam tylko po to, aby wymusić czas, nie ma tematów i kontrola jednostki została wystarczająco zrozumiana. Będą aktorami ich nauki i będą bardziej skupieni na wyjaśnianiu innym niż na rowerach.

Możesz wymagać od nich ręcznie narysowanego schematu jednostki kodowej, który zostanie skopiowany i zachowany w dokumentach udostępnionych przez zespół, aby mieli w przyszłości coś namacalnego. Dobrze jest też zakotwiczyć wspomnienia.

Przepraszam, jeśli już próbowałeś ...

feydaykyn
źródło
1

Czy próbowałeś robić lekcje wstępne, nad którymi ludzie osobno się przyglądają?

Twórz krótkie filmy lub prezentacje, które wyjaśniają treść, sposób działania kodu, lub w zasadzie wszystko, czego chcesz ich nauczyć w formacie, w którym muszą na nie spojrzeć i dowiedzieć się, jakich informacji chcesz nauczyć.

Następnie używasz sesji zespołowych do omawiania problemów związanych z treścią. Musisz wyraźnie określić, że sesje zespołu służą wyłącznie do omawiania i rozwiązywania problemów związanych z treścią.

Jeśli zapewnisz lekcje ludziom indywidualnie, możesz być w stanie uniknąć tego innego problemu społecznego, w którym jedna sprawa może stać się głosem grupy jako zbiorowości i odwrócić uwagę od faktycznego celu lekcji.

Joe
źródło
13
Nieee ......., nie wideo ..... "Death By Powerpoint" został zastąpiony przez jeszcze gorszy los ......, Chociaż przyniesie pożądany efekt zatrzymania pytań - zagrozić im więcej filmów, które wyjaśniają, co można odczytać w 30 minut i zrozumieć w kilka sekund ...
Mattnz
6
+1 mattnz Problemy z komunikacją raczej nie zostaną poprawione dzięki interakcjom jednokierunkowym.
Michael Durrant
1
Nie chcę być zatrzymany, nawet jeśli jestem na filmie! Jaki format / kodek wideo wyłącza pauzę? :) :) :)
Kaz
1

Najpierw naucz ich projektowania bazy kodu, poprowadź ich wokół architektury, ZANIM zaczniesz szukać konkretnych przykładów. W ten sposób mogą zobaczyć, jak przykłady kodu, na które patrzysz, pasują do większego obrazu. Pomyśl o strukturze programu treningowego. I uwzględnij motywację biznesową projektu.

Spędziłem kilka lat szkoląc innych programistów i nigdy nie wdałem się w kod, zanim pokazałem im, jak system się ze sobą łączy. Potem, kiedy kazałem im robić ćwiczenia kodu w ramach, pytania były uporządkowane i tematyczne.

Bobble
źródło