Коли ви не надаєте допомоги менш досвідченим програмістам? [зачинено]

Ви вважаєте, що це гарна ідея, коли молодшому програмісту потрібна допомога, щоб завжди стрибати та намагатися їх виховувати? Або вони будуть ігнорувати всі поради "вчити рибалити", які ви їм даєте, і просто зосередиться на "рибі", яку ви їм щойно принесли? Чи дозволяєте ви їм завжди розбирати речі самостійно, знаючи, що помилки - найкращий спосіб вчитися? Або ти боїшся, що вони настільки згорять і розчаруються, що втратять бажання прискорити швидкість?

Коли ви вибираєте, коли допомогти комусь молодшому, ніж ви, а коли відстояти і дозволити їм вчитися на своїх помилках?

На одній із моїх робіт я вчився і викладав (бо, звичайно, не знаю всього, але я знаю більше, ніж деякі)

Чи не за всяку ціну скласти руки на клавіатурі. Це засмучує і вас, і людину, якої ви навчаєте. Навіть якщо ви даєте їм покрокові вказівки, коли ви кладете руки на клавіатуру, це рівнозначно тому, щоб дати їм фрагмент коду і сказати «це виправляє».

У чому я дізнався:

• Не вводите код для них
• Спробуйте викладати на їхньому рівні (якщо вони розуміють синтаксис, не пояснюйте їм це. Це просто набридне; замість цього навчіть класи / функції, що використовуються)
• Не ігноруйте їх і не кажіть "зрозумійте самі". У кінцевому підсумку ви їх отримаєте пізніше, за винятком 3-х рядків коду, з якими виникли проблеми, зараз 50 рядків, розповсюджених на 8 файлів, які намагаються вирішити проблему.
• Навчіть їх вчитися самостійно. Один з найкращих способів - сказати їм використовувати stackoverflow. Я іноді, навіть знаючи відповідь, якби вони запитали мене. Я б сказав "добре, я збираюся задати це питання на stackoverflow". і я б дав їм посилання на запитання. Зробіть перерву на каву та подивіться на якийсь інший код. Коли вони повернулися із запитанням "так як я виправити цю проблему", просто скажіть їм, щоб вони переглянули своє запитання щодо SO (використовуючи вказану вами URL-адресу). Я виявив, що маси, як правило, кращий вчитель, ніж я.
• Коли вони копіюють і вставляють код з Інтернету і запитують, чому він не працює, попросіть їх пояснити, що робить кожен рядок. Якщо вони не можуть, то скажіть їм дослідити використовувані функції / класи. За потреби надайте пояснення для класу та функцій
• Проведіть огляд коду, щоб переконатися, що вони вирішують проблему, а не просто обробляйте її, щоб вона з’явилася пізніше.
• Будь вихованим. Коли хтось тільки починає працювати у вашій кодовій базі без документації, не просто повідомте їм читати вихідний код. Дайте узагальнений огляд високого рівня відповідної функції. Або, ще краще, почніть писати документацію :)
• Будь покірним. Не варто BS щодо проблеми. Якщо ви цього не знаєте, скажіть, що ви цього не зробите, і допоможіть їм знайти. Багато разів достатньо допомогти вам знати домен, щоб знати, які ключові слова шукати.

Сократичний метод, тобто задайте їм питання, які спонукають їх мислити в позитивному напрямку

[це корисно навіть тоді, коли ви не знаєте, в чому проблема, тим більше рішення]

Я навчився допомагати їм архітектором і зупинятися на цьому. Підберіть правильні інструменти, складіть загальну конструкцію до складної проблеми або двох і відпустіть її. Якщо вони повернуться і попросять поради, дайте їм їх невеликими шматками. Якщо вони цього не роблять, нехай будуть.

Ви абсолютно праві щодо "спалених і розчарованих". Це буде саме те, якщо ви будете мікро-керувати або вибирати ніт. Нарешті, це дуже допомагає налагодити дружні робочі стосунки зі своїми колегами. Час, витрачений на завоювання довіри та взаємної поваги, окупить себе в 10 разів.

Я допомагаю їм, коли мені справді потрібні речі, щоб швидко закінчити, коли зрозуміло, що вони потрапили в цегляну стіну, і коли явно нерозумно очікувати, що вони зрозуміють це без сторонньої допомоги. Якщо, однак, вони не доклали часу до чогось, то краще спершу спробувати це.

