«В чем разница между Senior- и Middle-разработчиком?» — один из самых распространенных вопросов в IT-индустрии, на который до сих пор нет точного ответа. На градацию влияет ряд факторов, но даже несмотря на это конечный результат будет зависеть от конкретного примера. Своим мнением поделился и Senior-разработчик из GitLab Илья Климов. Его тред в Twitter оценили уже более 200 человек.
Илья Климов предупреждает, что описанная им градация — это его личное мнение. В каждой компании процесс выдачи «лычек» уникален, поэтому, призывает специалист, не стоит бояться претендовать на высокие позиции. Далее описан идеальный вариант, открывающий множество возможностей.
Senior — это автономная боевая единица
По словам Ильи, в его понимании Senior — это прежде всего автономная боевая единица, способная подобно атомной подлодке надолго уходить в свободное плавание, полагаясь только на себя, но при этом регулярно выходить на связь. Вот что, по мнению специалиста, должен уметь Senior, и что позволено не уметь Middle-разработчику:
- сеньор понимает и может правильно реализовать простейший флоу запуска проекта в техническом плане: от старта «с чистого гита» до подготовки проекта к релизу, развертывания на серверах и последующего мониторинга;
- понимает не только основную зону ответственности — код, но и то, как организованы техпроцессы сборки проекта, запуска в продакшн;
- понимает ограничения выбранной реализации. Если говорить о практическом аспекте, чаще всего это подразумевает минимальные навыки администрирования
*nix-систем; - понимает все 10 этапов DevOps-цикла и на базовом уровне владеет инструментами (Sentry, Docker, Kubernetes) для их реализации;
- если задача мидла — хорошо реализовать то, что задали, сеньор должен быть способен эффективно работать в условиях высокой неопределенности — когда задача сформулирована не полностью или сформулирована так, что ее реализация будет проблемной из-за существующих ограничений в системе;
- сеньор обладает компетенциями в смежных областях. Для фронтенда это: бэкенд, UX, безопасность (XSS, CSRF), тестирование (в том числе нагрузочное), деплой, мониторинг. Специалист должен быть способен на основании этих знаний брать инициативу по доведению до ума задачи перед ее реализацией;
- способен идентифицировать риски при старте большого проекта/задачи. Хороший мидл должен быть способен ретроспективно проанализировать ограничения своего реализованного решения, а сеньор должен быть способен сделать это без написания кода;
Сопротивление хайпу
- идентификация рисков происходит за счет понимания ограничений выбранной технологии/стека (именно поэтому важно смотреть критические доклады/статьи), личного опыта и способности. Сюда же относится способность противостоять хайпу;
- обладает навыками менторинга. По словам Ильи, он разделяет «менторинг» и «руководство». Он считает, что сеньор не обязан ставить джунам/мидлам задачи, хотя это много где практикуется, но обязан быть способен помочь коллегам с реализацией задачи, при этом соблюдая баланс помощи;
- к пункту выше также относятся навыки эффективного код-ревью, который приносит команде пользу, а не превращается в «контроль запятых»;
- признает, что ему что-то не нравится в проекте, но готов уступить, когда решение удовлетворяет требованиям проекта, несмотря на внутренний перфекционизм;
- видит «паттерны» в задачах. Речь не только о паттернах программирования в классическом понимании, а также об умении в бизнесовой задаче выделить известные куски решения и реализовать их максимально скучным способом;
- способен к рефлексии не только на уровне себя, но и на уровне команды;
- умеет идентифицировать проблемные места и предлагать их решения;
- расставляет приоритеты решения подобных мест исходя из потребностей бизнеса;
Документирует все, что движется
- хороший сеньор максимально «прозрачен», то есть ничего не держит в голове или на бумаге. На любую проблему создает тикет, даже если проблема точно не будет фикситься в ближайшее время. Описывает все известные ограничения архитектуры: в идеале там, куда человек полезет при реализации;
- документирует любую вещь, которую приходится объяснять больше двух раз;
- четко коммуницирует изменение прогнозов по задачам, имеющиеся проблемы и тому подобное;
- способен к проведению ресерча — когда решение задачи неизвестно и необходимо за время на исследование;
- противостоит бизнесу и коллегам. Конфликт бизнес/разработка — это одна из движущих сил разработки. Суть в том, что бизнесу нужно «пилить» максимальное количество фич, а разработке — обеспечивать управляемость кодовой базы.
А в чем разница между мидлом и сеньором по вашему мнению? Пишите об этом в комментариях ниже.