В мире существует множество классификаций программистов — простые и сложные, фокусирующиеся на какой-то одной стороне деятельности (например, на технических навыках) или комплексные. Ни в коей мере не умаляя их значения, хочу предложить вам свой вариант, который рассматривает программистов с точки зрения их ценности для бизнеса:
- junior - знает, что есть;
- middle - знает, что можно;
- senior - знает, что нужно.
Расшифровка на примере ситуации — когда вы сказали программисту что нужно сделать:
junior - возьмется делать, по ходу будет задавать вопросы, как это сделать, и если ему внятно объяснять как нужно — сделает;
middle - поисследует и предложит варианты, как это можно сделать, возможно порекомендует оптимальные, получив ваше одобрение — сделает;
senior - спросит — а зачем это делать, чего вы хотите добиться? Вы расскажете ему о своих целях. Он исследует вопрос, потом возможно поправит вас, скажет, что вот этого хотеть не надо, а вот другого - надо, приведет аргументы. Когда согласие насчет целей достигнуто, он найдет что и как для этих целей лучше сделать (вполне может оказаться, что это будет совсем не то, что вы предлагали изначально), и сделает в оптимальном виде.
По моим наблюдениям, помимо ценности для бизнеса эта классификация отражает естественный рост программиста в профессии. Junior начинает с изучения основ программирования - языки, фреймворки, алгоритмы, и т.д. Поэтому он в основном сфокусирован на уровне «как сделать». Middle уже достаточно уверенно владеет языками и фреймворками, поэтому он переходит к следующему уровню - «что сделать». Он расширяет свой кругозор, интересуется альтернативными вариантами решений, интересуется архитектурными подходами, начинает сравнивать разные подходы и формировать свои оценки для них. Senior уже обладает достаточно широким кругозором, и имеет за плечами серьезный опыт. Он чувствует в себе достаточно уверенности для того, чтобы самостоятельно найти подход практически к любой задаче. В то же время, он уже повидал в своей практике последствия плохих управленческих решений, когда люди выбирали неправильные пути для достижения своих целей, или вообще затруднялись четко сформулировать свои цели, из-за чего проекты терпели неудачу. Поэтому он начинает интересоваться уровнем «зачем» и выбором оптимального направления движения проекта. Таким людям часто доверяют быть тимлидами в командах, потому что они уже работают на том уровне, когда могут влиять на курс движения проекта в целом.
Также полезно: Понимаем сленг программистов мини-словарь для начинающих разработчиков
Чем эта классификация может быть полезна для программистов? Я думаю, из нее можно почерпнуть совет - как быстрее расти в профессии. В общем случае ответ на вопрос «как быстрее расти» конечно многогранен, и вряд-ли кто-то сможет претендовать что знает золотой универсальный способ. Поэтому этот совет я приведу с такой оговоркой - мы используем это в нашей компании (ivelum), и, мне кажется, это работает. Я не могу обещать что это подойдет всем, но по крайней мере вы можете принять это к сведению, и возможно попробовать.
Итак, как быстрее расти:
во-первых, старайтесь никогда не делать такой работы, смысла которой вы не понимаете. Если вам поставили очень конкретную задачу (типа, «добавить столбец в таблицу») и не объяснили как это будет использоваться - постарайтесь это узнать. Где именно будет место этой работы в общей картине проекта, для чего это нужно делать, и почему выбрано именно такое решение;
во-вторых, привыкайте к работе с неопределенностью. Если вы попадаете в ситуацию, в которой вам непонятно что делать, то не спешите сразу идти к начальнику или к заказчику с вопросом "что делать". Постарайтесь сначала найти варианты решений самостоятельно. Подумайте, в чем цели работы, какие есть варианты, какие у них плюсы и минусы. Вы все равно можете потом пойти к начальнику с вопросом «что делать», но вы уже придете к нему с готовыми вариантами решений, с их анализом, и возможно с вашей рекомендацией - давайте сделаем вот это;
в-третьих, привыкайте брать на себя ответственность. Не во всех компаниях есть для этого подходящие условия (в нашей - есть :), но постарайтесь их найти. Постарайтесь добиться того, чтобы под вашу ответственность был выделен какой-то участок проекта, и вы могли в рамках него принимать решения сами. Пойти к начальнику спросить «что делать» - это проще, но это будет означать, что решение примет он. А вам надо учиться делать это самостоятельно.
На этом пока все :) Если у вас есть комментарии или вопросы к написанному - буду рад обсудить, здесь в комментариях или в чате Хекслета, можно в Твиттере.
Читайте также: Как легально получать доходы от программирования: информация для разработчиков, работающих не по найму.
