Як наставити молодшого розробника

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

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

Коли я кажу "новий розробник", вони можуть бути деінде від коледжу до досвіду року чи двох.

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

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

А може:

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

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

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

Мої основні завдання:

• Допоможіть їм і надайте їм необхідні інструменти, щоб почати ставати більш самостійними.
• Направляйте їх у правильному напрямку та порушуйте шкідливі звички розвитку на початку.
• Зменшіть кількість часу, який я провожу з ними (описаний вище тип особистості, як правило, потребує набагато більше один за одним і не надто добре над чатом чи електронною поштою. Хоча це загалом добре, я не завжди можу зупинити те, що я ' я працюю над тим, щоб порушити крок і допомогти їм налагодити помилку на моменти сповіщення; у мене є власні проекти, які потрібно виконати).

Тут колись виникало питання, яке містило таку інформацію, і деталь, яка найбільше застрягла в мені, - це не торкатися їх клавіатури

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

Але крім цього, ось ще кілька порад:

• Заохочуйте Google (або будь-який інший інструмент пошуку). Якщо ви знаєте, що відповідь можна легко знайти в Інтернеті, скажіть, щоб вони її шукали, а не говорили їм відповідь. Зрештою, ви хочете навчити їх, як навчати себе , а не робити їх залежними від вас.
• Будьте доступні для відповіді на запитання. Якщо ви ніколи не доступні або не хочете, щоб вас переривали, дайте їм зрозуміти, що вони повинні затримати свої запитання до визначеного часу.
• Регулярно проводите огляди коду, щоб повідомити, що вони роблять правильно / неправильно. Використовуйте це як можливість вказати на найкращі практики
• Почніть рано з кращих практик. Краще витратити додатковий час, щоб навчити їх правильному шляху, ніж потім намагатися і змінити свої методи.
• Почніть їх рано з планування / документування того, що вони будуть робити, а не дозволяти їм починати з написання коду.
• Будьте відкриті до навчання у них. Вони, ймовірно, витрачають більше часу, ніж ви навчаєтесь, і можливо, вони дізнаються щось, чого ви не знали.

• Допоможіть їм вчитися на своїх помилках. Будуть помилки, тому обов'язково покажіть їм, що помилки є частиною навчання, і що вони повинні використовувати їх як можливість вчитися.

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

• (З RuneFS нижче) Замість того, щоб розповідати їм про те, що вони зробили не так, розкажіть їм про способи їх покращення. Обов’язково вкажіть, чому ваш шлях кращий за їхній. Це підвищить їхню впевненість, а не послабить її. Звичайно, якщо вони вас не слухають, то не бійтеся просто сказати їм зробити це правильно :)

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

По суті, ви хочете заохотити їх вчитися. Деякі люди думають, що після закінчення навчання в коледжі їм більше не потрібно читати книги чи вчитися. Таке ставлення може призвести до того, щоб шукати ярлики та просто "робити це".
Отримайте їх "Прагматичний програміст" і попросіть їх прочитати. Ця книга допоможе їм усвідомити, що програмування - це ремесло / кар’єра, а не просто робота. Рекомендуйте книги читати щоквартально або близько того. Допоможіть їм створити свій "портфель знань" (як згадується у Прагматичному програмісті). Я настійно рекомендую Safari Books Online, у яких багато книг CS / програмування.

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

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

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

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

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

Огляди коду теж критичні. А якщо ви паруєте програму, дайте йому клавіатуру часто. Навіть якщо ви говорите йому, що слід вводити, він навчиться робити більше набирання тексту, що навчиться просто сидіти поруч, поки ви програмуєте.

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

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

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

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

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

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

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

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

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

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

Залежно від поставленого завдання, я б спокусився скористатися кількома різними підходами:

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

• Погляньте швидко, що вони хочуть зробити, і запропонуйте підказки, щоб вони з'ясували проблему. Це замість того, щоб дати відповідь "Просто вийміть цей рядок коду", запропонуйте вони подивитися, що там є, і чи все це потрібно.

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

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

Одне, що я зробив тут у своїй роботі, який вважав мене справді корисним, - це створити форум (тобто PHPbb) для внутрішніх запитань і відповідей, і дотримуватися правила, що якщо питання та / або відповідь займає більше 5 хв, це повинно бути запитав і відповів через форум. Переваги:

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

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

Натомість, з'єднайтеся з ними у пошуку відповіді. Ви все одно збираєтеся в Google, тому робіть це, сидячи з ними. Вони підберуть, що це спосіб знайти відповіді.

Якщо ви тісно співпрацюєте з ними, вони підберуть, як правильно використовувати IDE; Як нормалізувати базу даних; як ПУСИТИ свій код ... все, що ви знаєте, що варто знати.

