Comments 47
У вас рассуждение строится на утверждении "Дальше наступает практически потолок в технической части". Но мне оно не очевидно. Почему наступает потолок в технической части? Там точно "потолок"?
Да, там потолок. Возьмём PG, если вы уже знаете как работает SQL, хранение данных, индексы, репликация, WAL, MVCC и умеете писать расширения, то глубже вам эту БД знать не нужно, если только вы не являетесь ее разработчиком. Может я пару пунктов забыл, но список недлинный. Аналогично с любой другой технологией.
Можно в ширь пойти, изучить MSSQL таким же образом, но там, примерно, все то же самое. Изучили 2-3 БД и вы знаете их все, аналогично с UI, API и т.д.
Когда вы уперлись в этот потолок как раз начинаются интересные задачи.
- Инженерные — «нам нужна система хранения с характеристиками, отличными от всего, что есть»
- Организационно-технические — «есть 50 индусов и приложение на 10 000 формочек, сделайте архитектуру и процесс, чтобы они за 2 года все сделали»
- Дизайн систем — «у нас тут на вход данные с такими характеристиками, вот такая обработка, нужно придумать как эту обработку, хранение и показ данных организовать». Тут крайне важно знать область, иначе можно всякого напридумывать.
И так далее и тому подобное — реальная проблема и профессионал, который ее решает, понимая пространство решений, альтернативы и компромиссы.
Подчеркну — все это, по настоящему, начинается после достижения потолка в технической части. Сложно придумать хорошую систему хранения, досконально не зная парочки существующих. Печаль начинается когда «сеньоры» с 3 годами опыта работы начинают изобретать базы данных или внедрять новые архитектуры по книжкам.
У вас комментарий строится на том что вы текст не читаете.
"Так я раньше думал. Однако впоследствии оказалось, что старший разработчик может стать еще более старшим. И еще более. Как так? Есть несколько путей."
Ну вот, нормальный ответ, а то все эти статьи были похожи на попытки слепых мудрецов описать слона.
Все забыли, что он не похож на сферического коня в вакууме, что он вообще то состоит из разных частей.
А по факту грейд сеньор очень похож на мага вне категорий из дозоров. Формально то они все принадлежали одному грейду, но при этом между ними была пропасть в плане умений.
Офигенное сравнение Дозорами. Спасибо, возьму на вооружение)
насколько я помню, там не пропасть была, а просто разницу в энергии между двумя чуваками вне категорий нельзя было измерить. А вот навыки и искусность могли сильно отличаться.
Просто тогда аналогия выходит неудачной (что есть сила а что есть навыки для программиста?)
животные делятся на:
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
1) Критерий попадания в principal и вообще карьерного роста. Это *уровень влияния* на судьбу проекта, отделов фирмы, всей фирмы, целой индустрии. Уровень охвата одним человеком самого себя, своего проекта или десятков/сотен/тысяч других людей. А не способность решить самостоятельно сложную задачу или запилить очередной фреймворк или сервис. Это как раз ожидается от обычного разработчика. А вот повести за собой остальных, увидеть проблемы и поставить задачи на годы вперед, это уже другой разговор.
2) Уровень зарплат. Который обычно нехило подскакивает при нахождении в данной категории senior/principal/staff/disitinguished и так далее (можно видеть на levels.fyi). Очень мотивирует, если кому надо.
А обьяснять кому-то необходимость понимания чем живет компания, с кем и как конкурирует и интегрируется, откуда и куда идут финансовые потоки (обобщив это все одним словом «бизнес») мне кажется немного странным занятием. Если кто-то считает что меньше знаешь — крепче спишь и ему это не надо, то, видимо, просто не пришло время. Ещё можно успокоить себя историей про специализацию и концентрацию умственных усилий в одной области. Но тогда это не разговор о principal.
А не способность решить самостоятельно сложную задачу или запилить очередной фреймворк или сервис. Это как раз ожидается от обычного разработчика.
Создать с нуля фреймворк — это ожидается от обычного разработчика? Как же все вокруг изменилось...
А под "запилить очередной сервис" вы что понимаете?
Это пришло потом, когда организовал работу команды и поднял проект с нуля.
Это говорит скорее о том, что на том вашем месте работы "сеньёристость" подразумевала выполнение административных обязанностей. Т.е. развитие человека в сторону менеджмента (пусть даже и низового уровня). Тогда как в статье обозначается цепочка развития именно в техническом ключе, без необходимости брать на себя обязанности по руководству команд разработчиков.
Мне сложно понимать о чем вы говорите, т.к. вы сперва пишете одно, затем оказывается другое. Начали о том, что "запилить новый фреймворк" — это ожидается от обычного программиста. Потом выяснилось, что не "запилить", а "заиспользовать".
Потом сказали, что сами стали сеньором только "когда организовал работу команды и поднял проект с нуля." А следом пишете, что "руководство" не при чем, что нужно влияние. Хотя ваш пример именно про руководство.
Получается как в анекдоте: не сто рублей, а три рубля, не выиграл, а проиграл.
Тут может быть "организовал техническими средствами": выбрал платформу, фреймворк, архитектуру, ввёл код-стайлы и прочие рекомендуемые/запрещенные паттерны в коде, возможно настроил хуки и пайплайны, организовал процессы код-ревью и т. п. То есть никому не приказывал, но организовал разработку так, что без выполнения новых, разработанных им требований (одобренных обычно руководством и/или командой), "обычные" сеньоры не могут сдать задачу в принципе (например права для выкатки на прод оставили только для CD-агента) или в разумные сроки.
Можно поверить в то, что человек, который не считается сеньором выбирает платформу, фреймворк и архитектуру для проекта. Ну мало ли, толковый разработчик, просто лычку пока еще не получил.
Но вот в то, что человек без административного ресурса вводит код-стайлы, организует процессы код-ревью, одобряет или запрещает паттерны… Ну вот не могу, извините.
Как и в то, что можно "поднять проект" не раздавая никому живительных подсрачников (т.е. выполняя менеджерскую роль). Не, в одиночку можно. Но не когда речь идет о команде.
Здесь (США, Израиль) так обычно не работает. Начальник занимается карьерным ростом людей и направляет проект в нужную сторону. Команда «плоская» (есть разные позиции, но нет никаких иерархий, голоса всех равны, просто кто опытнее обычно приводит более убедительные аргументы) и сама делает все остальное и каждый проявляет ровно столько инициативы, сколько может и умеет. Раздавать пинки, разрешать/запрещать и трясти перед людьми «админ ресурсом» это уже очень российская реальность, с которой я плохо знаком. Хотя нет, вру, довелось однажды работать в российской конторе. То еще осталось впечатление от выстроенных там пирамид и иерархий.
одобренных обычно руководством и/или командой
Да и в США с Израилем хватает иерархических структур в разработке, даже в стартапах.
Выводить "тенденции" по максимум всего 6 точками наблюдения? Так себе идея.
Да, понятно, вы там в светлом граде на холме на острие прогресса, а мы тут лаптем щи хлебаем и блох подковываем в лучшем случае.
Руководитель может быть формальным, может быть фактическим. Менеджерские обязанности могут быть зафиксированы формально, могут быть неформально признаны командой.
Но всегда есть тот, кто принимает решения и несет ответственность. Хоть в плоской команде, хоть в вертикальной.
И суть в том, что взятие на себя этой роли и означает развитие по линии менеджера. Потому что основная забота при этом смещается с технической составляющей на социальную. Это разные навыки.
Ну а вы, возможно, просто оказывались в ситуациях, когда равных вам по опыту в команде либо не было, либо же были, но они не хотели брать на себя ответственность. Поэтому вам и удалось "организовать" не имея формально закрепленных за собой полномочий. А случись в вашей команде еще один или два таких же инициативных, энергичных, амбициозных и со своим непробиваемым мнением, вот тогда все могло бы пойти несколько не так.
Есть ещё один вариант: решение принимается совместно, голосованием, например. Но есть кто-то, кто проявил инициативу, организовал принятие этого решения. Например, я хочу внедрить единый код-стайл и линтеры для проверки его соблюдения в пайплайнах. Никаких особых полномочий нет, плоская команда или руководитель говорит что-то вроде: "это ваши технические/локальные заморочки, решайте сами". Ну и я подготовил PR, бросил его в девканал в слаке с комментарием "кому надоело спорить о скобках и пробелах на код-ревью — плюсуйте, кто против — минусуйте" и через какое-то время мержится, возможно с поправками по результатам обсуждения. Вот, организовал внедрение код-стайла. И даже без взятия ответственности.
В моем понимании это не "организовал", а "предложил" или "реализовал". А "организовал" бы тот, кто взял на себя ответственность за мержинг предложенных вами изменений. И за то, чтобы потом никто не мог это проигнорировать и выпилить.
Ну и, по-моему, не следует опускаться с уровня "организовал работу команды и поднял проект с нуля" до "я сделал PR с интеграцией автоматического запуска линтера перед коммитом". Поскольку "организовал работу" (как по мне) означает, что кто-то распределяет работу (т.е. делает декомпозицию и распределяет задачи) между членами команды, обеспечивает контроль за выполнением работы, решает оперативные вопросы и рабочие разногласия. А "поднял проект с нуля" (опять же как по мне) означает, что человек взаимодействовал с заказчиками проекта (внутренними или внешними), чуть ли не от момента возникновения самой задачи и вплоть до запуска в эксплуатацию. Т.е. брал на себя ответственность за объем работ, их очередность, сроки выполнения и т.д.
Все это несколько больше, чем "выбрать фреймворк" или согласовать набор паттернов.
Попробуйте получить Senior или Staff в западной фирме развиваясь чисто технически до уровня Бог (на чем подозреваю многие читатели фиксируются, в том числе благодаря этой статье), уверяю у вас ничего не выйдет — я знаком с критериями промо не по наслышке.
Не знаю, как насчет Staff, я такого грейда не видел, а вот Senior — легко. Не все "западные фирмы" одинаковы.
Staff встретил сам впервые в Убере. Примерно равняется Амазоновскому Principal (L7).
Там где был я 100% не прокатило бы, каким бы прокачанным чел ни был.
Какая это доля от всех "западных компаний"?
С уровня senior ожидают… голоса нескольких человек след уровня, готовых поддержать кандидатуру промо.
То есть с улицы такую позицию получить невозможно? или уже работая, или по знакомству?
Я же скорее говорил о процессе промо на senior или principal внутри фирмы. А потом и сохранении, так как review раз в год и критерии оценок работы все те же, как и на промо. Т.е чтобы однажды получить и удержать, придется регулярно показывать свое соответствие должности.
Техническое совершенство, конечно, ожидается, но во главу угла ставится прежде всего impact.
Такое ощущение, что у вас движение по цепочке junoir -> middle -> senior ассоциируется с качеством кода. Мол, пока пишет плохой код, то junior, как только код стал удобоваримым, повысили до middle, а вот когда уже начал писать отличный код, вот тогда уже senior.
Уж не знаю, как там в "западных фирмах", может быть и так.
Но вот в окружающей меня реальности разница между junior, middle и senior определяется вовсе не качеством кода, а двумя более важными факторами:
- количеством информации и подробностью деталей при выдаче задания;
- степенью контроля за исполнителем.
Т.е. junior-у нужно все рассказать максимально подробно, да еще и снабдить ссылками на необходимые ресурсы. А потом еще и тщательно контролировать.
Тогда как middle можно ставить менее подробные задачи и контролировать можно разве что конечный результат (ну или на важных промежуточных шагах).
А вот senior-у уже задание ставится в максимально общей форме, а результат не контролируется (помимо прогона тестов, успешного прохождения интеграционных тестов и пр. рутины).
И вот как раз с senior-ом зачастую говорят на языке бизнеса или около того. Мол, нам нужно повысить надежность сервиса или снизить время отклика. Оставляя senior-у на откуп поиск технического решения. А то и отдавая всю реализацию по его ответственность (особенно если это не требует координации работы нескольких команд).
Тогда как с middle и junior-ом разговор ведется на техническом языке. Типа сделать фичу такую-то в такой-то версии такого-то продукта. А для junior-а еще и: сделать фичу так-то и так-то.
Про качество кода я вроде ни разу не упоминал и как раз наоборот, подчеркнул что на одном коде и технических скилах далеко не уехать. По крайней мере в тех местах где работал я.
И я вижу тут уже не первый раз всплывает тема «под чью ответственность». Мне это напоминает поиск виноватых в случае не совсем верных решений. Отвечает не один человек, который предложил какой-то дизайн, а вся команда. Потому что проект это командное усилие, а не личная территория контроля одного человека. Кто-то предлагает решение, команда обсудила, одобрили/доработали и поехали. А попытка навешивать всю ответственность на одного человека опять же напоминает мне вертикаль власти. А также снимает всю ответственность со всех остальных игроков, что губительно. Да, за дизайном обычно стоит driver, который его толкает вперед вместе со всеми (и которому потом учтут все его инициативы на perf review), но это не то же самое что теперь это «его ответственность».
Статья про взаимоотношения между разработчиком и бизнесом. Уровни носят вторичный характер, но немаловажный. Первичное в статье — кто такой разработчик и за что он может отвечать.
Ну вот был я как-то старшим инженером-программистом, по факту выполняя обязанности CTO, техдиректора. Отвечал за всю технику в компании, даже за пылесосы и чайники, обладал юридическим правом подписи некоторых договоров (по доверенности) и утверждения оплаты некоторых счетов. Участвовал в практически всех совещаниях топов на равных с ними. В теории мог загнать фирму под банкротство или вывести заметную кучу денег на прокладки или просто за откаты закупать необходимые товары, услуги, лицензии по повышенной цене, имея доход в разы больший зарплаты и премий.
Но если спросить меня кем работаешь, то отвечал программистом не кривя душой. Приходилось этим заниматься просто, чтобы иметь возможность программировать в той области которая мне тогда была интересна, как можно дольше, не допуская потери интереса учредителей к компании, чтоб она приносила им денег хотя бы больше депозита. Часть, договора, счета и т. п. этих неформальных обязанностей взял на себя сам сначала де-факто, а потом, задолбав всех "вот тут подпиши", легко выбил себе и формальные полномочия, часть, типа пылесосов и чайников, была навязана по принципу "тыж программист и доверенность на технику у тебя есть".
Это я к чему — разработчик может отвечать за всё, за что он согласен отвечать. Ну, почти, не нарушая закона и подзаконных актов регулятора. В некоторых компаниях не дают разработчику отвечать за то, за что он хочет отвечать, в некоторых дают, но не считают нужным платить дополнительно в какой-либо форме, в третьих ещё и доплачивают, в четвёртых навязывают "если хочешь отвечать за это, то отвечай ещё и за то". Компаний много, и если задаться целью найти оптимальную для себя, то можно найти. Даже такую, где почти ни за что отвечать надо.
от senior как раз ожидают координацию и влияние на несколько команд
Могли бы вы привести примеры того, что вы называете "координацией"?
Про качество кода я вроде ни разу не упоминал и как раз наоборот, подчеркнул что на одном коде и технических скилах далеко не уехать.
Я процитировал фрагмент вашего высказывания. Видимо, нужно еще раз повторить:
Техническое совершенство, конечно, ожидается, но во главу угла ставится прежде всего impact.
В этой вашей фразе "техническое совершенство" воспринимается именно как качество производимого кода. Откуда и появляется предположение о том, что в вашем представлении senior — это уже тот, кто пишет качественный код. Но не только.
На что я вам и указал, что в цепочке развития junior -> middle -> senior качество кода вообще не главное. Соответственно, если до senior-а качество кода не главное, то и дальше оно главным не будет.
Мне это напоминает поиск виноватых в случае не совсем верных решений.
Это не напоминает, это оно и есть. "Ответственность" — это значит ответ за принятые (и не принятые) решения, за сделанное и не сделанное.
Нести ответственность — это значит отвечать за факапы, за невыполнение договоренностей и взятых на себя обязательств. Значит принимать решения в сложных ситуациях. И т.д., и т.п.
Отвечает не один человек, который предложил какой-то дизайн, а вся команда.
Это как? Просрали сроки, не обеспечили качество, вышли за рамки бюджета и вся команда отправляется на мороз?
Даже если в команде 30 человек, а пятеро из них junior-ы, которые делают только то, что им скажут, и никакого влияния ни на архитектуру, ни на выбранные инструменты, ни на принятые технические решения, не оказывают. Так что ли?
Ну и мне интересно: вот у вас в команде не только вы умеете правильные слова говорить, но и еще один-два человека. С правильными словами, с уверенностью в своей правоте, с желанием добиваться своего, с амбициями расти дальше, для чего нужны результаты. И вот вы предлагаете решение X, второй такой же решение Y, а третий — решение Z. Все решения более-менее одинаковы, при должных усилиях каждое из них приведет к работающему результату. Выбор, фактически превращается в дело вкуса и личных предпочтений.
Вы голосованием будете делать выбор из этих вариантов?
В теории и junior мржет написать свой фреймворк. Тут вопрос скорее в том, каждый ли сможет и какого качества результат получится. Чем выше квалификация программиста, чем больше опыт и кругозор, тем больше вероятность, что из этой затеи выйдет что-то путное.
Что до знания "как он работает изнутри", то что-то я сомневаюсь, что поголовно все пользователи каких-нибудь Spring, Hibernate, Akka, Orleans, Qt и пр. имеют такие знания. Или даже имеют достаточную квалификацию, чтобы при необходимости заглянуть вовнутрь и разобраться с каким-нибудь частным вопросом.
Поддерживаю коллег выше — отличная статья!
Капитанская статья
Точнее, в Y-модели разделение на технический и менеджерский трек начинается после senior.
В статье приведены позиции технического трека, названия специфичны для компаний, насколько я знаю.
И опять же верно, нужен человек, который способен понять потребности бизнеса и предложить сбалансированное техническое решение. В некоторых компаниях такого человека называют архитектором, иногда это роль, иногда это должность, но это senior+ (если бюджет компании позволяет).
Архитектура — это система компромиссов (уж не помню, где встречал это определение).
согласен
Программист должен решать