Що стосується того, щоб брати "рибу" замість "вчити ловити рибу", найкращий спосіб зробити це - не вирішувати для них проблем людей . Дайте їм ідеї і нехай вони з нею працюють. Якщо вони бігають з цим і не вдається, то допоможіть їм більше. Якщо їм це вдасться, ще краще.

Якщо вони хороші програмісти, вони повинні знайти спосіб зробити це своїми силами. Зараз у ситуації, коли майже неможливо знайти інформацію чи рішення певної проблеми, надаючи руку допомоги, здавалося б, в межах розуму, доки ви не зберігаєте її в межах розуму. Не ложкою подавай їм відповідь.

Можливо, як приклад мені 18 років, і я вже багато років навчаюсь самостійно, і написав кілька шалених речей, включаючи власного упорядника, і я самоучка. Я шукаю допомоги лише в тих речах, на яких я дійсно застряг (як, наприклад, я шукав і експериментував принаймні день, але безрезультатно). Я також хотів би надати зустрічний приклад: У класі програмування мені одного разу студент попросив мене налагодити код, який він навіть не склав!

По суті, хороший програміст, навіть молодший, повинен вміти експериментувати та досліджувати рішення більшості проблем.

Я буду наставником, але я відходжу, якщо вони хочу, щоб я зробив свою роботу за них. Зазвичай лише деякі поради щодо вирішення проблеми або переформулювання опису завдання можуть пройти довгий шлях. Навіть просто сказати їм слова, які вони повинні використовувати в Google, може бути достатньою допомогою. 2 хвилини максимум.

Нещодавно я почав використовувати техніку помодоро . Як результат, якщо я не можу відповісти на запитання, не порушивши свій потяг думок щодо мого поточного завдання, я почав запитувати, чи можу я відкласти відповідь до кінця Помодоро, в середньому близько 15 хвилин затримки. Цікавий побічний ефект цього я виявив, коли я заходжу за їхній стіл, щоб відповісти на запитання, вони часто вже вирішували це самостійно. Якщо вони цього не зробили, я тоді набагато більше готовий приділити їм всю свою увагу.

Це не школа. Це не обман, якщо швидко навести факт, який вони з часом зможуть знайти самостійно. Навпаки, має сенс в бізнесі економити час, і, на моєму досвіді, навички відточуються дуже мало шляхом спроб і помилок порівняно з наставником, що дає вам часті дрібні поштовхи в потрібному напрямку. Я вважаю за краще, щоб вони навчилися 10 правильних способів робити речі з моєю допомогою, ніж 9 неправильних способів і один правильний самостійно.

Якщо щось можна легко подивитися, навчіть їх робити це. З іншого боку, якщо це щось, що ви можете знати лише з досвіду, як, наприклад, які файли досліджувати на наявність певних симптомів помилок, я не бачу абсолютно нічого поганого в тому, щоб просто дати незрозумілу відповідь.

І навпаки, більш суб'єктивні речі, такі як настанови архітектури, завжди повинні супроводжуватися міркуваннями, що стоять за цим. По-перше, молодший розробник продумав набагато глибше про їх конкретне завдання, ніж ви. Якщо говорити про це, то ви не переходите до висновків. З іншого боку, це заважає їм сліпо застосовувати правила до майбутніх ситуацій, коли вони можуть не застосовуватися.

Я можу придумати лише один випадок, коли я відмовився продовжувати допомагати колезі, і це витратив пару годин на пояснення чогось кілька разів і переглянув кілька прикладів, після чого вона буквально ще не знала наступного твердження, щоб набрати деякі дуже провідні підказки. У цей момент у неї було мало надії зберегти свою роботу без серйозного переосмислення основ, і, безумовно, вона тривала лише пару місяців.

Я перестаю їм допомагати, коли вони повертаються з тим же запитанням втретє.

Я кажу їм, що буду радий допомогти їм, але тільки якщо вони допоможуть собі першими. Звідти вони або йдуть шукати інший ставок, щоб порибалити на безкоштовну їжу, і в такому випадку зазвичай їх звільняють на короткий час. Або вони працюють над цим і вдаряють у джек-пот, коли повертаються за більше…, це навчитися більше речі, а не більше того ж!

Я думаю, що контекст має значення.

