Kiedy nie udzielasz pomocy mniej doświadczonym programistom? [Zamknięte]

Czy uważasz, że to dobry pomysł, gdy młodszy programista potrzebuje pomocy, aby zawsze wskoczyć i spróbować je edukować? Czy też zignorują wszystkie udzielone im porady dotyczące „nauki łowienia ryb” i skupią się na „rybach”, które im przyniosłeś? Czy pozwalasz im na samodzielne rozwiązywanie problemów, wiedząc, że błędy to najlepszy sposób na naukę? A może boisz się, że zostaną tak spaleni i sfrustrowani, że stracą chęć przyspieszenia?

Kiedy zdecydujesz, kiedy pomóc komuś bardziej młodszemu niż ty, a kiedy się odsunąć i pozwolić mu nauczyć się na swoich błędach?

W jednym z moich zawodów uczyłem się i uczyłem (bo oczywiście nie wiem wszystkiego, ale wiem więcej niż niektóre)

Nie za wszelką cenę położyć swoje ręce na klawiaturze. Jest to frustrujące zarówno dla ciebie, jak i osoby, której uczysz. Nawet jeśli dajesz im instrukcje krok po kroku, kiedy położysz dłonie na klawiaturze, jest to odpowiednik podania im kodu i powiedzenia „to naprawia”.

W tym, czego się nauczyłem:

• Nie wpisuj dla nich kodu
• Spróbuj uczyć na ich poziomie (jeśli rozumieją składnię, nie wyjaśniaj im tego. To ich po prostu znudzi; zamiast tego naucz używanych klas / funkcji)
• Nie ignoruj ​​ich ani nie mów „wymyśl to sam”. Skończysz z tym, że przyjdą do ciebie później, z wyjątkiem 3 linii kodu, z którymi mieli problemy, jest teraz 50 linii rozłożonych na 8 plików, próbujących obejść problem.
• Naucz je uczyć się na własną rękę. Jednym z najlepszych sposobów jest poinformowanie ich, aby korzystali z stackoverflow. Czasami nawet znając odpowiedź, jeśli mnie o to zapytali. Powiedziałbym „cóż, zadam to pytanie przy przepływie stosów”. i dałbym im link do pytania. Zrób sobie przerwę na kawę i spójrz na inny kod. Kiedy wrócili z pytaniem „jak rozwiązać ten problem”, po prostu powiedz im, aby sprawdzili swoje pytanie na SO (używając adresu URL, który im podałeś). Przekonałem się, że masy są zazwyczaj lepszym nauczycielem niż ja.
• Kiedy kopiują i wklejają kod z Internetu i pytają, dlaczego to nie działa, poproś o wyjaśnienie, co robi każda linia. Jeśli nie mogą, powiedz im, aby zbadali używane funkcje / klasy. W razie potrzeby podaj wyjaśnienia dotyczące klasy i funkcji
• Przeprowadź recenzje kodu, aby upewnić się, że rozwiązują problem, a nie tylko obejść go, aby pojawił się później.
• Bądź miły. Gdy ktoś dopiero zaczyna pracę w Twojej bazie kodu bez dokumentacji, nie mów mu, aby przeczytał kod źródłowy. Podaj podsumowany ogólny przegląd danej funkcji. Albo jeszcze lepiej zacznij pisać dokumentację :)
• Być pokornym. Nie BS o problemie. Jeśli nie wiesz, powiedz, że nie i pomóż im to sprawdzić. Wiele razy sama znajomość domeny wystarczająca do znalezienia słów kluczowych do wyszukania jest wystarczająca, abyś mógł je podać.

Metoda socjokratyczna, tzn. Zadawaj pytania, które skłaniają ich do myślenia w pozytywnym kierunku

[jest to przydatne, nawet jeśli nie wiesz, na czym polega problem, a tym bardziej rozwiązanie]

Nauczyłem się pomagać architektom i tam się zatrzymywać. Wybierz odpowiednie narzędzia, narysuj ogólny projekt złożonego problemu lub dwóch i pozwól im się tym zająć. Jeśli wrócą i poproszą o radę, daj im ją w małych kawałkach. Jeśli nie, niech będą.

Masz całkowitą rację co do „spalonych i sfrustrowanych”. Będą dokładnie takie, jeśli wykonasz mikro-zarządzanie lub nit-pick. Wreszcie bardzo pomaga nawiązać przyjazne relacje robocze ze współpracownikami. Czas poświęcony na zdobycie zaufania i wzajemnego szacunku zwróci się 10-krotnie.

Pomagam im, kiedy naprawdę potrzebuję szybkiego ukończenia rzeczy, gdy jest jasne, że uderzyli w ścianę z cegły, a kiedy nie można oczekiwać, że rozwiążą sprawę bez pomocy. Jeśli jednak nie poświęcają czasu na coś, lepiej najpierw spróbować.

