Сложно сравнивать таланты из компаний разного размера, но некоторые вещи важны

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

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

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

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

Больше, чем просто знания

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

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

Этот глубокий опыт также помогает понять, как выбор, сделанный на ранней стадии разработки, окупается позже. Старшему разработчику необходимо знать, «где захоронены тела». Время, потраченное на глубокий конец, поддается интуитивному знанию того, где могут возникнуть проблемы, на 10 ступенях ниже. И эта мудрость удивительно применима к другим ситуациям; как минимум, старшие разработчики могут осознавать, когда они не знают всех скрытых потенциальных опасностей, и действовать осторожно.

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

Делать сложные вызовы и жить с ними

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

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

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

Открытость и извлечение пользы

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

Чем более человек открыт для познания и понимания, тем быстрее он станет «старшим» по любому определению.

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

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

Появятся «старшие» качества

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

  • Младшие разработчики знают один способ решения проблемы, обычно основанный на учебных пособиях или на том, что они делали в школе. Он почти наверняка использует какой-нибудь модный фреймворк.
  • Разработчики среднего уровня понимают, что каждая проблема существует как часть более крупной системы, и беспокоятся о ремонтопригодности, качестве кода и т. Д., Но все же не видят общей картины. Они склонны больше зацикливаться на процессе.
  • Старшие разработчики понимают, что нет ничего без возможных проблем, недостатков и рисков. Их выбор заключается не в том, что круто или «правильно» согласно какой-либо книге, а в том, чтобы сделать выбор в пользу целостного управления рисками для всей команды. Их волнует, что будет легко поддерживать, легко обучать и легко отлаживать.

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

Какой у вас опыт? Когда вы почувствовали, что готовы к «старшей» мантии?