Ключі: одне - зробити себе доступними для них, щоб вони могли бачити, як ви працюєте. І два - сказати вголос, чому ти робиш те, що робиш. "Цей код повторюється, тому я збираюся його рефакторировать," не "використовувати метод витягу в цих трьох рядках."

Мені тільки колись доводилося тренувати молодшого програміста. Це було допомагати підтримувати систему, яку я побудував. Метою було врешті-решт передати йому всю систему.

Через короткий період, коли він затінив мене, я кинув його у вогонь. Я б призначив йому справи і очікую їх завершення. Якби у нього були проблеми, я б змусив його пояснити, в чому проблема, і куди він дивився. Тоді я б порадив йому в найзагальніших рисах, де шукати далі. (Яке додаток, можливо, який модуль подивитися тощо). Я ніколи не залишав би його розлетітись, але я також ніколи не зробив би жодної роботи. Надати лише напрямок. Якби у нього все-таки були проблеми, я просто знизав плечима і сказав «Почніть відстежувати код». І кожен раз, коли я це говорив, він буде скупитися - знаючи, що його чекає втомлива вправа. Це ганяло його, бо ми обоє знали, що я, мабуть, зможу знайти проблему за 10 хвилин, якщо я просто зійду зі свого прикладу та допоможу.

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

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

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

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

Це забезпечить наступне:

• Взяти на себе частину тягар досвідчених розробників.
• Змушує нового розробника вчитися.
• Щастя для всіх.

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

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

Таким чином ви зобов’яжетеся виділити час на роботу з молодшими, і він зможе побачити "реальне життя". Працюючи над реальними завданнями і чуючи жваві відгуки, він зможе досить швидко досягти швидкості.

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

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

• Пакет інструментів та навичок
• Метод вирішення проблем

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

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

• Налагоджувач (коледж ніколи про це не згадував)
• Профілі
• Текстовий редактор
• Shell (та пов’язані з ними утиліти)
• Ресурси (книги, google, SO, manpages)

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

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

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

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

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

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

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

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

Інші відповіді дуже хороші, але я хотів прокоментувати це одне речення.

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

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

Рідкісні люди, які хочуть знати, чому щось робиться. Це люди, яких хочуть розумні менеджери, навіть якщо часом важко керувати.

Деякі люди кодують, щоб добре платити. Інші із задоволенням приймають гроші за кодування. Набагато приємніше працювати з людьми, які захоплюються дизайном та кодуванням. На жаль для мене це теж було досить рідко. Принаймні, поки я не знайшов Stack Overflow.

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

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

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

• Не кожен є добрим викладачем чи наставником, і не всі хочуть бути ним. Я не маю на увазі звучати хрустко або гірко; Мені подобається викладання, багато. Але дурно розраховувати, що всі будуть в цьому добрі (незважаючи на власні таланти), і не можна сподіватися, що всі сподобаються цьому процесу (пам’ятайте, це не просто). Крім того, якщо ви є старшим розробником, який не любить наставництво, або якщо ви дійсно вважаєте, що ви поганий вибір для викладача чи наставника, переконайтесь, що ваше керівництво розуміє, що план, який стосується вас, виконуючи ці обов'язки, - це план з серйозна вада. З іншого боку, якщо ви хочете стати хорошим у навчанні чи наставництві, це теж має комунікація.

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

Я подивлюся на це.

В основному, я добре вчуся, коли:

1. Я отримав офіційне вступ до теми. Я ніколи не можу навчитися чомусь новому без того, щоб хтось (так, людина) відповів на всі питання, які виникають у мене щодо нових понять. Як тільки я це зробив, я ...
2. Отримайте книгу. Як мій наставник у вас повинна бути точно така ж книга, щоб я завжди міг сказати щось на кшталт "Гей, що це означає в четвертій главі, стор. 72, пункт 6 ...", і ти точно знатимеш, про що я говорю о. Після того, як у мене з’явиться книга, я стає більш незалежним і дійсно задаю лише питання. Потім я...
3. Розпочніть проект разом. Це найважливіша частина процесу. Тут ви можете почати навчати мене про кращі практики, алгоритми, складні (але корисні) мовні особливості тощо.

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

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

• 1 місяць. Слід знати базовий синтаксис. Все ще не залежить від кодування.
• 3 місяці. У цей момент він повинен знати синтаксис, як тильну сторону руки, і повинен вміти легко вирішувати прості проблеми. Він набагато більш незалежний, просто ще не зовсім там.
• 6 місяців. Вони повинні знати, крім усього іншого: найкращі практики, загальні алгоритми і т. Д. Він повинен мати можливість самостійно робити проект, можливо, за допомогою трохи допомоги.

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

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

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

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

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

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

Я не бачив тут, щоб хтось згадував про мого особистого героя, Ренді Пауша .

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

• досягнення вашої мрії (він був професором, і це дуже пов'язане з мотивацією інших), і
• управління часом .

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

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