Jeśli chodzi o przyjmowanie „ryb” zamiast „nauczania ryb”, najlepszym sposobem na to jest nie rozwiązywanie za nich problemów ludzi . Daj im pomysły i pozwól im z tym biegać. Jeśli uciekną z tym i nie powiedzie się, pomóż im więcej. Jeśli im się uda, nawet lepiej.

Jeśli są dobrym programistą, powinni znaleźć sposób, aby to zrobić samodzielnie. Teraz w sytuacji, gdy jest to prawie niemożliwe, aby znaleźć informacje lub rozwiązania danego problemu nadając dłoń jest pozornie w granicach rozsądku, tak długo jak Ci utrzymać ją w granicach rozsądku. Nie karm łyżeczką odpowiedzi.

Być może jako przykład mam 18 lat i sam uczę się od lat i napisałem kilka szalonych rzeczy, w tym własny kompilator i jestem samoukiem. Poszukuję pomocy tylko w rzeczach, w których tak naprawdę utknąłem (jak w tym, że szukałem i eksperymentowałem przez co najmniej jeden dzień, ale bezskutecznie). Chciałbym również podać kontrprzykład: na zajęciach z programowania miałem kiedyś ucznia, który poprosił mnie o debugowanie kodu, którego nawet nie skompilował!

Zasadniczo dobry programista, nawet młodszy, powinien być w stanie eksperymentować i badać rozwiązania większości problemów.

Będę mentorem, ale odchodzę, jeśli chcą, żebym dla nich wykonał swoją pracę. Zwykle tylko kilka porad na temat rozwiązania problemu lub przeformułowanie opisu zadania może być bardzo trudne. Nawet samo powiedzenie im słów, których powinni używać w Google, może być wystarczającą pomocą. Maksymalnie 2 minuty.

Ostatnio zacząłem używać techniki pomodoro . W rezultacie, jeśli nie potrafię odpowiedzieć na pytanie, nie przerywając myślenia o bieżącym zadaniu, zacząłem pytać, czy mogę odłożyć odpowiedź do końca pomodoro, średnio o około 15 minut. Ciekawym efektem ubocznym, który odkryłem, jest to, że kiedy wpadam przy ich biurko, aby odpowiedzieć na pytanie, często już rozwiązali to samodzielnie. Jeśli nie, w tym momencie jestem o wiele bardziej przygotowany na poświęcenie im pełnej uwagi.

To nie jest szkoła. To nie oszustwo, jeśli szybko podasz fakt, który w końcu mogą znaleźć na własną rękę. Wręcz przeciwnie, sensowne jest oszczędzanie czasu, a z mojego doświadczenia wynika, że ​​umiejętności są wyostrzone bardzo mało metodą prób i błędów w porównaniu z mentorem, który daje ci częste małe pchnięcia we właściwym kierunku. Wolę, żeby nauczyli się 10 prawidłowych sposobów robienia rzeczy z moją pomocą niż 9 niewłaściwych sposobów i jeden właściwy.

Jeśli coś można łatwo wyszukać, naucz go, jak to zrobić. Z drugiej strony, jeśli jest to coś, co można poznać tylko z doświadczenia, na przykład, które pliki należy zbadać pod kątem pewnych symptomów błędów, nie widzę absolutnie nic złego w udzieleniu niewyjaśnionej odpowiedzi.

I odwrotnie, bardziej subiektywnym rzeczom, takim jak wskazówki dotyczące architektury, zawsze powinno towarzyszyć uzasadnienie. Po pierwsze, młodszy programista myślał o swoim konkretnym zadaniu znacznie głębiej niż ty. Omówienie tego sprawi, że nie dojdziesz do wniosków. Po drugie, powstrzymuje je przed ślepym stosowaniem reguł do przyszłych sytuacji, w których mogą nie mieć zastosowania.

Mogę wymyślić tylko jeden przypadek, w którym wprost odmówiłem dalszej pomocy współpracownikowi, i to po tym, jak spędziłem kilka godzin na wyjaśnianiu czegoś wiele razy i przejrzeniu kilku przykładów, po których dosłownie wciąż nie znała następnej wypowiedzi do pisania kilka bardzo wiodących wskazówek. W tym momencie nie miała nadziei na utrzymanie pracy bez poważnego ponownego poznania podstaw i na pewno przetrwała tylko kilka miesięcy.

Przestaję im pomagać, kiedy po raz trzeci wrócą z tym samym pytaniem.

Mówię im, że chętnie im pomogę, ale tylko wtedy, gdy sami sobie pomogą. Stamtąd albo szukają innego stawu, aby łowić darmowe jedzenie, w którym to przypadku zwykle zostają zwolnieni chwilę później. Albo pracują nad tym i trafiają w dziesiątkę, gdy wracają po więcej ... to więcej rzeczy do nauczenia się niż więcej tego samego!

Myślę, że kontekst ma znaczenie.

Jeśli mamy do czynienia z krytycznym problemem wsparcia produkcji, w którym ważny jest czas reakcji, w rzeczywistości zapewniłbym dużo pomocy wraz z mnóstwem wyjaśnień, aby mogli poznać ten problem.

