Как помочь борющимся новичкам лучше работать?

Я был единственным разработчиком и де-факто "старшим разработчиком" на своем флагманском продукте моей компании некоторое время (приложение .NET WinForms, но это не связано). Совсем недавно они представили "новичка" разработчика со свежей степенью в области компьютерных наук. Нет опыта управления версиями, модульного тестирования, обслуживания программного обеспечения и т.д.

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

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

  • Спросите, какая часть последней итерации была сложнее. Спросите, какая часть заняла гораздо больше времени, чем он ожидал.
  • Проделайте пару программ программирования. Я уже предлагал это, и он, казалось, был открыт для этой идеи, но каждый раз, когда мы начинали, я склонялся к тому, что он не набирал достаточно быстро. Что-то, над чем я должен работать.
  • Прочитайте код перед проверкой работы. (Мы не на этот раз из-за его отпуска.) В обзоре кода будут выделены следующие элементы.
  • Требовать комментарии ко всем публичным пользователям. (Ни один из его кода не прокомментирован.)
  • Требовать от него удалить все неиспользованные коды. (Беглый обзор показывает, что он этого не делал.)
  • Требовать от него фиксации кода для каждого случая FogBugz, когда он завершает его и/или пересматривает случаи, когда они отличаются от того, что он обнаруживает при кодировании.
  • Требовать, чтобы он ввел исходные оценки в FogBugz и переключил флаг "working on", чтобы держать его в задаче.

В то время как материал для проверки кода является специфическим и техническим, меня больше интересует его способность быть стартером и просить/получить руководство там, где он ему нужен. Я не думаю о требованиях FogBugz (6 и 7) как о жестких правилах, но кажется, что ему нужно следовать им, чтобы держать его в курсе.

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

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

4b9b3361

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

Я бы предложил следующие вещи:

  • Заставьте его прочитать "Код завершен".
    • Рассматривайте его как старшего программиста, но проверяйте каждый шаг, который он делает, пока не увидите хорошие результаты.
    • Не сдавайся, или он не узнает. Пусть он совершает ошибки, но затем заставит его исправить это.
    • Он всегда должен делать оценки. Затем попросите его признать, когда его оценка неверна.
    • Всегда поощряйте его думать. Свежие студенты CS вряд ли думают; они кодируются как роботы.

Дайте ему некоторые основные правила, например: никогда не записывайте один и тот же код дважды, и если вы это сделаете, проверьте свой дизайн и т.д.

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

Через полгода он будет хорошим и готовым! (уйти и искать лучшую оплачиваемую работу:-))

50
ответ дан 30 нояб. '09 в 19:29
источник

Вот несколько советов о том, как это обрабатывается в Японии.

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

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

Затем попросите его сделать базовое кодирование в течение 2-3 недель. Дайте ему сказать 5 действительно маленьких заданий в день в первую неделю. Основной уровень шума. И выполните обзор кода в конце каждого дня.

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

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

Он прошел обряд посвящения (очень важный психологически).

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

Теперь, когда у вас есть счастливый, любознательный и уверенный новый человек, сделайте все, что предлагают все остальные здесь:)

46
ответ дан 01 дек. '09 в 8:45
источник

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

Это определенно не в порядке. Вероятно, это не поможет ему думать, что у него есть место для изучения.

Не делайте много изменений в его работе, пока он уходит. Это заставит его чувствовать себя ужасно. Вместо этого, работайте над рефакторингом с ним, когда он вернется (и, во что бы то ни стало, избежит желания перебирать текст).

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

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

<суб > NB. Я никогда не делал никакого управления, так что это просто описание того, как я хочу, чтобы вы справились с этой ситуацией, если бы я был другим.

35
ответ дан 30 нояб. '09 в 19:27
источник

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

Советов:

  • Не ставьте его в проект, где он является единственным программистом в этом проекте. Поместите его под ведущим разработчиком и назначьте ему небольшие задачи, которые могут быть выполнены за короткий промежуток времени. Ему будет легче оценить что-то, что может занять 16 часов работы, а не то, что может занять 80 часов. Сейчас он, вероятно, боится давать оценки, потому что он не хочет давать вам "неправильный ответ". Он боится, что он скажет вам 32 часа, когда вы ожидали 8 или что-то в этом роде. lol Я всегда боялся этого.

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

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

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

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

  • Наличие у него отзывов о кодах - это хорошо. Может быть, вы с ним поедете, и вы с ним можете просмотреть с ним код elses.

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

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

19
ответ дан 30 нояб. '09 в 21:40
источник

Вы хотите привести его к своим профессиональным стандартам? Отлично. Вам нужно научить его, каковы они. С точки зрения наставничества не оставляйте одновременно все правила. Работайте каждый день каждый день. Со временем он доберется туда или избавится от него.

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

13
ответ дан 30 нояб. '09 в 20:17
источник

Это сложный вопрос, и не будет ни одного "правильного" ответа, но вот несколько комментариев и предложений:

Так что я должен использовать то, что он проверил в хотя я не думаю, что это удовлетворительным?

