Я только начал работать в Andela в новой должности старшего инженера-программиста, и должен признать, что до сих пор это была одна из моих лучших поездок. В Andela наша миссия состоит в том, чтобы воспитать новое поколение технологических лидеров, вооружив их не только техническими навыками разработки программного обеспечения, но также социальными, лидерскими и предпринимательскими навыками, и представив их миру, работая с ведущими компаниями, помогая им. для создания продуктов мирового класса.
Один из первых вопросов, который мне задали, когда я присоединился, был: «В чем разница между старшим и младшим / средним инженером?» Я был очень ошеломлен, так как я никогда особо не задумывался об этом, и у меня не было прямого ответа (что хорошо), но это заставило меня много задуматься в следующие пару дней и побудило меня написать свой самый первый блог пост по этой теме.
Сначала я хотел перечислить моменты, то есть, по моему мнению, и что касается моего опыта, которые я бы определил как качества, которые я бы использовал, чтобы судить человека как «старшего инженера». Обратите внимание, что фраза заключена в кавычки, причина в том, что мне не нравится думать о ней в терминах иерархической структуры, и я хотел бы пояснить последнее, что это не черно-белая категоризация с четкими границами. относительно того, где один останавливается и где начинается другой. Однако я предпочитаю думать об этом как о зарождающемся и возникающем, с разницей в качестве роста и развития. Говоря «старший», я больше сосредотачиваюсь на уровне зрелости и «опытности», если я могу использовать это слово.
В части первой этого поста я бы начал с рассмотрения общих определений, которые многие считают характерными для кого-то, кто является «старшим» в том, что касается разработки и проектирования программного обеспечения.
У меня чуть более трех лет профессионального опыта в разработке программного обеспечения, так что извините, если моя точка зрения поверхностна по сравнению с инженером, проработавшим более 40 лет. Не стесняйтесь критиковать мои замечания в разделе комментариев. Цель этой роли - поделиться и собрать мнения, которые заставят всех нас расти.
Итак, хватит кругозора, какие факторы НЕ характеризуют старшего инженера?
«Старший» инженер / разработчик не зависит от количества времени, когда он пишет код / разрабатывает системы. Прежде чем убить меня, обратите внимание, что я не говорил, что время не способствует зрелости в разработке программного обеспечения, я имею в виду, что это не определяющий фактор. Я собираюсь привести два тематических исследования, чтобы показать, почему я так считаю.
- Пример A. Спустя 1,5 года моей карьеры разработчика я работал в компании A, у которой были отличные технологии и отличная команда, которая создавала корпоративные продукты для цепочки поставок. Что-то интересное произошло, когда все старшие инженеры ушли из компании, а нас осталось несколько «новичков». Мы должны были вскочить вглубь продуктов и довести дело до конца. Мы работали почти день и ночь, пытаясь достичь того же темпа, теперь, когда остался большой разрыв. Одна вещь, которая действительно сработала для нас, - это совместная работа со старшим консультантом, который помог нам понять так много, что касается дизайна и архитектуры разработки программного обеспечения, помимо простого написания кода. Спустя пару месяцев наша динамика была действительно высокой, мы могли приступить к работе над «основными» частями приложения с разумной степенью уверенности в том, что мы делаем. Это ускорение было основано не на времени, а на наличии правильного контекста и среды для развития.
- Пример B: поработав какое-то время, давление продолжало расти, и мы почувствовали, что нам нужно привлечь в команду старших инженеров. Мы искали людей и обратились к большому количеству людей. Одна из вещей, которая меня удивила, заключалась в том, что у некоторых людей был 10-летний опыт работы, но им не хватало понимания фундаментальных принципов разработки программного обеспечения и лучших практик разработки программного обеспечения, таких как контроль версий, разработка через тестирование и общие структуры и шаблоны, например MVC и MVVM. Это было очень важно для наших процессов разработки программного обеспечения, и попытка заставить кого-то вписаться в команду была довольно утомительной. При дальнейших раскопках (я бы не стал судить людей, здесь, в Andela, есть одна мантра: Блеск распределяется равномерно; возможности нет », и чаще всего возможность - это не то, что находится под прямым контролем), я обнаружил эти люди работали в отрасли, которая не так быстро развивается, например в банковском или страховом секторе по таким причинам, как регулирование и т. д., и поэтому они могут не иметь такой широты воздействия, чтобы не отставать от темпов развития технологий. Хотя можно утверждать, что они старшие в своих отраслях, что является веским аргументом, но я прошу не согласиться, как я покажу в следующем пункте. Таким образом, контекст и воздействие играют очень важную роль в определении уровня навыков и опыта, а также степени их зрелости. Слава Богу за Интернет, который уравнял игровое поле, я могу иметь такой же уровень доступа к новым концепциям в мире программной инженерии, как кто-то глубоко в сердце кремниевой долины.
Старший инженер не основан на знании определенного технологического стека или языка программирования для этой материи. Если кто-то разработал интерфейс, он поймет, что значит усталость от javascript. Я вспомнил одно из первых приложений, которое я построил с нуля, это система микрофинансирования, которая позволяла принимать депозиты и выдавать ссуды для микрофинансовой организации. Я был не единственным членом команды, так что пока не стоит отдавать мне должное. Это проект, которым я больше всего горжусь на сегодняшний день, поскольку он укрепил мои навыки и помог мне расти в геометрической прогрессии. Я создал интерфейс, используя смесь razor, который представляет собой .nets view и движок шаблонов, для простых грубых операций, и angular 1, для более сложных пользовательских интерфейсов, таких как расчет ссуд и проверка причитающихся платежей при внесении депозиты. Примерно через год появился angular 2. Мне понравился angular 1 из-за его простоты, но еще больше за его мощь под капотом (кто-то может кричать директивы!) Однако я не был таким большим поклонником angular 2, так как это было резкое изменение с 1 и накладные расходы для меня было слишком много. Пожалуйста, не судите, когда я работал с машинописным текстом, я теперь считаю самоубийством создавать сложную интерфейсную систему без него, особенно если база кода большая. На этом я ушел из проекта. Когда я начал работать в своей новой компании, vuejs был одним из самых распространенных фреймворков. Я был довольно зеленым, потому что, кроме чтения в Интернете, я толком с этим не работал. Тем не менее, было очень легко стать продуктивным в кратчайшие сроки, поскольку я мог иметь отношение ко многим концепциям, таким как дизайн на основе компонентов и тому подобное.
Основной принцип заключается в том, что если вы понимаете основы программирования, стеки становятся несущественными. То, на чем вы сосредотачиваетесь, - это правильный инструмент для работы, и точка. На моей предыдущей работе я был специалистом по стеку asp.net, но теперь я работаю с таким большим количеством javascript. Дело в том, что, хотя стеки и языки могут меняться по-разному, основы разработки программного обеспечения всегда останутся неизменными, и именно на этом вам следует сосредоточить свои усилия.
Пару месяцев назад я начал изучать и разрабатывать, используя F #, функциональную парадигму для .net, и Elm для javascript. К моему удивлению, я обнаружил, что так много новых функций C #, таких как TPL и кортежи, были встроены в F # с самого начала, и что существует так много концепций программирования, которые можно заимствовать из разных языков, например, как C # представил LINQ. Следовательно, цель того, кто хочет быть «старшим» инженером-программистом, должна быть больше связана с основами, а не с такими вещами, как стек и языки программирования.
