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

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

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

Однако они редко, если вообще не согласны или спрашивают, почему. И в последнее время я замечаю более явные признаки того, что они слепо соглашаются с моими высказываниями, а не формируют собственное мнение.

Мне нужна команда, которая может научиться действовать правильно самостоятельно, а не просто следовать инструкциям. Как можно исправить младшего разработчика, но все же побудить его думать за себя?

Изменить: Вот пример одного из этих очевидных признаков того, что они не формируют свое собственное мнение:

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

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

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

Краткий ответ:

Вовлеките их (поместите загадку в их сознание), уполномочивайте их (доверяйте их ответам).

Это вопрос, который движет нами! - Матрица.

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

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

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

В целом, очень маленькие дети склонны быть более искусными в технических вопросах (например, какой шаблон проектирования работает лучше!), А не в процессах , но со временем, когда вы их тренируете, это работает.

Однако они редко, если вообще не согласны или спрашивают, почему. И в последнее время я замечаю более явные признаки того, что они слепо соглашаются с моими высказываниями, а не формируют собственное мнение.

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

Лучшее, что я узнал от одного из моих прошлых боссов: он попросит членов команды сначала обсудить (они чувствуют себя здесь довольно равными), и, надеюсь, после того, как все аргументы будут исчерпаны, он войдет в комнату только с одним вопросом - «Что было точки разногласия? " - Дело в том, что людям всегда нравится участвовать в дебатах и ​​дискуссиях, но если их (действительные) пункты не будут приняты к действию в следующий раз, они чувствуют, что участвовать в обсуждении не стоит.

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

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

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

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

Поскольку у вас есть несколько начинающих разработчиков, делайте проверки кода как группу, а не 1 1 1.

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

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

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

Когда я впервые начал работать программистом, я сделал то же самое, что вы описали: когда мне рассказывали о том, что я мог делать, я всегда соглашался. Это было главным образом потому, что у меня не было достаточно опыта, чтобы сказать иначе.

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

Хороший способ облегчить индивидуальное мышление состоит в том, чтобы они заглядывали в сайты программирования, такие как Stack Overflow или Programmers SE. Я знаю, что это помогло мне узнать о различных техниках, которые были там, и позволило мне обсуждать с высокопоставленными членами команды, а не слепо соглашаться с ними.

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

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

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

Конечно, вы не всегда можете прямо попросить их повторить то, что вы только что сказали, поэтому вам нужно скорректировать свою стратегию. Например, вот как я бы перефразировал ваше последующее заявление от ОП как «пробный» вопрос:

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

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

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

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

Когда мне пришлось иметь дело с этим, я сказал (честно) такие вещи, как:

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

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

Ответственность - это то, что может им помочь.

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

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

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

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

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

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

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