Определенно нет, ИМХО. Сначала вам нужно сделать обзор. В противном случае, как он может поверить вам, что код не является удовлетворительным, если вы его используете?

Требовать комментарии ко всем публичным члены. (Ни один из его кодов прокомментировал.)

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

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

11
ответ дан 30 нояб. '09 в 19:44
источник

То, что вы делаете, здорово, и вы узнали, что вам нужно улучшить.

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

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

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

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

Относитесь к ним как к другу, которого вы всегда поощряете, и они пройдут долгий путь.

5
ответ дан 30 нояб. '09 в 20:24
источник

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

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

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

5
ответ дан 30 нояб. '09 в 19:43
источник

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

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

3
ответ дан 30 нояб. '09 в 20:33
источник

Почти все, что нужно сказать, было сказано - много хорошего совета.

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

Полные оценки за то, что вы так старались делать правильные вещи.

3
ответ дан 02 дек. '09 в 6:15
источник

Я ценю ваши усилия, чтобы быть хорошим наставником. Вот мои 2 цента. У меня когда-то был Sr.Developer, который использовал оценки, чтобы проверить, используют ли разработчики правильный подход для функции (без временного давления). Вы определенно знаете, что что-то не так, если разработчик оценивает 10 часов за что-то, что можно сделать за 2 часа.

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

3
ответ дан 30 нояб. '09 в 22:09
источник

Отличный вопрос и некоторые отличные ответы!

Еще одно предложение, которое я бы добавил: когда вы занимаетесь парным программированием, не слишком быстро исправляйте его ошибки. Запишите их сами, но пусть он продолжит и посмотрит, сможет ли он решить свои проблемы/проблемы. Разумеется, дайте руку помощи, если она заберет его слишком долго (вам придется решить, как долго это длится), но некоторые из лучших учебных событий исходят из исправления ваших собственных ошибок.

3
ответ дан 30 нояб. '09 в 20:40
источник

Будучи будущим инженером-программистом (и младшим инженером), я могу посочувствовать новичкам.

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

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

3
ответ дан 01 дек. '09 в 23:33
источник

Поздравляем вас с вашим отношением к наставничеству. Простой факт, что вы спрашиваете, делаете ли вы все правильно, и как вы можете сделать это лучше, означает, что вы делаете это правильно!
Я думаю, проблема заключается в том, что вы можете быть в двух ситуациях:
1) ему просто нужно время и руководство, чтобы понять, что такое игра, но доберется там
2) он/она не является игроком в команде, и ему все равно.
Очевидно, что если вы находитесь в ситуации (2), наставничество не поможет. Если это так, ваша лучшая стратегия - ограничить ущерб, который может сделать человек, и попытаться заставить его/ее покинуть команду. Но вы не сделаете этого, не давая человеку шанс, что вы делаете.
Уже было дано много хороших советов. Предполагая, что вы работаете с кем-то, кого вы можете наставником, мои 2 общих совета:
1) помогите человеку понять, что от него ожидается. Дайте человеку небольшие задачи, скажите, что вы будете искать (дублирование кода...), и посмотрите вместе после завершения для них. Будьте обнадеживающими, но придерживайтесь правил: если вы согласились, что нужно сделать одно, а не сделать, не позволяйте этому скользить, это неуважение к команде. Не исправляйте код, отправляйте код для исправления, если что-то не было сделано по согласованию. Это поможет ему/ей выйти на правильный путь - и если неоднократно повторяются те же самые проблемы, извините, но у вас есть мертвый вес в вашей команде.
2) построить доверие. Колледж должен хорошо понимать теорию, но обычно это плохая подготовка к работе в команде, на больших частях программного обеспечения. Попросите человека понять, что плохие коммиты влияют на всю команду. Попросите его/ее понять, что задавать вопросы хорошо, и что каждый делает ошибки. Для этого я нашел пару программистов, потому что это показывает, что никто не бог (но не набирайте клавиатуру, никогда!). Попросите человека оценить, что они сделали хорошо, и где у них возникли проблемы с функцией, и рассказать им вашу оценку того, что было хорошо и не очень хорошо, или где вы видите улучшение. Также, чтобы поощрять вопросы, задайте также вопросы, если сможете, или мысли о проблеме, над которой вы работаете.

2
ответ дан 30 нояб. '09 в 22:20
источник

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

Я вижу несколько преимуществ для этого подхода:

  • Он может участвовать в StackOverflow, что является отличным способом улучшить ваш стиль программирования и изучить канаты.
  • Он может видеть вещи с вашей точки зрения.
  • Он может видеть все советы из первых рук и знать, что мы все были там раньше
  • Он откроет дверь для очень честного и перспективного отношения работодателя/сотрудника.
2
ответ дан 30 нояб. '09 в 22:35
источник

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

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

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

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

2
ответ дан 30 нояб. '09 в 19:41
источник

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

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

Никогда не пользуйтесь клавиатурой при парном программировании; в противном случае это хорошая идея. Также пусть он тоже сидит на вашем программировании.

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

2
ответ дан 30 нояб. '09 в 19:49
источник

