Wed 23 Aug 2006
Что должен знать каждый программист?
Posted by Alex Lebedev under программирование, менеджмент
В личных разговорах и в сети я регулярно слышу мнение “Любой программист должен знать X, Y и Z”. Естественно, каждый раз люди называют в этом обязательном списки совершенно разные предметы. Lisp, C, Java, Python, Ruby, Javascript, ассемблер, высшая математика вообще и отдельные ее разделы в частности, английский язык, архитектура x86, design patterns, HTML, основы веб, javascript, принципы юзабилити, принципы параллельного программирования, регулярные выражения, XML, SQL, реляционные БД, теория сложности алгоритмов, lambda calculus и основы функционального программирования, архитектура Windows и Linux, 65535 других вещей. При найме программистов это мнение, за неимением лучшего, часто пытаются превратить в критерий отбора кандидатов.
В результате получается лажа. Некоторые люди, замечательно подошедшие бы в команду, отсеивается по этому критерию. Вместо них берут людей, подходящих по знаниям и опыту, но плохо подходящих для того, чтобы работать в команде. Или плохо подходящих для того, чтобы делать какую-либо полезную работу вообще.
Проблема в том, что набор “обязательного минимума знаний” часто формируется менеджером проекта (бывшим программистом) на базе собственного опыта, а не требований проекта. Если такой менеджер долго писал на C++ и научился на нем замечательным вещам, то он будет требовать от кандидатов знания C/C++. Даже если это абсолютно бесполезно для текущего проекта. И для всех будущих проектов тоже. Причина может быть и в инерции мышления и в стремлении найти “идеального программиста”, который не “может знать X, Y и Z”. И в том и в другом случае вы ухудшаете свои шансы найти лучшего кандидата.
Идеального программиста, если он и существует, невозможно стандартизировать. Каждый программист уникален. И при их отборе ваша основная цель - найти самого талантливого и пригодного для работы в команде кандидата, а не того, который лучше всего удовлетворяет надуманному набору требований.
Надо сказать, что если бы в идее “обязательного минимума” не было здравого зерна, она не была бы так привлекательна. Да, некоторые базовые знания необходимы, хотя бы для того, чтобы разработчики могли понять друг друга. Разумеется, не всем нужным вещам можно обучиться за пару месяцев. Именно по этой причине брать в команду веб-проекта C++-программиста, предыдущие 10 лет разрабатывавшего системы видеонаблюдения, - плохая идея. Впрочем, если кандидат сам горит желанием перейти в вашу область, это может изменить ситуацию.
Попробую описать правильное использование “обязательного минимума” при отборе кандидатов, как я его вижу.
Первое. Минимальные требования к кандидатам должны быть действительно минимальными. Только то, что не может не понадобится любому вашему разработчику в проекте, и только то из этого, чему талантливый программист не может быстро научиться.
Второе. Нет смысла пытаться стандартизировать разработчиков с помощью прокрустова ложа, все разработчики разные. Осознавать и использовать их индивидуальные достоинства гораздо приятнее и эффективнее, чем пытаться привести всех к единому стандарту.
Материалы по теме:
- Замечательная статья Джоэля Спольски об основных парадигмах разработки ПО: “Пять миров”
- Эрик Синк пишет о том, что скорость обучения важнее сегодняшних знаний: “Career Calculus”
August 23rd, 2006 at 10:44
Хм. Всех нормальных разработчиков очень легко подвести под общий знаменатель.
Характерные черты:
1) Ответственность. Как минимум полное тестирование проделанной работы.
2) Основы юзабилити. Человек может слова такого не знать, а всё равно должен задумываться удобно ли его API или интерфейс.
3) Работа в команде. Понимает, что нужно следовать общим требованим, чтобы другим легче было.
Это и есть обязательный минимум при отборе кандидатов. 8-( Почему так мрачно? Да потому, что и такие программисты уже похоже перевелись.
August 23rd, 2006 at 01:19
В том-то и дело, что нельзя. Разве что под общим знаменателем иметь в виду принадлежность к Homo Sapiens.
Очень важно. Но безответственный программист при минимальной QA-поддержке может отлично разрабатывать прототипы. То есть для ряда работ такого можно нанять, вопрос только в том, какие проекты вы ведете.
Даже полная юзабилити-бездарность элементарно обходится через то, что человек пишет реализации интерфейсов / API, придуманных коллегой, понимающим юзабилити.
Согласен, если вы работаете в команде, то это обязательное требование. Человек, не стремящийся облегчить работу своим коллегам, не может компенсировать это никаким индивидуальным вкладом. Даже если он делает работы больше, чем остальные программисты вместе взятые. Впрочем, с немеющими работать в команде такое нечасто бывает.
В общем, как я и писал, нужно, чтобы недостатки человека компенсировались его достоинствами, а не чтобы недостатков не было. Важный момент - в команде не должно быть “неприкрытых” недостатков, иначе не получится достигнуть хорошего результата. Например, если никто из членов команды не понимает юзабилити, по итоговый продукт будет, хм, своеобразным.
August 23rd, 2006 at 01:49
Так почитаешь такие дискуссии и приходишь к выводу, что нужно набирать не “хороших программистов” - а просто “хороших людей”, т.е. аккуратных и ответственных, способных работать в команде, быстро обучаться, радеющих за качество своей работы и т.д. - это же все относится к любой работе. К обязательному минимуму таких требований могу от себя добавить системность мышления, т.е. способность продумать, как твоя работа ложится в то, что было сделано до тебя и будет сделано после тебя.
А что касается узкопрофессональных навыков, т.е. языка или знания каких-то там платформ, то просто подбирайте людей под нужды проекта – если это «хороший человек» и знает то, что вам в данный момент нужно, то раздумывать долго не стоит.
August 30th, 2006 at 01:55
Да, судя по посту так и получается.
Мало быть хорошим человеком, надо быть ещё и программистом. IMHO, есть грань между опытностью программиста и его хорошестью. Нельзя загонять требования к программистам в узкие рамки. Надо рассматривать эту грань, требования проекта, требования PM к программистам. В каждом случае будут разные требования. Возможно очень, очень разные.
Первое. Минимальные требования к кандидатам должны быть действительно минимальными. Только то, что не может не понадобится любому вашему разработчику в проекте, и только то из этого, чему талантливый программист не может быстро научиться.
2) Основы юзабилити. Человек может слова такого не знать, а всё равно должен задумываться удобно ли его API или интерфейс.
не во всяком случае. пример - разработка ПО для какой нибудь железки, у которой одна кнопка.
1) Ответственность. Как минимум полное тестирование проделанной работы.
Важно. Но как это определишь?
3) Работа в команде. Понимает, что нужно следовать общим требованим, чтобы другим легче было.
Команда из одного человека? Команда из 140 человек? Возможно, есть разные команды - и разное понимание командной работы.
August 30th, 2006 at 02:03
В общем я хотел сказать что возможно можно вывести только общие требования, настолько общие, что они будут применимы в самом общем случае… И почти никогда в реальности. Точнее, будут достаточно большие отклонения от общего
August 31st, 2006 at 06:15
Ответственность можно определить как способность двигаться в правильном направлении выдавать качественный результат без постоянного надзора. Ответственность не обязательна для младших позиций, предполагающих постоянный надзор, но не каждый проект может себе позволить хотя бы одного безответственного разработчика.
Способность к работе в команде и понимание юзабилити можно свести к одному очень важному параметру - уважению к потребностям других людей, коллег, пользователей и руководства (с отсутствием последнего лично я готов мириться, главное чтобы результат это оправдывал). Без этого лучше разрабатывать софт только по жесткой спецификации. И только одному.