11 июня

Программист VS Инженер

Учебный процесс в ITУправление персоналом
Привет, Хабр. Я достаточно давно наблюдаю за ИТ рынком, но никогда ничего не писал. Это первая часть моей первой пасты, а посему прошу сильно не хейтить.

Таков путь


В своих статьях я хочу поделиться опытом поиска, обучения и интеграции интернов или джунов в продуктовую команду (не путать с фриланс-командами или типа того).

В первую очередь, нужно понимать, что всё написанное ниже сугубо моё личное, субъективное мнение. Оно основано на многолетних наблюдениях и опыте, в частности, опыте и наблюдениях последних пяти лет. Разумеется, не претендую на исключительность и не утверждаю, что оно является истиной в последней инстанции.

image

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

Рассмотрим два базовых варианта:

Программист


Программист-колхозник

На самом деле, разницы между рядовым программистом нашего времени (вы ведь тоже видите эти бессовестно врущие рекламы «стань Java разработчиком за 3 месяца!»?) и аккаунт-менеджером Светой — не так уж и много. Разумеется, я не говорю обо всех-всех аккаунт-менеджерах или обо всех программистах. Я беру основную «массу», которая, судя по всему, будет хейтить этот пост (первая версия была намного жёстче). Поехали.

Программист — просто исполнитель


Для большинства в наше время программирование стало просто работой. Да, самой, что ни на есть, простой работой, что, впрочем, и неудивительно; и объявления про курсы «Java за 3 месяца» тому прямое доказательство.

Программист может писать, а может не писать.

Он будет делать ваши фичи, задавать минимум вопросов, или напротив, максимум (про таких я расскажу в следующей части).

Программист редко задумывается о трендах, новшествах. Он пишет так, как рекомендуют топы (зачастую) или как советуют топовые дев-блоггеры. Я, к примеру, совсем не понимаю, почему у Facebook столь отвратная, нелогичная и запутанная организация фронта, и почему это модно. Вот, хоть карму мне уроните, но не понимаю.

Программистом может стать каждый!


К сожалению, это горькие реалии нашего времени.

С одной стороны, это круто! Прогресс не стоит на месте, человечество развивается. А с другой (девочки из HR агенств меня поймут), рынок перенасыщен некомпетентными или низкоквалифицированными кадрами!

Да, он в принципе перенасыщен, ценники стали выравниваться. Безумных вакансий, где компании ищут джунов за ₽100к, не осталось. По крайней мере, я таких давно не наблюдаю. Лиды всё чаще стоят до ₽250к, ну и т.д.

Найти программиста просто


Это действительно так, но, нужен ли вам «такой программист»? Сейчас если взять среднестатистического frontend разработчика, он безусловно пройдёт собеседование, так как каналы типа WebDev публикуют вопросы с собесов разных компаний и, разумеется, ответы на них, а на ютьюбе шарят гайды по всяким штукам типа замыканий, промисов, коллбеков и прочих «нужных» штук.

На выходе мы получим фронтендера, который за месяц научился всему тому, чему обычно учат на курсах до полугода, а что на самом деле?

На самом деле получается картина маслом: разраб не понимает базовых принципов веб-разработки (DOM, CSS Flow Layout, HTML 5 API, es6+, immutability, etc), он делает так «как показывали в том видосике». Или делает по принципу «я вам тут по доке писал…норм же?»

Кому нужен программист?


Безусловно, такие кадры тоже имеют определённую ценность.

Кому они могут быть полезны в первую очередь?

  • Большим компаниям, где все процессы отлажены, а стек устаканен; как пример: mail.ru, yandex, rambler, Сбертех
  • Командам, которые работают «на поток», стек обычно используют тот, что скажет клиент, или максимум какие-то бойлеры+стеройды (rca+bootstrap/materialui+redux/mobx+fetch/axios)
  • Гос. конторы, там программист может спокойно расти или просто «отрабатывать» ставку, так как обычно в «госах» всё течёт довольно медленно из-за высокой бюрократии в процессах

Инженер


Инженер за работой

Как правило, бóльшую часть жизни посвящают саморазвитию и учению.

Глубокий анализ


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

Ему не нужно ТЗ, так как знает, что это бесполезная трата времени, а декомпозицию и постановку тасок проще проводить непосредственно знакомясь с требованиями по входу в проект.

Сперва анализ требований, потом проектирование, уже в конце разработка. Да, именно так и в таком порядке. По большому счёту, соотношение потраченного времени распределяется подобным образом: 40/40/20, ну, само собой ±.

Применение мощных практик


Применение сложных практик тоже является ключевой фишкой, ведь если спросить рядового разработчика, что он знает про *DD, с бóльшей долей вероятности дать внятного ответа он не сможет, с инженерами иначе. Код зачастую пишется через TDD, планирование флоу работы над продуктом из клиента посредством набора практик из BDD, проектирование продукта через DDD.

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

Кому нужен инженер?


  • Опять же — большие компании, которые в поисках лидов или архитекторов на перспективу
  • Международные компании с офисами в РФ, разрабов они обычно берут на всякие рутинные задачи, а инженеров на более сложные задачи с перспективой роста до лида, архитектора
  • Закрытые продуктовые команды, там они просто собираются в небольшие группы и решают чего и куда, и программисты там мало что сделают

И что теперь?


House M.D. - And so what?

В следующей части мы рассмотрим несколько вариантов привлечения людей в вашу команду, в зависимости от вашего выбора (программист или инженер). Рассмотрим весь процесс поиска. Варианты автоматизации процесса. Что делать если откликов очень мало или наоборот очень много. А самое главное — каким должно быть эффективное тестовое задание для ваших будущих товарищей по клавиатуре.
Теги:обучениеобучение программированиюweb-разработкаджуниорджуниор-разработчиккомандообразование
Хабы: Учебный процесс в IT Управление персоналом
+1
13,6k 26
Комментарии 40
Лучшие публикации за сутки

Партнерские материалы

Разместить