Когда вы не оказываете помощь менее опытным программистам? [закрыто]

Считаете ли вы, что это хорошая идея, когда младший программист нуждается в помощи, чтобы всегда вмешиваться и пытаться обучить их? Или они проигнорируют все советы по «обучению рыбам», которые вы им дадите, и сосредоточатся только на «рыбе», которую вы только что принесли им? Вы позволяете им всегда разбираться с вещами самостоятельно, зная, что ошибки - лучший способ учиться? Или вы боитесь, что они так сгорят и расстроятся, что потеряют желание набрать скорость?

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

На одной из своих работ я одновременно учился и преподавал (потому что я, конечно, не все знаю, но знаю больше, чем некоторые)

Ни в коем случае не кладите руки на клавиатуру. Это расстраивает как вас, так и человека, которого вы обучаете. Даже если вы дадите им пошаговые инструкции, когда вы кладете руки на клавиатуру, это равносильно тому, чтобы дать им кусок кода и сказать «это исправляет».

Из того, что я узнал:

• Не вводите код для них
• Попытайтесь преподавать на их уровне (если они понимают синтаксис, не объясните им это. Это просто утомит их; вместо этого научите используемые классы / функции)
• Не игнорируйте их и не говорите «разберитесь сами». В конечном итоге они придут к вам позже, за исключением трех строк кода, с которыми у них возникли проблемы, - теперь 50 строк разбиты на 8 файлов, пытаясь обойти эту проблему.
• Научите их учиться самостоятельно. Один из лучших способов - сказать им использовать stackoverflow. Я иногда даже зная ответ, если меня спросят. Я бы сказал: «Хорошо, я собираюсь задать этот вопрос по stackoverflow». и я бы дал им ссылку на вопрос. Сделайте перерыв на кофе и посмотрите на другой код. Когда они вернулись с вопросом «как мне решить эту проблему», просто скажите им, чтобы они посмотрели свой вопрос на SO (используя URL, который вы им дали). Я обнаружил, что массы обычно лучше учителя, чем я.
• Когда они копируют и вставляют код из Интернета и спрашивают, почему он не работает, попросите их объяснить, что делает каждая строка. Если они не могут, попросите их изучить используемые функции / классы. При необходимости предоставьте объяснения для класса и функций
• Проводите проверки кода, чтобы убедиться, что они решают проблему, а не просто обойти ее, чтобы она появилась позже.
• Будь милым Когда кто-то только начинает в вашей кодовой базе без документации, не говорите ему читать исходный код. Дайте краткий обзор высокого уровня рассматриваемой функции. Или, что еще лучше, начните писать документацию :)
• Быть скромным. Не говорите о проблеме. Если вы этого не знаете, скажите, что нет, и помогите им разобраться. Много раз, просто зная домен достаточно, чтобы знать, какие ключевые слова для поиска достаточно помочь вам дать им.

Сократовский метод, т. Е. Задавать им вопросы, которые заставляют их думать в положительном направлении

[это полезно, даже если вы не знаете, в чем проблема, а тем более решение)

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

Вы абсолютно правы насчет "сгоревшего и расстроенного". Они будут именно такими, если вы будете микроуправлять или придираться. Наконец, это очень помогает установить дружеские рабочие отношения с вашими коллегами. Время, потраченное на завоевание доверия и взаимного уважения, окупится в 10 раз больше.

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

Что касается того, чтобы брать «рыбу» вместо «учения ловить рыбу», то лучший способ сделать это - не решать проблемы людей за них . Дайте им идеи и дайте им поработать с этим. Если они бегут с этим и терпят неудачу, то помогите им больше. Если им это удастся, даже лучше.

Если они хороший программист, они должны найти способ сделать это самостоятельно. Теперь в ситуации, когда почти невозможно найти информацию или решение данной проблемы, протянуть руку помощи, по-видимому, в пределах разумного, пока вы удерживаете его в пределах разумного. Не кормите ложкой их ответ.

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

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

Я буду наставником, но я уйду, если они хотят, чтобы я сделал их работу за них. Обычно просто несколько советов о том, как решить проблему или переписать описание задачи, может иметь большое значение. Даже просто сказать им слова, которые они должны использовать в Google, может быть достаточно помощи. Максимум 2 минуты

Я недавно начал использовать технику Pomodoro . В результате, если я не могу ответить на вопрос, не нарушив моих мыслей о текущей задаче, я начал спрашивать, могу ли я отложить ответ до конца pomodoro, в среднем около 15-минутной задержки. Интересный побочный эффект этого, который я обнаружил, состоит в том, что, когда я захожу к их столу, чтобы ответить на вопрос, они часто уже решили его самостоятельно. Если нет, то в этот момент я гораздо более готов уделить им все свое внимание.

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

