Comments 34
Но настоящий senior-разработчик понимает, что существуют физические серверы, на которых установлена операционная система, предоставляющая различные интерфейсы пользователям и приложениям по определенным протоколам. Если возникает проблема, он спокойно переходит на уровень операционной системы или даже оборудования, чтобы эффективнее решить задачу.
Как художник художнику. На простых требованиях к железу под нагрузкой посыпятся почти все начальники ИТ отделов. По софту попроще, посыпется меньше. Мне кажется, что нет ни одного senior-a, который "легко" выйдет на этот уровень. Особенно если информация проприетарная, и доступна узкому кругу лиц. Без обид :).
Ну... мне в начале карьеры приходилось решать проблемы уровня "индекс-сервис работает нормально в dev-environment, но падает на проде из-за недостатка памяти". Как оказалось, приложение прорекламировали, трафик возрос многократно и памяти VM-ки перестало хватать. Ничего, разобрался, хотя несколько дней на это ушло. Сейчас - решаю проблемы от "ускорить загрузку фронт-энда" до "настроить Message Queue между микросервисами в Azure". И всё это на должности Senior Developer, вернее - контрактник, работающий на уровне Senior.
от "ускорить загрузку фронт-энда" до "настроить Message Queue между микросервисами в Azure"
Но это ведь совсем другие задачи, одно дело - что-то ускорять и оптимизировать в существующем проекте, и совсем другое - выбрать железо для старта с полного нуля.
Мне, например, до сих пор непонятно - как этому вообще можно научиться, не запустив ну хотя бы с десяток высоконагруженных проектов. А человеку без опыта никто не даст их запускать, и круг замыкается.
Мне, например, до сих пор непонятно - как этому вообще можно научиться, не запустив ну хотя бы с десяток высоконагруженных проектов. А человеку без опыта никто не даст их запускать, и круг замыкается.
Не обязательно новое запускать, это больше про нагрузочное тестирование. Характерные паттерны потребления железа разными видами систем как раз можно таким образом изучить, и дальше, когда надо будет планировать что-то новое, у вас уже будут в голове цифры, от которых можно отталкиваться.
Это так не работает. Тестирование и продакшен это разные миры. Особенно когда идет речь про проектирование таких систем и их эксплуатацию.
Как вы определяете реальные потребности конкретного софта в железе, если не через нагрузочное тестирование? Скажем, вам надо развернуть объектный сторадж на Ceph/Minio, или L7 балансировщик нагрузки (он же API GW) - как вы будете выбирать, сколько под это надо "железа"?
С профилировкой и оптимизациями уже запущенного понятно, там правда начинать придётся с продакшен нагрузки, потому что надо ещё придумать, как (и получится ли) повторить синтетикой.
Конечно нет. Скорее эмпирически. Софт в нужных местах готов масштабироваться в известных пределах, в ненужных может и не готов. Главное их верно отличить друг от друга.
Нагрузка всегда растет постепенно. Время на понять что что-то пошло не так, залить железом это место и спокойно починить всегда есть.
Вы когда сдадите сертификационные экзамены на инженера по любому железячному вендору - вы все это будете уметь делать. Там именно этому и учат. На железе этого вендора само собой. На остальных вендорах - по подобию. Поэтому любой "специалист" отвечающий за железо, но не имеющий такого сертификата - это некомпетентные решения.
Вы сейчас серьезно? Т.е. ИТ отдел не сделал нотификации в почту, если память на ВМ больше 75%? Это задача уровня начального-среднего сисадмина. Остановите планету, я сойду :). Можно ещё какие нибудь примеры из вашей практики? Мне чисто для расширения кругозора падения компетентности. Я сейчас не шучу, абсолютно серьезно.
Вы не представляете, сколько бардака в больших корпорациях и больших проектах. Тот проект был частью большого журнала Chatelaine, принадлежащего корпорации Rogers и представлял из себя древний легаси-код, к которому я два года писал обновления. Собственно, это был мой первый опыт работы по контракту, и мне понравилось настолько, что с тех пор я уже семнадцать лет как контрактник.
Чтоб вы понимали масштаб трагедии - чтобы делать deploy в продакшен, мне пришлось самостоятельно УГАДАТЬ пароль от продакшен-сервера, потому что мне его знать не полагалось, а ответственных за этот сервер уже давно уволили. К счастью, пароль оказался одинаковым с паролем от дев-машины, созданной, видимо, в одно время. Никакого CI/CD там не было (справедливости ради, это понятие в те времена еще только начиналось), поэтому деплой я делал путем копи-пейста скомпилированных библиотек и форм фронт-энда. Начальство об этом моем самоуправстве узнало только когда ему самому зачем-то понадобилось влезть на этот сервер, я ввел пароль и услышал "а откуда ты его знаешь???". И да, я уже упомянул, что никакого отдела QA или DevOps на проекте не было в принципе?
Сервис индексации базы данных крутился на той же машине, в отдельном сервере Apache Tomcat. База была довольно приличная (сотни тысяч кулинарных рецептов, ингридиентов, оценок и комментариев), а машина, как вы поняли, была создана за много лет до того, как я пришел на проект. И, как я понял, это приложение с рецептами лежало там много лет, до того момента, как о нем вспомнили, "причесали", прорекламировали для пользователей, и... сервер не выдержал нагрузки и лег.
Бардак лечится служебными записками. С любого положения в иерархии ИТ. Проверено на государственных и на коммерческих структурах. Было бы желание.
Я простой контрактник, получаю оплату за рабочие часы, никакого карьерного роста в корпорации мне в принципе не грозит. Моя задача - прийти, поскорее врубиться в проект и спокойно выдавать на-гора требуемый от меня код. Ваш бардак - ваши проблемы, меня это не интересует, самое большее - оповещу о потенциальной проблеме своего непосредственного менеджера.
Вспоминается случай еще в одной почти-госкомпании (колледже для сертификации неких специалистов), как раз перед пандемией. Обычный проект: пользователь заходит в "личный кабинет" и может делать там какие-то действия, в том числе - сгенерировать и скачать свой инвойс в PDF. Для скачивания предоставляется ссылка с идентификатором инвойса, идентификатор - не случайный GUID, а обычное число.
Господа знатоки, внимание - вопрос: если увеличить это число на единицу - чей инвойс вы скачаете? В общем, вы поняли - любой инвойс мог быть запрошен без какой-либо аутентификации, тупо по его порядковому номеру в базе. Слегка эмм... удивившись, я показал этот фокус коллеге - русскоязычной девушке из Армении, кстати - и задал вполне логичный вопрос: где этот код и кто за него отвечает? Оказалось, что этот кусок сделан какой-то сторонней компанией, к нашей команде не имеет никакого отношения, где код она понятия не имеет, но скажет своему менеджеру, чтобы тот посмотрел.
Через пару недель началась пандемия, нас сначала поотправляли по домам, а еще через три месяца мой контракт разорвали за ненадобностью, с чем я даже согласен - задач для меня там почти не было, я тупо сидел дома и ничего не делал. Спустя год я случайно вспомнил про этот баг, залез в то приложение через сервисный аккаунт - баг был все еще на месте, любой инвойс можно было скачать просто изменив id в URLе.
С позиции человека 25 лет в индустрии, опытом в куче иностранных конторах первого эшелона и руководством разработкой массой завершенных проектов.....синьерный разработчик 1. Нормальное образование. Корки ВУЗа не обязательны, но человек должен понимать как родить что то новое, а не только нагуглить или нейронку спросить...без нормального образования и-или базовой фундаментальной мат подготовки это малореально (противоположного я не видел) 2. Хорошее знание базиса и насмотренность в техничке, за пределами своего домена. 3. Креативность 4. Хороший софт скил 5. Постоянное самообразование и самосовершенствование... отличное знание того или иного языка или технологии НЕ является признаком синьерности, ибо имея базу в пунктах 1-4, и умением прогать на плюсах или питоше, освоить го, например, на уровне прохождения собеса технического в FAANG (а я там работал и людей обесил) у вас проблем не будет. Я лично проходил собес и принял офер в один из FAANG, где работал в проект на го, не зная го вообще - кодинг интервью было на плюсах, алгоритмы на питоне, как работает го под капотом я объяснил довольно подробно - потаму что если знаешь как работает ось и знаешь внутрянку плюсов.....го рутины асинхронщина и тд работает по тем же принципам....потом го я освоил за месяц.
Есть многократно проверенная теория про 10 тысяч часов. Будь ты хоть супер гений, но для достижения планки "синьора" или "мастера" в любой профессии эти 10к часов (5-7 лет фултайма) надо отпахать. Хоть инженером, хоть хирургом, хоть музыкантом - но примерно так. Обратных примеров известно очень мало.
Разумеется, это необходимое условие, но не достаточное. Можно быть идиотом не на своём месте, можно гонять чаи и т.д.
Так что рассказы про сеньоров за 2 года оставьте рекламе курсов "С++ за 21 день".
Стаж задает минимальную планку. До 5 лет поучаствовать в достаточном количестве проектов чтобы стать сеньором просто невозможно. 7-10 лет это более реальный срок.
Я бы еще добавил опыт долгосрочной поддержки продукта - одно дело написать софт, сдать в эксплуатацию и забыть. И другое - поддерживать и дорабатывать все это дело, не скатываясь в говнокод.
Если достаточный, желательный, но не необходимый критерий: способность написать код на каждом из следующих языков: SQL, LISP, C/C++/Rust, Java/.NET/F#, JS/TS, Haskell/Idris, Erlang. Это покрывает почти все известные нам парадигмы, а значит — говорит о наличии кругозора.
К сожалению, если хотя бы с одним из вышеперчисленных языков — проблема, скорее всего, лакуна в кругозоре — когда человек столкнется с задачей, лучше всего решаемой именно в этой парадигме, — приведет к построению велосипеда.
Это покрывает почти все известные нам парадигмы, а значит — говорит о наличии кругозора.
Это Вы как-то низвели этого самого синьера даже не до ремесленника(пусть и очень натасканного), а до какого-то, прости господи, "синьер девелопер ИИ-агента".
"Вот тебе, электронная макака, множество всех модных палок-копалок. Твоя задача угадать самую подходящую, и копать ей от забора до обеда."
Я конечно "не настоящий сварщик", но достаточным этот критерий я бы не назвал.
Недостает того, что в статье описано в разделе Бесстрашие перед неизвестностью, а я бы назвал "наличие (естественного) интеллекта".
по-моему, это всё укладывается в один тезис: старший разработчик решает проблемы. Иногда даже с помощью компьютера. Средний разработчик умеет хорошо программировать.
Умение писать работающий код - это необходимый навык для любого программиста. Однако, это навыки которые являются решающими на этапе джуниор и мидл разработчика. Когда мы говорим про senior, то уже подразумевается, что человек в него может хорошо, и его проверка по большому счета даже не требуется.
У меня тут был забавный диалог, с человеком из мира Java. Который удивлялся моим рассказам, о том, что в go никто не пишет unit-test'ы.
Большинство навыков, которые должны формироваться на этапа джуниора, отсутствуют у людей являющихся сеньор или принципиал инженерами в бигтехе, не говоря уж о тимлидах и техлидах.
Да, они умеют писать работающий код. В определенных ситуациях. И абсолютно не поддерживаемый, примитивный и многословный - просто посади людей в мир "без фреймворков" и оказывается, что у них нулевые навыки в организации, рефакторинге, структурировании, стандартизации, минимизации сложности.
Хочу отметить, что исключения бывают, но они редки. По моей оценке менее 10% команд и компаний смогли бы пройти мои стандарты качества и требований. А они ведь ещё и не очень высоки.
Моё изучение опенсорсных репозиториев на Rust и Go, в целом соответствует ожиданию - там качество исполнения - ещё ниже. И бигтех скорее роняет планку, чем держит её.
просто посади людей в мир "без фреймворков" - зачем? Что за мир такой? Вы любите олимпиадное программирование?
Я работал в 4 иностранных бигтехах из первой 20ти мировой и в паре наших, если их конечно можно наззвать бигтехами, с культурой производства софта +- норм. Но я делал контракты по консалтингу в несколько небольших компаний, до 1000 человек....вот там действительно было все ооочень печально
Если совсем коротко, то синьор - это спец, не захотевший в тим-лиды потому что лень, и не захотевший в архитекторы, потому что по прежнему любит кодить.
Синьор - тот, кто сможет пройти на вакансию синьора и работать на ней долгое число времени за сеньорскую ЗП, т.е умеет решать задачи бизнеса на таком уровне, который бизнес считает "синьорским". Все остальные определения являются субъективными выдумками гейткиперов, которые у каждого свои
Критерии для Senior Developer'а