Помогаете младшим программистам преодолеть их недостатки? [закрыто]

15

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

Я не имею в виду межличностные навыки, такие как «выслушивание совета», я имею в виду технические вопросы, такие как (если применимо):

  • 'Вы никогда не делали SQL?'

  • 'Вы никогда не писали юнит-тест?'

  • 'Вы не знаете, как использовать командную строку Unix?'

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

Андрей М
источник
13
Самая раздражающая вещь: постоянно спрашивать о том, что раздражает. :-)
Джерри Коффин
12
Я не думаю, что вас должно раздражать, когда люди не знают того, о чем вы ожидаете. Важно то, что они хотят учиться =)
koenmetsu
Да, согласен с @KoMet, если у вас есть желание научиться слушать. Я думаю, что это важно :)
MalsR
8
Мне не нравится этот вопрос, у него неправильный менталитет для разработчика. МЫ ВСЕГДА БЫЛИ ЕДИНСТВЕННЫМИ, и каждый день мы новички Я бы НИКОГДА не раздражался из-за того, кто чего-то не знает. Такое ощущение, что в этом слишком много высокомерия ....
Темная ночь
3
Ох, закрыто, BRAVO. Я прочитал шесть основных конструктивных субъективных вопросов, и это отвечает всем им. Честно говоря, неконструктивная часть - это занятые лица, закрывающие ветку, на которую 13 человек уже ответили, просто потому, что они неправильно поняли вопрос. Просто реальность такова, что старшие разработчики иногда разочаровываются в способностях младших разработчиков, этот вопрос только пытается найти какие-то закономерности в этом разочаровании, чтобы мы могли лучше избегать трудностей. Игнорирование законных жалоб и критики никому не идет на пользу и не имеет ничего общего с высокомерием.
Андрей М

Ответы:

25

Не зная, что такое контроль версий или как правильно его использовать .

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

sevenseacat
источник
4
Пресмыкаться? Ей повезло, у нее все еще есть работа.
Рейн Хенрикс
2
Похоже, это скорее вопрос «не знать, чего не знаешь» или «не признавать того, чего не знаешь». Если бы она с самого начала обратилась за помощью, это было бы вообще важно?
Майкл МакГоуэн
1
о, это звучало как я, ха-ха, мы не внедрили контроль версий до недавнего времени, и я присоединился к компании как свежий выпускник, я немного изучил управление версиями и подрывную деятельность в университете, но никогда не реализовывал его раньше.
Суфенди
1
«Это инструмент для резервного копирования, не так ли? Вы используете его для сохранения своего кода каждый вечер?»
Дэвид
2
Это одна большая вещь, что они почти никогда не учат вас в школе
Элайджа Саункин
23

Не задавая достаточно вопросов

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

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

Стивен Эверс
источник
Ну и дела ... почти тот же ответ, который я написал, вы идете примерно за 5 секунд до.
quick_now
2
"Вы раздражаете! Я занята здесь, вы не можете думать самостоятельно?" если тебе не повезло !! хаха
Суфенди
4
+1 - Подзаголовок об этом не просит после объяснения. Это действительно разозлило меня, когда я объяснил какое-то задание младшему, он кивнул, я думал, что он его получил и приступит к работе, затем через две недели он возвращается, снова задает те же вопросы, снова кивает, затем еще два недели спустя ... Достаточно справедливо, это была не тривиальная задача, но ради бога, не притворяйся, что понимаешь, если не понимаешь. И если вам кажется, что вы что-то поняли, сделайте записи, чтобы вспомнить это через две недели.
Петер Тёрёк
1
С другой стороны, некоторые люди задают слишком много вопросов (о переполнении стека).
BoltClock
1
@SnOrfus: Те, кого я не квалифицировал, это те, кого я имею в виду: P
BoltClock
14

Скопируйте вставку и метод проб и ошибок вместо того, чтобы пытаться понять основные принципы

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

Сохраняя свой «первый черновик» кода

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

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

Карл Билефельдт
источник
1
+1 за «копировать и вставлять вместо того, чтобы пытаться понять», хотя, конечно, это не проблема, уникальная для новых программистов, просто для плохих. Новые программисты, по крайней мере, имеют шанс вырасти из этого - ребята, с которыми я работаю, которые были программистами в течение десятилетий и до сих пор делают это, не делают.
Том Андерсон
Частично это также может быть следствием стиля управления. Задача уже говорит дольше, чем ожидалось, и менеджер хочет, чтобы ваша функция была завтра. Вы торопитесь заставить его работать и быстро переходите к следующему заданию. Все разбито на карты задач небольшого размера, поэтому нет времени на рефакторинг или отступление назад, чтобы посмотреть на большую проблему в целом
Джейми МакГиган,
14

Полагая, что вы первый столкнулись с ситуацией.

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

Редактировать :

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

