26 added
1 removed
Original
2026-01-01
Modified
2026-02-26
1
-
error code: 502
1
+
<p>В мире существует множество классификаций программистов - простые и сложные, фокусирующиеся на какой-то одной стороне деятельности (например, на технических навыках) или комплексные. Ни в коей мере не умаляя их значения, хочу предложить вам свой вариант, который рассматривает программистов с точки зрения их ценности для бизнеса:</p>
2
+
<ul><li>junior - знает, что есть;</li>
3
+
<li>middle - знает, что можно;</li>
4
+
<li>senior - знает, что нужно.</li>
5
+
</ul><p>Расшифровка на примере ситуации - когда вы сказали программисту что нужно сделать:</p>
6
+
<ul><li><p>junior - возьмется делать, по ходу будет задавать вопросы, как это сделать, и если ему внятно объяснять как нужно - сделает;</p>
7
+
</li>
8
+
<li><p>middle - поисследует и предложит варианты, как это можно сделать, возможно порекомендует оптимальные, получив ваше одобрение - сделает;</p>
9
+
</li>
10
+
<li><p>senior - спросит - а зачем это делать, чего вы хотите добиться? Вы расскажете ему о своих целях. Он исследует вопрос, потом возможно поправит вас, скажет, что вот этого хотеть не надо, а вот другого - надо, приведет аргументы. Когда согласие насчет целей достигнуто, он найдет что и как для этих целей лучше сделать (вполне может оказаться, что это будет совсем не то, что вы предлагали изначально), и сделает в оптимальном виде.</p>
11
+
</li>
12
+
</ul><p>По моим наблюдениям, помимо ценности для бизнеса эта классификация отражает естественный рост программиста в профессии. Junior начинает с изучения основ программирования - языки, фреймворки, алгоритмы, и т.д. Поэтому он в основном сфокусирован на уровне "как сделать". Middle уже достаточно уверенно владеет языками и фреймворками, поэтому он переходит к следующему уровню - "что сделать". Он расширяет свой кругозор, интересуется альтернативными вариантами решений, интересуется архитектурными подходами, начинает сравнивать разные подходы и формировать свои оценки для них. Senior уже обладает достаточно широким кругозором, и имеет за плечами серьезный опыт. Он чувствует в себе достаточно уверенности для того, чтобы самостоятельно найти подход практически к любой задаче. В то же время, он уже повидал в своей практике последствия плохих управленческих решений, когда люди выбирали неправильные пути для достижения своих целей, или вообще затруднялись четко сформулировать свои цели, из-за чего проекты терпели неудачу. Поэтому он начинает интересоваться уровнем "зачем" и выбором оптимального направления движения проекта. Таким людям часто доверяют быть тимлидами в командах, потому что они уже работают на том уровне, когда могут влиять на курс движения проекта в целом.</p>
13
+
<blockquote><h3>Также полезно:</h3>
14
+
<p>Понимаем сленг программистов<a>мини-словарь для начинающих разработчиков</a></p>
15
+
</blockquote><p>Чем эта классификация может быть полезна для программистов? Я думаю, из нее можно почерпнуть совет - как быстрее расти в профессии. В общем случае ответ на вопрос "как быстрее расти" конечно многогранен, и вряд-ли кто-то сможет претендовать что знает золотой универсальный способ. Поэтому этот совет я приведу с такой оговоркой - мы используем это в нашей компании (<a>ivelum</a>), и, мне кажется, это работает. Я не могу обещать что это подойдет всем, но по крайней мере вы можете принять это к сведению, и возможно попробовать.</p>
16
+
<p>Итак, как быстрее расти:</p>
17
+
<ul><li><p>во-первых, старайтесь никогда не делать такой работы, смысла которой вы не понимаете. Если вам поставили очень конкретную задачу (типа, "добавить столбец в таблицу") и не объяснили как это будет использоваться - постарайтесь это узнать. Где именно будет место этой работы в общей картине проекта, для чего это нужно делать, и почему выбрано именно такое решение;</p>
18
+
</li>
19
+
<li><p>во-вторых, привыкайте к работе с неопределенностью. Если вы попадаете в ситуацию, в которой вам непонятно что делать, то не спешите сразу идти к начальнику или к заказчику с вопросом "что делать". Постарайтесь сначала найти варианты решений самостоятельно. Подумайте, в чем цели работы, какие есть варианты, какие у них плюсы и минусы. Вы все равно можете потом пойти к начальнику с вопросом "что делать", но вы уже придете к нему с готовыми вариантами решений, с их анализом, и возможно с вашей рекомендацией - давайте сделаем вот это;</p>
20
+
</li>
21
+
<li><p>в-третьих, привыкайте брать на себя ответственность. Не во всех компаниях есть для этого подходящие условия (в нашей - есть :), но постарайтесь их найти. Постарайтесь добиться того, чтобы под вашу ответственность был выделен какой-то участок проекта, и вы могли в рамках него принимать решения сами. Пойти к начальнику спросить "что делать" - это проще, но это будет означать, что решение примет он. А вам надо учиться делать это самостоятельно.</p>
22
+
</li>
23
+
</ul><p>На этом пока все :) Если у вас есть комментарии или вопросы к написанному - буду рад обсудить, здесь в комментариях или в чате Хекслета, можно в<a>Твиттере</a>.</p>
24
+
<blockquote><h3>Читайте также:</h3>
25
+
<p><a>Как легально получать доходы от программирования</a>: информация для разработчиков, работающих не по найму.</p>
26
+
</blockquote>