Якщо ми маємо справу з критичною проблемою підтримки виробництва, де важливий час відповіді, то я б фактично надав багато допомоги, а також багато пояснень, щоб вони могли вивчити проблему.

Якщо граничний термін менш чутливий, то складність стає водієм. Звичайно, ви можете багато чого допомогти новачкам, призначивши відповідні завдання на рівні навичок, але якщо це щось, що можна вирішити за допомогою досліджень, то я погоджуюся з іншими плакатами, які керують ними, не даючи точної відповіді, - це чудовий підхід .

Якщо вони задають питання, на які легко відповісти, дивлячись в іншому місці, то я спрямовую їх на виконання своєї роботи. Згідно з цими лініями, якщо є процес чи рішення, які є досить грізними і мало значення для того, щоб зробити їх рабами для цього, то соромтесь за вас, якщо у вас немає зручної вікі для перевірки.

Якщо мова йде про передачу знань про домен, які є звичними для бізнесу, то я не заграю слова. Викладайте його якнайшвидше. Новачкам потрібно це допомогти у всьому, що з’явиться пізніше. Не існує такої речі, як занадто швидко або занадто легко навчатись бізнесу. Колись у мене був бос, який протягом години грав усілякі хитрощі, намагаючись привести мене до відповіді. Я був абсолютно новим, ще нічого не знав про додаток або бізнес, і я мав справу з проблемою підтримки виробництва. Мені хотілося кричати: "Чому ви граєте в # @ & (* $%! Ігри? Користувачі, які намагаються отримати рахунки-фактури, чекають відповіді!"

Я думаю, що перше, що ти маєш запитати у них, перш ніж допомогти їм, це ти розслідував це? якщо так, запитайте у них, що вони з’ясували, і вкажіть їх у правильному напрямку. Дослідження його часто недооцінюється, але це одна з найкращих практик, яких я засвоїв, пошук інформації про те, що вам потрібно, дає вам змогу вчитися самостійно, а також стане зрозумілим, що їм потрібно спробувати спочатку.

Якщо проблема є більш складною, спробуйте не говорити їм, що робити, але поділіться деякими ідеями, запитайте їх, як вони думають, що вони могли підійти до проблеми.

Якщо у них немає поняття, то спробуйте розбити його на дуже базовий рівень, коли ви не роздаєте всі деталі, але опишіть рішення достатньо, щоб вони спробували, для цього є дуже корисні інструменти, такі як алгоритми або блок-схеми .

На закінчення спробуйте керуватись ними, не втручаючись у процес навчання, завжди допомагаючи їм змусити їх залежати від вас для кожного завдання, яке потім буде призначено, це займе ваш час і є непродуктивним.

Я уникаю допомоги у простих речах, таких як синтаксис, який вони повинні знати, або якщо вони не знають, вони повинні мати можливість зрозуміти самостійно. Якщо це щось складніше, я не проти пояснити один раз.

Якщо мова йде про такі речі, як пояснення процесу чи стандарти кодування нашої організації / проектів тощо, я використовую правило трьох ударів. Я дійсно думаю, що людина кульгає, якщо йому доведеться тричі пояснювати речі. Насправді це також є одним із критеріїв нашої оцінки.

Багато що залежало від того, хто навчається. Я очікую, що вони підберуть кілька речей самостійно. Якщо вони придумують: "Я зіткнувся з цією проблемою, я спробував методи A, B і C, але не міг вирішити проблему", я їм допоможу. Якщо вони просто придумають "Я зіткнувся з цією проблемою" і не зробили нічого, я попрошу їх повернутися до книг і шукати рішення.

Як сам програміст-початківець (близько 9 місяців в моїй теперішній роботі використовую здебільшого Perl і SQL і з a) не знаючи Perl і b) кілька місяців майстерності з SQL перед цим завданням), коли я задаю питання програмування, я намагаюся показати що я робив до цього часу, або у випадку, якщо щось не працює (і це важко налагодити), де я думаю, що помилка може лежати. Коли це було можливо, я прагну навчитися ловити рибу.

Я перестаю допомагати в таких випадках:

• Якщо мене використовують для каналу Google / Stack
• Якщо я надав належну документацію та коментарі, вони скорочують етап RTFM
• Якщо вони брудні, без коментарів, "я зламу це зараз і повернусь до нього пізніше" & & £>! $

Якщо я не надав належних документів або вони працюють з інструментом / класом, яким я є автор, я відповідаю за них.