Как Наставить Младшего Разработчика

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

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

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

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

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

Или возможно:

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

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

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

Моими основными целями являются:

• Помогите им и дайте им инструменты, которые им необходимы, чтобы стать более самостоятельными.
• Направьте их в правильном направлении и избавьтесь от вредных привычек развития на ранней стадии.
• Уменьшите количество времени, которое я провожу с ними (описанный выше тип личности, как правило, требует гораздо больше времени один на один и не очень хорошо справляется с обменом мгновенными сообщениями или электронной почтой. Хотя в целом это нормально, я не всегда могу остановить то, что я делаю » я работаю над тем, чтобы прекратить свои действия и помочь им отладить ошибку на мгновение; у меня есть свои собственные проекты, которые необходимо выполнить).

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

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

Но в дополнение к этому, вот еще несколько советов:

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

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

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

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

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

По сути, вы хотите поощрить их учиться. Некоторые люди думают, что после окончания колледжа им больше не нужно читать книги или учиться. Такое отношение может привести к поиску ярлыков и просто «сделать это».
Получите их «Прагматичный программист» и попросите их прочитать. Эта книга поможет им понять, что программирование - это ремесло / карьера, а не просто работа. Рекомендуйте книги для них, чтобы читать каждый квартал или около того. Помогите им создать свой «портфель знаний» (как упомянуто в Pragmatic Programmer). Я очень рекомендую Safari Books Online, в которой много книг по CS / программированию.

С их портфелем знаний они будут знать, где искать, если у них есть проблемы. Научите их, где искать. Я сам недавно обнаружил полезность StackOverflow (и, как вы знаете, здесь лучше, чем просто Google).

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

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

Задавайте наводящие вопросы, чтобы направить его к ответам, а не просто рассказать ему (ну, вы можете сказать ему некоторые основные вещи, такие как имя сервера и в какой базе данных хранится информация). Покажите ему, как найти его ответы.

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

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

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

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

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

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

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

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

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

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

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

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

В зависимости от поставленной задачи у меня будет соблазн выбрать несколько разных подходов:

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

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

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

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

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

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

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

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

Если вы будете тесно сотрудничать с ними, они поймут, как правильно использовать IDE; Как нормализовать базу данных; как высушить ваш код ... все, что вы знаете, стоит знать.

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

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

После короткого периода, когда он следил за мной, я бросил его в огонь. Я бы назначил ему дела и ожидал, что они будут завершены. Если бы у него были проблемы, я бы попросил его объяснить, в чем была проблема, и куда он смотрел. Я бы тогда посоветовал ему в самых общих чертах, где искать дальше. (Какое приложение, возможно, какой модуль посмотреть и т. Д.). Я никогда не оставлю его барахтаться, но я также никогда не буду выполнять какую-либо работу. Только укажите направление. Если бы у него все еще были проблемы, я бы просто пожал плечами и сказал: «Начни отслеживать код». И каждый раз, когда я говорил это, он съеживался, зная, что ему нужно утомительное занятие. Это сводило его с ума, потому что мы оба знали, что я, вероятно, смогу найти проблему через 10 минут, если я просто соскочу с задницы и помогу.

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

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

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

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

Это выполнит следующее:

• Взять на себя часть бремени опытных разработчиков.
• Заставить нового разработчика учиться.
• Счастья всем.

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

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

Таким образом, вы посвятите себя выделению времени на работу с младшим, и он сможет увидеть «настоящую жизнь». Работая над реальными заданиями и выслушивая живые отзывы, он сможет довольно быстро набрать скорость.

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

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

• Инструментарий навыков и инструментов
• Метод решения проблем

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

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

• Отладчик (Колледж никогда не упоминал об этом)
• Профайлеры
• Текстовый редактор
• Shell (и связанные утилиты)
• Ресурсы (книги, Google, SO, справочные страницы)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я дам тебе мой взгляд на это.

В основном, я хорошо учусь, когда я:

1. Дается официальное введение в тему. Я никогда не смогу узнать что-то новое без того, чтобы кто-то (да, человек) ответил на все мои вопросы о новых концепциях. Как только я это сделал, я ...
2. Получить книгу. Как мой наставник, у вас должна быть точно такая же книга, чтобы я всегда мог сказать что-то вроде: «Эй, что это значит в четвертой главе, стр. 72, пункт 6 ...», и вы точно поймете, о чем я говорю около. Когда у меня есть книга, я становлюсь более независимым и на самом деле задаю только вопросы. Затем я...
3. Начните проект вместе. Это самая важная часть процесса. Здесь вы можете начать рассказывать мне о передовой практике, алгоритмах, сложных (но полезных) языковых функциях и т. Д.

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

С учетом сказанного вам все равно придется работать с ним на регулярной основе. Общая «временная шкала» должна быть:

• 1 месяц. Должен знать основной синтаксис. Все еще не зависит при кодировании.
• 3 месяца. На данный момент он должен знать синтаксис, как тыльная сторона его руки, и уметь легко решать простые проблемы. Он гораздо более независимый, просто еще не совсем там.
• 6 месяцев. Они должны знать, помимо всего прочего: лучшие практики, общие алгоритмы и т. Д. Он должен быть в состоянии сделать проект сам, возможно, с небольшой помощью SO.

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

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

Надеюсь, это поможет! Кстати, пусть он прочтет это: научи себя программированию за десять лет .

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

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

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

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

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

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

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

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