Jeśli termin jest mniej wrażliwy, wówczas czynnikiem decydującym jest złożoność. Oczywiście możesz bardzo pomóc początkującym, przydzielając odpowiednie zadania na poziomie umiejętności, ale jeśli jest to coś, co można rozwiązać za pomocą badań, zgadzam się z innymi plakatami, że prowadzenie ich bez podania dokładnej odpowiedzi to świetne podejście .

Jeśli zadają pytania, na które można łatwo znaleźć odpowiedź, to kieruję ich do własnej pracy. Wzdłuż tych linii, jeśli istnieje proces lub rozwiązanie, które jest dość rutynowe i ma niewielką wartość w zmuszaniu ich do niewolnictwa, wstydź się, jeśli nie masz pod ręką wiki, aby je sprawdzić.

Jeśli chodzi o przenoszenie wiedzy o domenach, która jest niestandardowa dla firmy, to nie mielę słów. Wykładaj to jak najszybciej. Nowicjusze potrzebują tego, aby pomóc we wszystkim, co nastąpi później. Nie ma czegoś takiego jak zbyt szybkie lub zbyt łatwe wykształcenie firmy. Kiedyś miałem szefa, który grał wszelkiego rodzaju triki przez godzinę, próbując doprowadzić mnie do odpowiedzi. Byłem zupełnie nowy, jeszcze nie wiedziałem nic o aplikacji ani biznesie i miałem do czynienia z problemem wsparcia produkcji. Chciałem krzyczeć: „Dlaczego grasz w gry # @ i (* $%!)? Użytkownicy próbujący uzyskać faktury czekają na odpowiedź!”

Myślę, że pierwszą rzeczą, o którą musisz ich zapytać przed udzieleniem im pomocy, jest zbadanie tego? jeśli tak, zapytaj ich, co odkryli, i skieruj ich we właściwym kierunku. Badanie tego jest często niedoceniane, ale jest jedną z najlepszych praktyk, których się nauczyłem, znalezienie informacji na temat tego, czego potrzebujesz, daje ci siłę do samodzielnego uczenia się, a także wyraźnie wyjaśni, że najpierw muszą spróbować.

Jeśli problem jest bardziej złożony, staraj się nie mówić im, co mają robić, ale dzielić się pomysłami, zapytaj ich, w jaki sposób mogą podejść do problemu.

Jeśli nie mają pojęcia, spróbuj rozbić go na bardzo podstawowy poziom, na którym nie podajesz wszystkich szczegółów, ale wystarczająco opisujesz rozwiązanie, aby spróbować, istnieją bardzo pomocne narzędzia do tego typu algorytmy lub schematy blokowe .

Podsumowując, staraj się prowadzić ich bez ingerowania w proces uczenia się, zawsze pomagając im sprawić , że będą od ciebie zależni od każdego przydzielonego zadania , co zabierze ci czas i przyniesie efekt przeciwny do zamierzonego.

Unikam pomagania w prostych rzeczach, takich jak składnia, które powinni znać, a jeśli nie wiedzą, powinni być w stanie zrozumieć sami. Jeśli jest to coś bardziej złożonego, nie mam nic przeciwko wytłumaczeniu raz.

Jeśli chodzi o takie rzeczy jak wyjaśnienie procesu lub standardy kodowania naszej organizacji / projektów itp., Stosuję zasadę trzech ostrzeżeń. Naprawdę uważam, że człowiek jest ułomny, jeśli trzeba mu trzykrotnie wyjaśnić różne rzeczy. W rzeczywistości jest to również jedno z kryteriów naszej oceny.

Wiele zależy od ucznia. Oczekuję, że sami odbiorą kilka rzeczy. Jeśli wymyślą: „Napotkałem ten problem, wypróbowałem metody A, B i C, ale nie mogłem rozwiązać problemu”, pomogę im. Jeśli po prostu wymyślą „Jestem w obliczu tego problemu” i nic nie zrobiłem, poproszę ich, aby wrócili do książek i szukali rozwiązania.

Jako początkujący programista sam (około 9 miesięcy w mojej obecnej pracy, używając głównie Perla i SQL oraz a) bez znajomości Perla ib) kilka miesięcy majstrowania przy SQL przed tą pracą), zadając pytania programistyczne, próbuję pokazać co zrobiłem do tej pory lub w przypadku czegoś, co nie działa (i jest trudne do debugowania), gdzie, jak sądzę, może leżeć błąd. Gdy to możliwe, starałem się nauczyć, jak łowić ryby.

Przestaję pomagać w następujących okolicznościach:

• Jeśli jestem przyzwyczajony do kierowania Google / Stack
• Jeśli dostarczyłem odpowiednią dokumentację i komentarze, a one skracają etap RTFM
• Jeśli są nieprzyzwoite, nie komentują: „Włamię się teraz i wrócę później” & & £>! $

Jeśli nie dostarczyłem odpowiednich dokumentów lub pracują oni z narzędziem / klasą, którą napisałem, to moim obowiązkiem jest im pomóc