Если что-то легко найти, научите их, как это сделать. С другой стороны, если это что-то, что вы можете узнать только из опыта, например, какие файлы нужно исследовать на предмет определенных признаков ошибок, я не вижу абсолютно ничего плохого в том, чтобы просто дать необъяснимый ответ.

И наоборот, более субъективные вещи, такие как руководство по архитектуре, всегда должны сопровождаться обоснованием этого. С одной стороны, младший разработчик задумался над своей конкретной задачей гораздо глубже, чем вы. Обсудив это, вы не сделаете поспешных выводов. С другой стороны, это не позволяет им слепо применять правила к будущим ситуациям, в которых они могут не применяться.

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

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

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

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

Если мы имеем дело с критической проблемой поддержки производства, где важно время отклика, то я бы на самом деле предоставил много помощи, а также много объяснений, чтобы они могли изучить проблему.

Если срок менее чувствителен, то сложность становится драйвером. Конечно, вы можете очень помочь новичкам, просто назначив соответствующие задания на уровне навыков, но если это что-то, что может быть решено с помощью исследований, то я согласен с другими постерами, что направлять их без точного ответа - отличный подход ,

Если они задают вопросы, на которые легко ответить, посмотрев в другое место, тогда я заставлю их заняться своей работой. Вдобавок к этому, если есть процесс или решение, которые довольно замкнуты, и нет смысла делать их рабами для этого, то позор вам, если у вас нет удобной вики для их проверки.

Когда дело доходит до передачи знаний о предметной области, которые являются обычными для бизнеса, тогда я не теряю слов. Лекция прямо как можно скорее. Новичкам нужно это, чтобы помочь со всем, что придет позже. Нет такого понятия, как слишком быстро или слишком легко обучаться бизнесу. Однажды у меня был начальник, который целый час играл разные трюки, пытаясь привести меня к ответу. Я был новичком, еще ничего не знал о приложении или бизнесе, и я имел дело с проблемой поддержки производства. Я хотел закричать: «Почему вы & # @ $! Играете в игры @ @ (* $%!? Пользователи, пытающиеся получить счета, ждут ответа!»

Я думаю, что первое, что вы должны спросить их, прежде чем помочь им, это вы исследовали об этом? если да, спросите их, что они узнали, и направьте их в правильном направлении. Расследование этого вопроса часто недооценивается, но является одним из лучших методов, которые я усвоил, поиск информации о том, что вам нужно, дает вам возможность учиться самостоятельно, а также дает понять, что они должны попробовать в первую очередь.

Если проблема более сложная, постарайтесь не говорить им, что делать, а поделиться некоторыми идеями, спросите их, как, по их мнению, они могут подойти к проблеме.

Если они не имеют ни малейшего представления, попробуйте разбить его до базового уровня, на котором вы не отдает все подробности, а описываете достаточно подробное решение, чтобы попробовать их, для этого есть очень полезные инструменты, такие как алгоритмы или блок-схемы .

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

Я избегаю помогать с такими простыми вещами, как синтаксис, который они должны знать, или если они не знают, что они смогут понять сами. Если это что-то более сложное, я не против объяснить один раз.

Когда речь идет о таких вещах, как объяснение процесса или стандарты кодирования нашей организации / проектов и т. Д., Я использую правило трех ударов. Я действительно думаю, что человек хромает, если ему нужно объяснить это три раза. На самом деле это тоже один из критериев нашей оценки.

Многое зависит от ученика. Я ожидаю, что они подберут несколько вещей самостоятельно. Если они придумают: «Я столкнулся с этой проблемой, я попробовал методы A, B и C, но я не смог решить проблему», я помогу им. Если они просто придумают «Я сталкиваюсь с этой проблемой» и ничего не сделали, я попрошу их вернуться к книгам и найти решение.

Как сам начинающий программист (около 9 месяцев на моей нынешней работе, использующей в основном Perl и SQL, и а) без знания Perl и б) несколько месяцев работы с SQL перед этой работой), когда я задаю вопросы по программированию, я стараюсь показать то, что я сделал до сих пор, или в случае чего-то не работающего (и затрудняющего отладку), где я думаю, что ошибка может лежать. По возможности я старался научиться ловить рыбу.

Я перестаю помогать в следующих обстоятельствах:

• Если я использую для канала Google / Stack
• Если я предоставил адекватную документацию и комментарии, и они сокращают этап RTFM
• Если они грязные, без комментариев: «Я взломаю это сейчас и вернусь к этому позже» & & £>! $

Если я не предоставил адекватные документы или они работают с инструментом / классом, который я создал, то я обязан помочь им