Здесь много хороших моментов, поэтому я просто немного добавлю.

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

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

О, и если вы просматриваете свой код, попросите его просмотреть ваш.;)

1
ответ дан 30 нояб. '09 в 23:49
источник
  • Дайте им индивидуальные, четко определенные, кусочки размера укуса.
  • Сообщите им, почему каждый кусок необходим.
  • Начните их двумя кусками, чтобы они могли выбирать, что нужно делать дальше. Поскольку они учатся обрабатывать многозадачность, дайте им больше, чем это, и дайте им приоритеты и приблизительные сроки для каждого. Убедитесь, что у них есть бай-ин; они должны чувствовать, что каждый крайний срок является разумным.
  • Лично я склонен также предоставить всем новым разработчикам копию "Прагматического программиста".

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

1
ответ дан 01 дек. '09 в 0:05
источник

Это очень общий характер и может использоваться с другими предложениями по специфике.

Пока это может показаться очевидным, противостоять человеку (красиво, но с достаточной откровенностью, чтобы просветить). Во-первых, спросите, хотите ли они иметь вход и поделиться идеями об улучшении (это происходит в обоих направлениях), если они этого не сделают. Если они это сделают, вы отправитесь в положительную сторону, вы ЗНАЕТЕ, что видите, сообщите им откровенно, что вы наблюдаете, и спросите, желают ли они конкретного ввода в/в каждой из этих областей. ВСЕГДА дайте им знать, что все начинаются с самого начала, и эта индустрия ВСЕГДА учится - попытайтесь найти позитива, что ОНИ могут поделиться с вами очень рано - вы обнаружите, что это сделает акцент на "совместном использовании и коммуникации", а не диктаторский и самодержавный по стилю, и вы также можете научиться этому материалу!

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

1
ответ дан 01 дек. '09 в 16:23
источник

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

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

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

1
ответ дан 01 дек. '09 в 14:46
источник
  • Не надавливайте на него со временем.
  • Разбивайте задачи как можно больше - на самом деле разбивайте вещи на мельчайшие шаги, о которых вы можете думать
  • Не ожидайте, что он даст полезные оценки времени
  • УВЕРЕНЫ, ЧТОБЫ ИСКАТЬ ОБЗОРЫ КОДОВ. Просмотрите код и дайте хорошую обратную связь.

Поощряйте его, когда сможете.

Престижность вам в желании наставника.

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

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

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

Удачи.

1
ответ дан 30 нояб. '09 в 19:36
источник

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

  • Каждый метод документируется и следует стандартам С#/Java/. Вы можете обеспечить это, предоставив соответствующие ссылки на эти стандарты, чтобы он знал, где искать.
  • Каждый метод ясен и эффективен. Это немного субъективно, но это элемент контрольного списка, который дает вам точки разговора с ним, когда вы просматриваете его код, и это поможет ему увидеть, где ему нужно улучшить.
  • Каждый метод выдает правильные исключения. Если вы определяете пользовательские исключения в своих проектах (хорошая практика в целом), убедитесь, что он правильно их использует.
  • Нет избыточности кода. Убедитесь, что общий код заменен на вспомогательные методы и т.д.
  • Технологии используются правильно. Например, если вы видите, что он пишет метод подстроки для строки, он должен знать, использовать метод подстроки в самом классе строк, а не изобретать колесо.

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

И я думаю, что это поможет вам "держать руки от клавиатуры":).

Удачи.

1
ответ дан 30 нояб. '09 в 19:32
источник

Я бы, конечно, отказался от требований оценки времени.

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

1
ответ дан 01 дек. '09 в 11:55
источник

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

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

0
ответ дан 01 дек. '09 в 9:22
источник

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

0
ответ дан 01 дек. '09 в 15:21
источник

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

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

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

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

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

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

0
ответ дан 01 дек. '09 в 16:08
источник

Это сработало для меня.

  • Дайте ему задачу, которая измерима. Если он не измерим, тогда он не узнает, когда он это сделает, и, вероятно, запустит свои колеса. Лучшая метрика, на которую он будет надевать: Покрытие кода
  • Его задача - получить кодовый охват существующей базы кода до 100%, не меньше. Начните с одного модуля, а затем разверните его область.

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

Дайте ему эту работу, пока он не попросит что-нибудь еще. В этот момент вы можете оценить, готов ли он к чему-то более существенному. Это должно быть около отметки в 3 месяца.

0
ответ дан 01 дек. '09 в 23:12
источник

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

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

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

Код просматривает его материал и проверяет его код. Увидеть лучший код поможет его процесс. Его вопросы при попытке понять ваш код помогут вам лучше понять его мыслительный процесс.

0
ответ дан 02 дек. '09 в 20:57
источник

Я рекомендую вам смотреть Развивающая экспертиза: Herding Racehorses, Racing Sheep от Dave Thomas, это все о разных уровнях опыта и способах решения с ситуацией. Вы найдете, что лучший способ справиться с новичком - дать ему очень конкретные инструкции.

0
ответ дан 02 дек. '09 в 3:17
источник