Скотт Уитлок
источник
1
Ну, также вы не хотите, чтобы разработчик копировал и вставлял весь код из некоторых сомнительных ресурсов из Интернета. Поиск полезен, чтобы получить некоторые идеи, возможно, решить некоторые фундаментальные проблемы понимания, но никогда не получить готовые решения. Это также делает разработчика тупее; возможно, это делает его хорошим коллекционером, но не изобретателем.
Элайджа Саункин
В какой-то момент я согласен с Элайджей: копирование-вставка кода, не затрачивая время на изучение того, что он делает, не ускоряет ваши навыки программирования. Хуже всего, что это вступит во владение и станет плохой привычкой.
Сетзамора
1
Конечно, но @ Scott ничего не сказал о копировании и вставке кода, он просто сказал, не думайте, что вы первый столкнулись с ситуацией, т. Е. Понимаете, что может быть какая-то информация и опыт, которые вы можете извлечь из этого. Пример: я хочу знать, похожи ли две строки. Есть ли уже известный алгоритм для решения этой проблемы? Представьте себе, если разработчик просто решил начать свою собственную разработку, даже не зная, что ответы уже существуют.
Дэвид Конрад
@ Дэвид Конрад, верно, верно, мы на одной странице здесь.
Илия Саункин
10

Думая, что они все знают.

У меня был младший стажер, который пытался решить все с помощью JavaScript. Пытался объяснить несколько понятий, но он всегда думал, что может сделать это лучше. Теперь он закрыл и перерабатывает основную программу, которую он создал для вывода на печать, используя HTML вместо технологии, готовой к печати, такой как PDF. Не говоря уже о куче других серьезных проблем.

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

P.Brian.Mackey
источник
5

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

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

Не желая продвигать свои знания - вместо этого они идут по пути наименьшего сопротивления.

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

Я сел с стажером и объяснил, что именно не так и почему. Мы исправили ошибку, затем я указал на несколько дополнительных улучшений («так как я здесь»), и в итоге мы переписали функцию виновности в 10 строк вместо 20 и без ошибок. Отвечая на любые вопросы, убедившись, что в мире снова все в порядке, я ушел.

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

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

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

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

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


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

Николь
источник
Как и на базовом уровне, они не знают, что вы подразумеваете под созданием объектов, классов и наследственности? Или более продвинутые вещи, такие как использование шаблонов дизайна (вы должны признать, что книга GoF довольно сложная, хотя, конечно, есть и другие книги / руководства)
Andrew M
@ Андрей, я немного расширил ответ.
Николь
1
И я вижу обратное: не знаю, как писать простой старый процедурный код на C, потому что его учили только ООП. Опять же, не заставляйте меня рассказывать о людях, которых больше не учат писать парсеры, потому что им говорят, что все эти проблемы можно решить с помощью lex и yacc.
quick_now
1
@quickly_now Это хороший момент, хотя writing code other ways than OOPи writing bad OOPдве совершенно разные вещи. Во-первых, у меня нет проблем с.
Николь
Большинство университетов не преподают объектно-ориентированный дизайн. Также многие рабочие места работают как бункеры даже с младшими разработчиками ... или имеют "старших" разработчиков, которые не знают, что такое объектно-ориентированное программирование. Есть «старшие» разработчики, которые получили звание от работающих х лет, и старшие разработчики, которые знают свое дело…
Cervo
3

Не зная, чего не знаешь, и в неведении думая, что ты знаешь все.

(И его близкий двоюродный брат, не желая спрашивать.)

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

quickly_now
источник
2

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

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

Напишите код, который вычисляет N-е число Фибоначчи .

Они почти всегда идут на большинство, пишут очевидное, но неэффективное

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Когда меня просят прокомментировать алгоритмическую сложность, я обычно получаю «это хуже, чем O (N) ... хм ... O (N logN)». Это на самом деле (гораздо) хуже, чем это ...

Эрик Дж.
источник
1
Чтобы ответить на ваш вопрос о полноте, нужно знать эту формулу для вычисления чисел Фибоначчи без рекурсии, которую он использовал бы вместо рекурсии в первую очередь.
П Швед
1
@Pavel: есть решение O (n) и O (1) ... на самом деле Like every sequence defined by linear recurrence, the Fibonacci numbers have a closed-form solution. en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
Эрик Дж.
1
Я не говорю, что вы разместили идеальное решение. Я просто сомневаюсь в актуальности вашего последующего вопроса для такого решения, вопроса о сложности. Чего вы хотите добиться, задавая этот вопрос, и, что наиболее важно, почему вы ожидаете, что то, чего вы хотели, будет достигнуто при ответе на предыдущий вопрос? (Я сделал свою точку зрения?)
P Швед
чтобы прояснить мою точку зрения, я бы предложил вам спросить о том, как можно улучшить код, вместо того, чтобы просить оценить сложность. Я уверен, что некоторые выпускники CS предложат запоминание или скажут, что они знают формулу, но не хотят показывать ее сразу, потому что вы думаете, что они умники.
П Швед
С практической точки зрения, такую ​​функцию можно обнаружить с помощью профилировщика и оптимизировать, добавив в кэш-память. Неэффективность на самом деле является проблемой только для больших значений N. Лучший способ научить младших по такому коду - заставить их пошагово выполнять весь код, используя отладчик. Оказывается, для действительно больших значений N существует математическая формула maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/…
Джейми МакГиган,
1

Делать обратный код отступа!

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

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

она написала бы как (Боже, это все еще кажется мне невозможным!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Разочарование не так ли?

Элайджа Саункин
источник
Что во имя ...
Майк Спид
1
Это очень удивительно !!!
Джаванна
Это почти как если бы они были на арабском, иврите или китайском, где вы читаете справа налево, а не на западном соглашении слева направо. Это совершенно правильный способ отступа в вашем коде, но он означает, что вам нужно заново сделать отступ для всего файла, основываясь на самом глубоком уровне вложенности, и он делает ваш код несовместимым со всеми, кто разделяет противоположное соглашение.
Джейми Макгиган