Каковы ваши общие претензии к начинающим разработчикам, которые присоединяются к вашей команде или с кем вам приходится работать? Очевидно, что они неопытны, поэтому вы не можете ожидать, что они знают все, но какие навыки часто необъяснимо не хватает - и как, в частности, мы можем помочь им развить эти недостающие навыки?
Я не имею в виду межличностные навыки, такие как «выслушивание совета», я имею в виду технические вопросы, такие как (если применимо):
'Вы никогда не делали SQL?'
'Вы никогда не писали юнит-тест?'
'Вы не знаете, как использовать командную строку Unix?'
Вещи , которые вы бы ожидать , - я хотел бы услышать ваши замечания и методы для обучения новых программистов , чтобы получить мимо этих конкретных недостатков.
teamwork
knowledge-transfer
Андрей М
источник
источник
Ответы:
Не зная, что такое контроль версий или как правильно его использовать .
Один из младших разработчиков, который недавно работал в моей компании несколько месяцев, должен был научиться самым основам Subversion. Это действительно заставило меня съежиться ... она все время проверяла код для живых проектов ... и понятия не имела, что она делает ...?
источник
Не задавая достаточно вопросов
Я знаю, что они младшие, я ожидаю, что они будут делать ошибки и просто не знают вещей. Такого количества королевских взлетов можно было избежать, просто задав вопрос, а не предполагая что-то. Честно говоря, я не могу приставать достаточно.
У меня были тонны вопросов, когда я начинал - задавая их, я несколько раз спас мою задницу. Черт, у меня все еще много вопросов ... Мне просто нравится думать, что сейчас они лучше.
источник
Скопируйте вставку и метод проб и ошибок вместо того, чтобы пытаться понять основные принципы
Многие начинающие разработчики будут копировать код, который выглядит близко, а затем почти случайным образом пробуют различные варианты модификаций методом грубой силы, пока не найдут тот, который работает. Если вы не знаете, почему это работает, скорее всего, вы вносите ошибки в граничные случаи, которые кто-то, понимающий это, должен будет устранить позже.
Сохраняя свой «первый черновик» кода
Когда опытный разработчик пишет новую функцию определенной сложности, он начинает с заглушки, которая ничего не делает, кроме компиляции, затем переписывает, чтобы добавить высокоуровневые комментарии псевдокода для всего алгоритма, а затем переписывает эти комментарии по одному с фактический код, добавление и удаление фиктивного кода по мере необходимости для тестирования, затем перезапись, чтобы удалить избыточность, возникшую во время реализации, и так далее в серии последовательных и постепенных улучшений.
Младшие разработчики имеют тенденцию записывать их в один большой кусок, а затем выполнять массовую отладку методом грубой силы. Им не нравится удалять строку кода после ее ввода в редакторе, и они настолько счастливы, что наконец-то заставили ее работать, поэтому им не хочется переписывать для нефункциональных улучшений, но именно они должны это делать. так самое.
источник
Полагая, что вы первый столкнулись с ситуацией.
С любой проблемой программирования, с которой вы сталкиваетесь, сталкиваются другие в некоторой общей форме. У опытных программистов есть чему поучиться. Я достаточно взрослый, чтобы помнить программирование до Google, и это отстой . Еще хуже было, когда у нас были поисковые системы, но в Интернете еще не было так много хорошей информации. Программирование теперь намного продуктивнее, потому что у вас есть доступ к глобальным знаниям за считанные секунды. Люди, которые не используют его, игнорируют его на свой страх и риск.
Редактировать :
Просто чтобы прояснить, я не защищаю программирование копирования / вставки. Я уверен, однако, что вам нужно проверить имеющиеся знания, прежде чем вы сможете принимать правильные решения самостоятельно.
источник
Думая, что они все знают.
У меня был младший стажер, который пытался решить все с помощью JavaScript. Пытался объяснить несколько понятий, но он всегда думал, что может сделать это лучше. Теперь он закрыл и перерабатывает основную программу, которую он создал для вывода на печать, используя HTML вместо технологии, готовой к печати, такой как PDF. Не говоря уже о куче других серьезных проблем.
Урок состоит в том, чтобы просить пожилых людей о главном всеобъемлющем руководстве в начале проекта, не отказывайтесь от архитектур без посторонней помощи. Вы можете написать код и детали в одиночку, но убедитесь, что вы хотя бы используете правильную технологию.
источник
Я редко раздражаюсь, когда младшие не знают основ, им не преподают отраслевые навыки, такие как SCC в университете. Это работа старших разработчиков, чтобы научить их. Меня раздражают только личные столкновения. Но меня больше всего раздражают старшие разработчики, которые не знают основ.
источник
Не желая продвигать свои знания - вместо этого они идут по пути наименьшего сопротивления.
На днях стажер вместе с графическим дизайнером (который удивительно разбирается в программировании) обратился за помощью, потому что они столкнулись с проблемами при реализации чего-либо в jQuery - закрытие может быть болезненным, если вы не видите, что это произойдет.
Я сел с стажером и объяснил, что именно не так и почему. Мы исправили ошибку, затем я указал на несколько дополнительных улучшений («так как я здесь»), и в итоге мы переписали функцию виновности в 10 строк вместо 20 и без ошибок. Отвечая на любые вопросы, убедившись, что в мире снова все в порядке, я ушел.
На следующий день стажер пришел с вопросом, который показал, что он «хочет внести некоторые изменения и переписал эту функцию по-моему, потому что мне было трудно это понять» (по большей части отмена моих улучшений).
Он может либо попробовал труднее вместо (задавать дополнительные вопросы, читая на понятиях , которые я упоминал) - код так коротка никогда не может быть , что трудно понять - или взять легкий выход. Это печалит меня каждый раз, когда я вижу, как кто-то делает последнее.
источник
Не понимая ООП. К сожалению, это гораздо чаще, чем большинство из нас, вероятно, осознают.
Знание того, как создать класс, абстрактный класс, интерфейс или даже знание полиморфизма - это одно; понимание того, как правильно использовать их в интересах вашей программы, другое .
Если вы хотите избежать этого, я нашел эти вопросы и ответы на них поучительными:
источник
writing code other ways than OOP
иwriting bad OOP
две совершенно разные вещи. Во-первых, у меня нет проблем с.Не зная, чего не знаешь, и в неведении думая, что ты знаешь все.
(И его близкий двоюродный брат, не желая спрашивать.)
Отчасти это организационная вещь - соответствующая входящая индукция будет иметь большое значение для предотвращения возникновения некоторых из этих проблем. Но очень немногие компании имеют время или людей, готовых к вводной работе - что может занять от нескольких дней до нескольких недель и лишит разработчиков работы. Таким образом, мы должны потушить огни вместо этого.
источник
Я поражен тем, как много младших программистов, относительно недавно вышедших из CS-программы, слабы с алгоритмами. Неправильный выбор алгоритма может не особо выделяться в бизнес-приложениях, но при обработке миллиардов запросов веб-служб в день это действительно имеет значение.
Вот вопрос об интервью, который я использую, который пропускают почти все младшие программисты, который подчеркивает проблему:
Напишите код, который вычисляет N-е число Фибоначчи .
Они почти всегда идут на большинство, пишут очевидное, но неэффективное
Когда меня просят прокомментировать алгоритмическую сложность, я обычно получаю «это хуже, чем O (N) ... хм ... O (N logN)». Это на самом деле (гораздо) хуже, чем это ...
источник
Like every sequence defined by linear recurrence, the Fibonacci numbers have a closed-form solution.
en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expressionДелать обратный код отступа!
Конечно, это не очень "типично". Я никогда не мог поверить, что это даже возможно, но как бы написал нормальный разработчик
она написала бы как (Боже, это все еще кажется мне невозможным!)
Разочарование не так ли?
источник