В последнее время случилась (и продолжает случаться) тьма публикаций про кадровый голод в айти, про переоценённость синьоров, недооценённость всех остальных, про золотые горы, скандалы, интриги и конский перекос баланса фракции "программисты". Ну, короче, вы сами всё читали и вполне себе в теме. Так вот, в сим опусе хочется вспомнить, а ктож такой синьор и что ему крайне желательно знать, чтобы синдром самозванца не накрывал и чтобы окружающие уважали и на поклон за советом приходили.
Напоминаю, всё нижеследующее - это субъективное мнение автора, родившееся в ходе личного опыта и не претендует на истину в последней инстанции... да и вообще, на истину не претендует.
Об авторе
Давайте коротенько обрисую чем автор успел позаниматься и кем побыть за свою не очень-то длинную жизнь, чтобы были более понятны некоторые нижеследующие предположения касаемо синьора.
Карьера автора начиналась, когда руби 1.8.7 маячил на горизонте, макбуки ещё не были мэйнстримом и многие продолжали сидеть на 10.5 Leopard. В те времена автор сажал китайский фанерный бензиновый планер морковкой в попытках "разработать беспилотник" для обороны нашей родины, смотрел как одногрупники пишут распознавание образов для определения и сопровождения целей зенитных установок, используя GOTO в сишных макросах и понятия не имел что такое веб. Потом за старательные издевательства над Леной Сёдерберг и их качественное документирование залетел в веб, где и остался надолго. Сходил взад-назад по карьерной лесенке от джуна до своего отдела разработки, побыл системным архитектором и тех.руководителем... а потом вернулся обратно в район software engineer.
Были и вечные холивары за кодстайл, и долгие обсуждения архитектуры с командой, и "мордобои" с руководством за ресурсы, и политические разборки с С-левелом и даже оптовая продажа чёрного дерева. К последнему, кстати, рынок до сих пор абсолютно не готов. Но это совсем другая история.
Так вот, на эргодичность не претендую, но видал всякое, был по обе стороны баррикад процесса поиска работы/работников и у меня-таки есть шо вам сказать!
Про синьора
Так вот, синьор. Это, на самом деле, очень собирательный образ. Эдакая штука с чисто-утиной типизацией, с мат.ожиданием в районе "много знает и умеет" и дисперсией, не поддающейся никакой оценке. Как минимум потому, что с одной стороны, в это понятие включается "маркетинговая" составляющая вида "служи, дурачок - получишь значок", а с другой стороны, все старательно молчат про то, что бывает после синьора. То есть дважды синьор, трижды синьор и прочие кратные ордена Сутулова. Тут, лучше всего, привести примеры реальных людей: интересный господин азиатской внешности, специалист по связям с общественностью, лид рекрутмента и теолог-богослов или барышня - гейм дизайнер, DBA и балерина. Всё скилы на достойном уровне и абсолютно без шуток. Если нужно больше примеров, то ходите сюда. А вообще, в пору подтаскивать кардинальные числа для оценки этого бесконечного разнообразия, но не факт, что все оценят.
Посему, ограничу область рассмотрения синьорами обыкновенными из программирования/разработки с уклоном в тот самый пресловутый веб.
Фундамент
Сразу скажу, что титулы "синьор реакта", "синьор AWSа" и подобные - это какая-то хрень. Это классический замес техников и инженеров воедино. Здесь "синьор" надо читать как "крутой знаток". То есть это аналог слесаря 6-го разряда. Чувак это эпической крутости и делает крутые вещи, но не является синьором. Увы, в индустрии всё давненько перемешалось, но давайте отделять мух от котлет. Синьор - это про фундаментальные знания и успешный опыт множества серьёзных разработок с применением этих знаний. То есть синьор - это инженер с богатым опытом боевых действий, в "устаревшей" советской классификации.
Исходя из означенной парадигмы, давайте посмотрим, что же надо знать и уметь.
Сети
Давайте сразу с холиварного начнём, чтобы далеко не ходить.
Классический вопрос "что происходит, когда мы вводим в адресной строке example.com и жмём ентер?" должен сразу влечь цепь воспоминаний про TCP/IP, некоторые мысли про альтернативы вида ARP и далее разворачиваться в пышное повествование о сборке пакета, вложениях пакетиков один в другой, порты, фрагментацию, способы передачи на разных уровнях, про подтверждение и неподтверждение доставки пакетов, различные application-протоколы, их особенности, роутинг, приблизительное представление о пути обработки пакета в netfilter и его собратьях и вот это вот всё. Короче, всё что Таненбаум завещал и ещё чутка сверху про application-level и железно-юниксовые особенности.
Помимо вот этой горы "бесполезных сетей", надо бы понимать где и как это может выстрелить и пригодиться. Например, с ходу понимать что есть NAT, как его пробить и зачем он может пригодиться при организации внутренней сети. Как туда втиснуть туннели, как выборочно завернуть трафик в них, как работать с сетевыми интерфейсами в юниксе и вся эта прочая херобора. Конечно, с места хвататься и писать команды iptables не надо, надо просто знать широту спектра возможностей и места, где дислоцированы самые популярные грабельки.
Оси
Ну там, что логи в /var/log лежат, что pid-ы в дерево организованы, что бывают env-ы и через них работают всякие pwd и cd -. С башем, там, свободно взаимодействовать: логи погрепать, порты открытые посмотреть, пидам сигналы послать, потребление памяти оценить, скриптец написать, пакеты накатить, завимости разрулить, из исходников чего собрать без прямого make install, посмотреть какие либы к бинарю прилинкованы, быть в курсе про strace и wireshark, не бояться демонов во всём их многообразии, пробрасывать тунели/порты/прокси через ssh, тыкать палочкой файловые дескрипторы, уметь юзать man в любой непонятной ситуации и ещё много много интересных штук в том же духе. Короче, быть обычным юзером в изложении Кернигина с Пайком.
Здесь же нужно упомянуть app и web сервера и их настройку. Конечно, nginx и его сотоварищи уже давно тянут на отдельную специализацию и, быть может, уже сопоставимы с тем же ffmpg по монструзности, но базовый набор знаний должен быть. Всякие там vhost, настройка проксей/перенаправлений, прикручивание сертификатов, раскидывание приложений по портам, поддержка нескольких доменов и тд.
А чо так много? Я бы сказал, что это мало. Тут ни пересборки ядра, ни процесса загрузки ОС, ни awk+sed, ни всяких nspawn и прочих инструментов для виртуализации, ни узкоспециализированных бинарей. Хотя про всё это многообразие хорошо бы быть в курсе. Чтобы меньше вещей казалось магией и было понятно откуда ноги растут. И, само собой, хоть какой-то практический опыт применения всего вышеозначенного должен быть. Чтобы, получив ключи от танка ssh-доступ можно было зайти с ноги и сразу раскатать средних размеров приложение, либо забороть проблему средней лютости.
Хранилища данных
Быть в курсе про места, где складывают данные: файловые системы, различные носители информации от дискет до NVMe и программные надстройки над ними. Здесь же, должны быть знания баз данных (хотя бы на уровне sql/nosql) и областей их применимости. Знать SQL и хотя бы один его диалект, подозревать о иных языках запросов и сдержанно их ненавидеть за изобретение велосипедов. Понимать отличия декларативного сикуля от прочего императивного мракобесия и, следовательно, уметь мыслить сикулем. Само собой, ACID, структуры данных, индексы, чтение эксплейнов любой степени тяжести и оптимизация запросов на базовом уровне. Так же, будет неплохо понимать куда какие данные лучше сувать (кэш, логи, финансовую инфу etc), что там с хранилищами key-value, document-oriented, column-based и прочими достижениями непоседливых инженеров и их мысли.
Про интимные подробности различных базёнок, например, про временнУю сложность операторов в redis, про последовательность выполнения запроса в PG, про различные движки в ClickHouse или про лимиты BSON в Mongo можно не задумываться. Всё это логически вытекает из базовых знаний и Гугл радостно поможет с освоением, когда припрёт заюзать.
Английский
Вот так внезапно! Да, в нашем мире это тоже обязательный атрибут. Иначе, какой ты, нафиг, танкистсиньор? Как минимум, надо уметь гуглить на английском, читать технические тексты на нём же и, желательно, быть в состоянии описать свою проблему текстом, дабы спросить иностранных коллег по цеху. Если ещё и ртом говорить на нём умеешь, то вообще счастье!
Клингонский
Его техническим диалектом любой разработчик владеет "от рождения". С себе подобным мы можем коммуницировать крайне эффективно и даже не замечать что используем очень специфический набор терминов и синтаксических конструкций. Чтобы лучше понять о чём речь - посмотрите на рекрутёров. Им приходится изучать сей технический диалект, дабы коммуницировать с соискателями. Но, к сожалению, большинство рекрутёров не писали код в промышленных масштабах, а учили "язык" как любой другой иностранный. Отсюда же растут ноги кучи ляпов/мемов, которые регулярно появляются в описаниях вакансий и бодро разносятся по сообществу. Последний, кстати, про милф-разработчика.
Второй же диалект - это бизнес-диалект. Когда прожект/продакт менеджер, саппорт или иной коллега, созерцающий продукт снаружи и общающийся с конечными пользователями доносит вам свои мысли. Эту штуку тоже надо знать, понимать и уметь синхронно переводить с технического клингонского на бизнес-клингонский и обратно.
Программирование
Один язык на уровне слепой печати продакшн кода из головы по запросу. Общее знание шаблонов проектирования и основных библиотек языка подразумевается. Если в арсенале есть что-нибудь низкоуровневое (по современным меркам), то жирный плюс. Ибо, например, после Си любой иной язык - это очень просто. Но, в любом случае, понимание алгоритмов и структур данных - в обязательном порядке. Ровно так же как и чёткое представление о ресурсах, их потреблении, управлении и учёте. То есть, вся эта магия с памятью и её уровнями, сложность алгоритмов (О разного размера), процессорное время, переключение контекстов, интерпретаторы/компиляторы, их особенности и плюсы/минусы хотя бы на базовом уровне. Чтобы, например, не удивляться "многопоточности" в GIL и его собратьях. Тут же процессы/треды/файберы и основные знания параллельного выполнения кода. Ну и основы функционального программирования. А то его, так или иначе, завезли уже во все языки программирования.
А как же фронтенд?
Да никак, просто в разделе "программирование" язык будет из подмножества js, а остальное останется без изменений. Ну и HTML+CSS добавится. Вёрстка, поток документа, приоритеты селекторов, работа с DOM-ом.
А как же <название распоследней js-библиотеки/фреймворка>? Так же - никак. Это не фундаментальные знания. В конце статьи будет более развёрнуто об этом.
Архитектура
Это когда понимаешь, как увязать воедино всё вышеозначенное, чтобы оно на своих местах было, дополняло друг друга, а не мешало и чтобы минимально необходимый набор инструментов/технологий был, а не зоопарк. Здесь же, масштабирование, отказоустойчивость, CAP-теорема, оценка необходимых ресурсов (вычислительных мощностей, пропускной способности, кол-ва воркеров etc) и прочие высокоуровневые штуки, которые серьёзные дяди рисуют квадратиками да стрелочками на доске и от выбора/конфигурации которых крайне сильно зависит успех всего последующего процесса разработки.
Кстати, самая лучшая похвала в архитектуре, это когда на презентации результата тебе недоумённо говорят "и вот эти три квадратика вы два месяца рисовали?!" и больше никаких косяков найти не могут. То есть всё на столько просто получилось, что "очевидно же!" и не может туда быть закопано несколько сотен человекочасов.
Управление
Тут есть несколько видов.
Планированием
То есть, понимание скрамов/канбанов/ватерфолов и бесхитростной анархии стартапов должно быть в ассортименте. Опыт взаимодействия с чем-нибудь типа Redmine/Jira/ZenHub/etc. Не должно возникать вопросов зачем происходит планирование, как, в первом приближении, оценить задачу при отсутствии половины требований, какие бывают методики оценок и когда какую хорошо применять. Представление об управлении рисками будет большим плюсом. С его помощью можно эффектно предложить забить на большой и тяжёлый кусок функциональности и чётко аргументировать почему это наилучший сценарий из возможных. Да и с бордер-кейсами будет работать гораздо легче, а не слепо закрывать их всех большими кусками бизнес-логики.
Кодом
Версионный контроль всякий. Git, нынче, в тренде. Чтобы было понимание что такое коммит, как он с сотоварищами в дерево организуется, чем тег от бранчи отличается, как правильно бранчеваться, сливаться и как это можно практически приложить для пользы личной и общественной.
Процессом разработки
От бранчевания, через тесты с кодоанализаторами до CI/CD и релизов. Почему тесты - это важно, почему не надо холиварить за линтинг, как быстро собрать CI/CD на коленке, как подкрутить существующий пайплайн под новые хотелки, как зарелизить чтобы потом не было мучительно больно и не пришлось красноглазить по пояс в консоли продакшена и прочие неприметные, но очень важные штуки.
Людьми
Труды Чалдини и Фромма штудировать не надо (хоть и увлекательно), но базовый набор навыков должен быть. Чтобы не говорить "Вася, твой код гумно, а ты мудак! Звездуй переделывать и шоб я это херню больше не видел!", а более конструктивно сообщать, что не были учтены некоторые требования, можно улучшить пару мест и если воспользоваться вооот этой приблудой, то можно сильно сэкономить время и силы. Иначе говоря, подавать личный пример, конструктивно помогать коллегам и, по мере сил, мотивировать окружающих на качественное исполнение своих обязанностей.
Софт-скилы
Как вы уже поняли из предыдущей части про управление, софт-скилы - это тоже часть синьора. Если гуру кода и владыка техники не может прокоммуницировать с ближним своим, то это очень крутой чувак, но не синьор. Эмоциональный интеллект должен присутствовать и активно использоваться по назначению. Надо уметь чётко описывать проблемы, пути их решения, аргументированно критиковать и предлагать альтернативы. Быть открытым к критике своих творений, а так же уверенно стучать пяткой в грудь и слать всех от джунов до С-левела на хрен, когда интуиция говорит, что вот тут должно быть именно так и никак иначе. Естественно, принимая на себя всю ответственность за такое решение. Если что, ответственность - это не только звиздюли, но и плюшки, если решение выстрелило и принесло с собой дополнительный профит и/или экономию. Последнее (в смысле, плюшки), нужно выбивать отдельно используя скил продаж. О нём ниже.
Навыки самопродажи и прочей торговли, увы, тоже обязательный атрибут. У нас капитализм, всё вокруг - это товар, а что не товар, то уничтожить (если не согласны - труды Ленина вам в помощь). Так вот, без продажи не то что на нормальную работу не устроишься, даже своего мнения, порой, не отстоишь. Так что в синьоре ещё и продажник должен жить. Небольшой, но въедливый и честный.
Что же в итоге получается?
Получается большой и добрый монстер. Который дохрена чего умеет, ещё больше знает, но ещё не превратился в сферическое существо в вакууме и готов на новые свершения. То есть, мотивацию не растерял и она у него внутри, а не снаружи.
Такого же растить минимум пятилетку в суровых условиях продакшена да в атмосфере профессионалов!
Всё верно. По времени, считай, как высшее образование получить, если не больше. Только без халтуры, пьяного угара, складывания прибора на занятия, а всего лишь с вджобыванием по 8+ часов каждый день... иногда не только будний. Можно сказать, это современная вышка, которую все хотят, но никто не хочет давать, ибо дорого!
Гдеж такого найдёшь?!
Да, в общем-то, есть они и довольно много. Только все они чумаданом денег и пакетом опционов сверху придавлены к своим местам, чтоб далеко не отползали. Проблема в том, что, судя по вакансиям на рынке, именно таких и ищут, но не понимают сколько они реально стоят и какой на них спрос. Или не хотят понимать? Из-за чего, подавляющее большинство кадров плавно, но целенаправленно, течёт за бугор. Там мало того что денег больше, так ещё и условия приятнее. Например, круг общения ближе и роднее по менталитету, менеджеры вменяемые и общий уровень адекватности выше. Не говоря уж о задачах и их побочном эффекте в виде почти обязательных статей и опенсорса.
На самом деле, за бугром уже поняли проблему и хантят прямо со скамьи институтской, если не раньше. Вот тут хорошо описано сие действо и последствия. Так что кому надо, тот находит. Но кадров не хватает и страдают в общем-то, непричастные области. Чем это обернётся мы все с вами увидим в ближайшем будущем. А пока живём как завещал Конфуций врагам своим: "чтоб ты жил в эпоху перемен!"
Он же стоит как крыло от звездолёта и чугунный мост!
Всё верно. Три года назад я писал, что в РФ вилки вакансий были в районе 2-3к$, а потолок - в районе 5к$ (300к рублей по тем временам) да и то, таких вакансий было крайне мало и явно ставку там не указывали. Теперь же 5к$ - это вполне себе норма даже для РФ. Такую сумму открыто указывают. А если копнуть чуть глубже, то по России у рекрутинговых агентств потолок в районе 9к$. А если выйти на межгородмеждународный рынок, то там 10к$ - это не космос и далеко не предел. При этом, особо ценные кадры, пишущие код, могут быть придавлены и двадцаточкой, и опционом и ещё бонусом каким. И это мы ещё тактично умалчиваем про то что удалёнка может быть не одна(https://overemployed.com/). Короче, сами фантазируйте.
Что же делать?
Сухари сушить! Ну и базис прокачивать заодно с формированием целостной картины мира. Образование нам немного подкорректировали в последние пару десятков лет, поэтому кроме "помоги себе сам" ничего не остаётся. Кстати, если заметили, во всех вышеозначенных пунктах нет ничего про современные фреймворки, новомодные инструменты, библиотеки с переднего края науки и про прочие свежие и современные вещи. Всё относительно просто, базово и если отмотать лет на 10 назад, то мало что поменяется в повествовании. Потому что при всей скорости изменения мира разработки в частности и АйТи в целом, база остаётся одна и та же (хотя все старательно внушают нам обратное). При наличии той самой базы можно влиться в любой современный тренд за пару недель или месяцев и не испытывать никаких затруднений. Раскурить докер или разобраться с AWS при знании юникса и сетей? Легко! Изучить очередной js-фреймворк при наличии знаний в программировании? Да не вопрос! Освоить новую фишку очередного языка программирования? Позвольте, это же давно забытое старое и мы это уже знаем!
В общем, прокачивайте себя, товарищи! Употребляйте в достаточных количествах знания фундаментальные. Старательно откладывайте их про запас, интересуйтесь смежными областями и навыками по взаимодействию с окружающими гуманоидами. И не будет у вас иного пути и желания, кроме нанесения добра и причинения пользы себе и ближнему!
Комментарии (165)
SirEdvin
11.01.2022 12:49+36А что тогда нужно знать архитектору, если он еще круче чем сеньйор?
Просто не совсем понятно, зачем детально расписывать сети и настройки веб-серверов, но вот файловым системам указана лишь одна строчка. А как же знать форматы файловых систем, как работает форматирование и так далее. Чем файловые системы хуже сетей?
Вся статья похожа на небольшую суммаризацию автора на тему "что болит", чем на реальный разбор.
Ибо, например, после Си любой иной язык - это очень просто.
Ну и это да. Си простой язык, просто небезопасный.
Loriowar Автор
11.01.2022 12:58+11По личному разумению, архитектор не круче синьора, у них просто по жизни предпочтения разные и немного отличаются категории мышления. У архитектора категории глобальнее, а у синьора-разработчика душа больше болит за реализацию и её нюансы. То есть один больше любит придумывать и задавать общую форму, а второй больше любит оживлять эту форму и додумывать детали.
В небезопасности же и есть вся суть. Если ты знаешь что там под капотом, почему оно сделано именно так и какова цена "небезопасности", то более разумно используешь все прочие инструменты.
SirEdvin
11.01.2022 13:02+2В небезопасности же и есть вся суть. Если ты знаешь что там под капотом, почему оно сделано именно так и какова цена "небезопасности", то более разумно используешь все прочие инструменты.
И тут из-за угла выглядывает rust.
Это как говорить, что электрик, который долго прокладывает проводку без средств безопасности круче того, кто почему-то считает неплохой идеей соблюдать ТБ. Си такой не потому, что это самое крутое решение, это было просто самое крутое решение на тот момент.
К тому же Си очень разный. Человек может всю жизнь клепать микроконтролерры на Си и считать себя офигеть каким специалистом, а потом ему приходится сесть за какую-то Scala или Rust и оказывается, что прямое управление памятью это не сложно.
Ну и да, никто не умеет безопасно писать Си. История еще не знает таких случаев.
По личному разумению, архитектор не круче синьора, у них просто по жизни предпочтения разные и немного отличаются категории мышления. У архитектора категории глобальнее, а у синьора-разработчика душа больше болит за реализацию и её нюансы. То есть один больше любит придумывать и задавать общую форму, а второй больше любит оживлять эту форму и додумывать детали.
Тогда зачем синьору глобальные познания в архитектуре?
MarazmDed
11.01.2022 14:00-6Ну и да, никто не умеет безопасно писать Си. История еще не знает таких случаев.
Boost нервно курит в сторонке...
SirEdvin
11.01.2022 14:14+9Помимо того факта, что Boost это все-таки С++, не совсем ясно, почему он курит в сторонке.
MarazmDed
12.01.2022 18:23-2Помимо того факта, что Boost это все-таки С++
Понятно, что C++ - отдельный ЯП, но обычно, когда говорят C, то подразумевают и C++. Зачм использовать в 2022г чистый C - мне не очень понятно.
не совсем ясно, почему он курит в сторонке.
Как мило. Ну в таком случае, история вообще не знает безопасной разработки софта. Вообще на любом ЯП. Под безопасной разработкой в контексте С подразумевается безопасная работа с указателями. Ну так Boost и решает эту проблему. Да, это не язык со сборщиком мусора, но тем не менее.
SirEdvin
12.01.2022 19:04+2Понятно, что C++ - отдельный ЯП, но обычно, когда говорят C, то подразумевают и C++. Зачм использовать в 2022г чистый C - мне не очень понятно.
Абсолютно за те же, зачем использую С++ в 2022 году, когда есть куча более полезных языков. Ну и это очень странная позиция "говорят про одно, подразумевают другое", мы тут в сообществе программистов или HR?
Как мило. Ну в таком случае, история вообще не знает безопасной
разработки софта. Вообще на любом ЯП. Под безопасной разработкой в
контексте С подразумевается безопасная работа с указателями.Boost "решает" эту проблему так же, как и любой другой способ навернуть умных указателей. То есть он закрывает довольно узкую прослойку проблем, а куча других остается. Ну и как бы, решение проблемы снаружи языка всегда решают проблему довольно фрагментировано. Приходится использовать либу, которая решила не подключать boost? Добро пожаловать в проблемы.
0xd34df00d
12.01.2022 19:11+3Буст? Безопасная работа с указателями? В таком случае будет ещё ироничнее тот мелкий баг, с которым я встретился неделю назад, и который описал здесь (кстати, там есть мелкая ошибка в предложенном решении, плюсик в карму за её нахождение).
Очень безопасно, очень хорошо проблема решена.
vassabi
12.01.2022 20:57кстати, там есть мелкая ошибка в предложенном решении
неужели лишний constexpr ?
0xd34df00d
12.01.2022 21:04Почему?
F0iL
13.01.2022 12:39но обычно, когда говорят C, то подразумевают и C++
Вообще даже близко нет.
Ну в таком случае, история вообще не знает безопасной разработки софта. Вообще на любом ЯП.
В принципе, верно. Вот только легкость написания безопасного/небезопасного кода на разных языках очень разная. В каком-нибудь C или C++ компилятор не то что не защищает от ошибок, а наоборот в некоторых случаях пользуется каждой ошибкой разработчика максимально неявным и опасным способом, а в каком-нибудь Rust компилятор больно бьет разработчика по рукам когда тот пытается сделать что-то не то и докапывается до каждой строчки кода.
Под безопасной разработкой в контексте С подразумевается безопасная работа с указателями.
Ха-ха. Как уже было сказано выше, способов отстрелить ногу и написать ненадежный/небезопасный код на Си даже без указателей очень и очень много. С C++ еще веселее (даже вместе с Boost) - там чтобы получить висячие ссылки, use-after-free, buffer overflow и memory corruption, можно даже не иметь в коде ни единого сырого указателя вообще.
Ну так Boost и решает эту проблему.
Расскажете, как именно? Если речь про умные указатели, то см. выше, они совершенно не решают проблему. И кстати, умные указатели из Boost по большей части уже 10 лет как переехали в основной стандарт C++, так что чего вы с ним носитесь - непонятно.
Да, это не язык со сборщиком мусора
В C++ возможно использование сборщика мусора. Например, Boehm или Oilpan.
Zmops
11.01.2022 19:10+3--По личному разумению, архитектор не круче синьора, у них просто по жизни предпочтения разные и немного отличаются категории мышления.
Архитектор выше. Если это вкладывать в "круче" - то да, круче.
То, что описано в статье - это не синьор, даже образца 2008г в США. Это Expert \ Principal. Синьору достаточно уметь менторить и делать систему с нуля \ улучшать текущую в меру своих сил. В противовес миддлу, который просто не нуждается в контроле при работе в стриме, опредленном более опытными товарищами.
pavelsc
12.01.2022 19:33Чем отличается архитектор сарая от строителя сарая? Да ничем, строитель плюс-минус сможет сараи и без архитектора возводить и даже импровизировать (безопасно для заказчика) для разных животных/инструментов. Может даже себя называть архитектор, или строитель-архитектор, и это без нотки иронии, ведь такой строитель может принимать заказы на сараи любой сложности через десяток лет.
Чем отличается архитектор Бурдж-Халифа от его строителя? Разница вполне очевидно, что пропасть. Строитель небоскреба не в состоянии спроектировать и построить небоскреб, даже если ему дать бесконечно денег при условии, что он будет самым умным на проекте. А если сможет и какая-то QA группа подтвердит, что небоскребы по качеству идентичны, значит строитель на самом деле известный архитектор, а кирпичи для души кладет =)
Jammarra
13.01.2022 12:36Строитель небоскреба не в состоянии спроектировать и построить небоскреб, даже если ему дать бесконечно денег при условии, что он будет самым умным на проекте.
не был бы так категоричен. Самый просто вариант это взять проект другого небоскреба типовой и допилить напильником.
уверен что 90% архитекторов так и делают. Вы переоценивайте влияние одного человека в крупных проектах.
У меня иногда глаз дёргается когда я вижу решения принятые в крупных корпорациях. Но тем ни менее это хрень из палок на паровом ходу работает и приносит деньги.
LARII
11.01.2022 12:58+18Что должен знать и уметь старший разработчик-исполнитель? Кем он должен быть?
Он должен быть менеджером. (Управлять людьми, планировать(функция менеджмента по учебнику), уметь в риск менеджмент.)
Удобно, чё. И код пишет в промышленных масштабах и рулит-разруливает. А ЗП та же. Плюс еще с клиентом бухает как sales. Очень удобно.
Loriowar Автор
11.01.2022 13:07+4А кто сказал что ЗП та же? Мне кажется, прокачка навыков должна вести к увеличению полезного выхлопа, а он, в свою очередь, к улучшению благосостояния и дохода. Если это не так, то надо бы подопнуть соответствующего дядю/тётю и обсудить условия труда. К работе за еду в условиях "денег нет, но вы держитесь" в статье ни коим образом не призывается.
SirEdvin
11.01.2022 13:10+3Мне кажется, прокачка навыков должна вести к увеличению полезного выхлопа,
У позиции старшего работчика есть определенный потолок полезного выхлопа, который он на этой позиции перепрыгнуть не может (если ему не повезет с хорошим менеджментом). И очень часто этот потолок наступает до того, как будут все знания в статье усвоены.
kalombo
11.01.2022 14:09+6Ну это всё равно что сказать, я тут сижу в деревне Гадюкино, у нас тут электричества нет, не то, что программисты какие-то требуются, а вы тут своей статьей 10к$ обещали. Просто это логично, если вы делаете сайт-визитку со 100 уников в день, то и расти не будете, да и платить вам не за что 10к$ Тут надо проявлять какую-то инициативу непосредственно самому разработчику, искать другую работу, попробовать перевестись в другую команду, поискать челенджевые задания, поинтересоваться бизнесом, возможно придумать как бизнесу заработать денег с помощью своей идеи. Сама статья - помощь, как вы можете стать эффективнее и продать себя подороже, а не туториал по получению 10к баксов.
SirEdvin
11.01.2022 14:20+3Даже вне рамок сайтов-визиток, значительная часть того, что тут написана вполне может привести к overqualified для синьор позиции для большей части рынка.
Loriowar Автор
11.01.2022 14:38+8Предлагаю решать проблемы по мере их поступления. Ни разу в жизни пока не сталкивался с overqualified "проблемой" на рынке… а очень хотелось бы!
GooG2e
11.01.2022 14:57+7хз OverQualified на мой взгляд может возникнуть только в ситуации, когда вы по деньгам не стыкуетесь. Причём чаще всего - платить хотите за одно, часть навыков задвинув, а потом по-тихому их тоже подключить, хотя раньше они не требовались.
А так мне кажется это больше красивое слово, когда вы по навыкам не стыкуетесь с командой/проектом
SirEdvin
11.01.2022 15:10+2Ну, скажем, если у вас довольно простые бизнес задачи, слабые требования к производительности и куча легаси, но вы пихаете на проект исключительно синьоров, то на мой взгляд это отлично подходит под OverQualified ситуацию (у меня на текущем проекте так :) ).
Loriowar Автор
11.01.2022 15:11+1Остался один вопрос: а почему синьор "пихается" в такое?
avengerweb
12.01.2022 01:25Тоже не понятно что такое простые бизнес задачи. Если, там куча легаси, задачи простые и пихают сеньоров, а все остаётся как есть, это скорее ближе к under qualified уровня сеньеров.
GooG2e
11.01.2022 14:53+5Так он на то и большой и главный, если где-то что-то вдруг, то может спокойненько копать и находить проблему, а не долго и муторно выяснять, что оказывается всего-то прав на файлике не хватило. Да и наличие кругозора больше нужно для какого-то понимания, а как это внутри работает, чтобы лучше связи видеть.
Ну это на мой взгляд)
snuk182
11.01.2022 23:50+2А чем отличается "спокойно копать и находить" от "долго и муторно выяснять"?
GooG2e
11.01.2022 23:54+1наверное, я как-то слишком образно выразился, но суть в том, что сеньор может ограничить некий круг наиболее вероятных проблем, которые могли приветси к такому результату и их перебирать. Причём для каждой проблемы у него в голове может быть сценарий воспроизведения примерный.
Специалисты же имеющие меньший кругозор могут "долго и муторно" перебирать все возможные ситуации и сценарии, либо просто не суметь предположить ничего.
LARII
11.01.2022 15:49+4К уменьшению это приведет. К гадалке не ходи.
Как называется менеджер без прав на организацию, мотивацию, координацию, планирование и контроль?
Три буквы...
kovrovdv
11.01.2022 13:05+28В целом верно, только не пять, лет а скорее десять.
За это время разработчик уже успевает пережить одну смену основного языка/платформы и ко всем инструментам начинает относится гораздо спокойнее. В виде - хотите, например, Clickhouse/Mongo/... ? - давайте почитаем, может вам поможет. Появилась год-два назад? - подождем еще пару лет, пока отладят, допялят и остальные на ней шишки набьют. Очень хотите? - ну ладно давайте настроим, но вот так это скажется на бюжете разработки и развертывания. Все еще хотите? - ладно ищите человека который будет за это отвечать, а я пока попробую сам по мануалам развернуть и настроить.В разработке он уже не боится легаси, т.к. знает, что после 2-3 лет работы на проекте - даже его код, для него же самого уже легаси. И чтобы этого избежать нужно либо работать над проектами, которые и не предполагается запускать - сделали отчитались -> выкинули, либо быстро напили и
скипнули пока не догнали- работу же менять каждые год-два надо.. Поэтому он не прячется за модное слово техдолг, и как только он накапливается переходит к режиму скипнуть, а настаивает на непрекрашающеся переработке проекта по частям с самого начала.А в используемых инструментах сеньор уже во многом знает как делать не надо не смотря на то, что так в нескольких умных книжках написано, а где не знает - там уже одним местом чувствует.
А менять работу он не горит желанием, потому что он уже нашел место, где ему интересно, его ценят, и денег ему хватает - не много-много, больше всех, плюс опционы, и майбах не парковке, что кажется целью джунам, а именно достаточно. Именно эти ощущения вместе его на месте и держат.
BobArctor
11.01.2022 13:10+4За awk+sed вне экспериментальных энвов надо табуреткой бить. (к вопросу о применимости инструментов и классификации специалистов)
iboltaev
11.01.2022 15:10+21вы по софт-скиллам не прошли
sshikov
11.01.2022 17:39+2Почему это я (он) не прошел? По-моему, если я на собеседовании узнал, что тут пишут на awk, развернулся и ушел — это win-win. То есть, не прошел и работодатель — по набору используемых технологий. Но нам обоим хорошо — потому что он найдет других, которых это устроит, и я найду других.
CtrlAltDragon
11.01.2022 17:49+3В первом комментарии в этой ветке подобный подход не виден. Видна лишь религиозная ненависть к sed/awk. Что вызывает лишь недоумение, особенно когда ты по работе спокойно используешь и то, и другое в bash-скриптах в продакшене.
SirEdvin
11.01.2022 17:57+4Дело не в религиозной ненавести. awk и sed довольно нишевые тулы, которые используются раз в столетие и очень быстро забываются. В добавок, они имеют довольно необычный синтаксис и в итоге, что бы понять, что делает команда написанная недели три назад тратится столько времени, что проще переписать на любой другой язык.
Если у вас в команде хотя бы несколько человек на постоянке используют awk, то ситуация конечно другая.
PS: Ну и да, bash-скриптов на продакшене существовать не должно, имхо.
sshikov
11.01.2022 18:02+6Ну, религиозная ненависть — она скорее всего вредна. За отказом от применения в проме sed или там awk обычно должен стоять хотя бы какой-то опыт. Скажем, мне мой опыт говорит, что я много раз переписывал скрипты на баше, размером порядка сотен строк, на что-то более удобное, типа groovy. Или python, хотя бы.
И это давало мне очень хороший эффект, без всяких исключений — то есть, сколько переписал, столько раз эффект положительный. Сокращение размеров кода в два раза, например. В сочетании с лучшим пониманием кода коллегами — т.е. кроме меня после переписывания все видят, что он делает, и понимают почему. Причем порой еще и функциональность расширялась попутно.
Но вас я тоже вполне могу понять — потому что писать все же нужно на том, что ты хорошо знаешь. Ну и назначение кода конечно важно — потому что если вы вовсе не сопровождаете написанное, или делаете это один, это не такой же случай, как если в этих баш скриптах будет часто копаться еще кто-то (с другим набором знаний).
iboltaev
11.01.2022 18:26+2ненависть ни при чем. Табуреткой бить = плохие софт скилы
sshikov
11.01.2022 19:47+1А как вы оцениваете софт скиллы?
Ну вот решили мы кого-то демотивировать, не нравятся нам его методы по внедрению awk в проект. Стукнули его табуреткой (опустим на время вопрос, удобно ли именно табуретку с этой целью употреблять, или можно стулом), и он не просто выжил, но и стал сильным разработчиком. То есть это сработало. Это хороший софт скилл? Или надо сначала сравнить с другими методами демотивации, типа лишения премии?
:)iboltaev
11.01.2022 20:23+4ну так и оцениваю. Мягко - значит софт. Нет - значит не софт. Вот обитая табуретка - наверное, софт. А простая деревянная - не софт. Все просто ж.
а по существу
не нравятся нам его методы по внедрению awk в проект
кому-то не нравятся ваши методы по внедрению $TECH_NAME в проект - все, файт табуретками. Потому и нужно софт
sshikov
11.01.2022 20:48Если буквально посмотреть в википедию на определение, то софт скиллы — это вовсе не мягкие, это гибкие скиллы.
Если для решения задачи нужно иногда устроить конфликт (а потом успешно разрешить) — то чем умение это сделать не гибкий скилл? Не самый лучший и не самый широко используемый — но вполне себе инструмент для некоторых ситуаций.iboltaev
11.01.2022 21:11не всякий конфликт можно разрешить, не всякий конфликт стоит устраивать. Он и сам собой прекрасно возникнет. По моему опыту, чаще достаточно определить свою(!) зону ответственности, и почвы для конфликта становится меньше.
Если взять приведенный пример "мне не нравится, как коллега (?) делает Х" - то если разобраться, почвы для конфликта тут нет. Мне может не нравиться, а начальство устраивать, тогда все ок. Начальство может не устраивать - тогда тоже все ок, так как это не мое дело. Мне может не нравиться вычищать баги в этом X - тогда тоже нет почвы для конфликта, просто обрисовываем начальству, начальство разбирается, так как по мнению начальства может быть все ок и еще может быть так, что чего-то не знаю я. Если мы и есть начальство, и нам не нравится, как подчиненный делает X и что подчиненный использует - ок, как один из вариантов, делаем как надо, убеждаемся, что так лучше, убеждаемся, что использованный инструмент разрешен к применению и не противоречит политикам, вводим как стандарт и ставим задачу на переделать как надо, конфликтовать тут тоже негде.
sshikov
11.01.2022 21:22>Если взять приведенный пример «мне не нравится, как коллега (?) делает Х» — то если разобраться, почвы для конфликта тут нет.
Ну да, в этом конкретном случае — нет конечно. Когда речь об инструментах, где эффект можно измерять, обычно проще убедить. И эффективнее тоже.
Я тут скорее о более общей теме — почему умение применять жесткие (но эффективные) меры не является софт скиллом? Причем понимание того, когда их стоит применять, а когда нет — тоже часть умения. Конфликт не по серьезному поводу реально устраивать не стоит — слишком быстро пропадет эффект, если применять сильные средства каждый день.iboltaev
11.01.2022 21:38почему умение применять жесткие (но эффективные) меры не является софт скиллом?
жесткие, но эффективные меры, безусловно, стоит уметь применять. Главное, действительно уметь, т.е. цель/средства , и цель действительно лучше бы тоже хорошо представлять.
iboltaev
11.01.2022 18:32+5"Николай ненавидел все, что запускается из-под шелла. А все, что не запускается, он запускал из-под cygwin-а и нненавидел"
(c) (откуда-то)
BobArctor
11.01.2022 19:41+3Ненависти нет. Есть опыт хождения по собственноручно наделаным скриптам с регулярками, которые долго работали нормально, но потом перестали. Второй раз было интересно когда пачку старых заборов из sed нужно было объяснить ньюкамеру. Это хорошие инстументы чтобы раз от разу что-то сделать прямо сейчас на проекте где кроме автора больше никого нет.
Korobei
11.01.2022 22:43А если эти регулярки будут в питонячьем скрипте, они не перестанут работать при тех же условиях? Или подразумевается что в скрипте можно логику какой-либо валидации прикрутить? Или про то что регулярки не надо использовать?
siziyman
11.01.2022 13:58+21По-моему, автор описал вещи, которые кажутся полезными лично ему, и описал своего личного "идеального специалиста в вакууме". А правда на самом деле простая: правды нет, лычка ничего не значит вне контекста компании, в которой вы работаете.
Бывают синьоры с 4.5-5 лет стажа, которые переходят потом в компанию поинтереснее джунами с повышением в зарплате.
А если по тексту статьи, то, гм, понты-то хорошие, но по сути я далеко не со всей конкретикой согласен.
Сети:
некоторые мысли про альтернативы вида ARP и далее разворачиваться в пышное повествование о сборке пакета, вложениях пакетиков один в другой, порты, фрагментацию, способы передачи на разных уровнях
Вы, конечно, извините, но человеку, занимающемуся прикладной веб-разработкой (и да, разработчик микроконтроллеров, низкоуровневый системный разработчик и просто веб-бэкэндер - это три очень разных человека, которым нужен очень разный набор знаний), это всё по большей части ни к чему - а я не думаю, что кто-то станет спорить с тем, что прикладная веб-разработка - одна из самых многочисленных сфер в коммерческой разработке ПО. TCP/IP-стэк с его соседями вроде UDP, модель OSI (и почему это дырявая абстракция, которая разваливается на ходу при внимательном рассмотрении даже самых популярных примеров)? Да, хорошо. Эзотерические альтернативы, которые не пригодятся 99,999% публики? Ну, я за вас рад, но не надо.
NAT<...> зачем он может пригодиться при организации внутренней сети. Как туда втиснуть туннели, как выборочно завернуть трафик в них
Опять же, не надо превращать прикладного разработчика в (хорошего) системного администратора, это разные люди. Если вы занимаетесь инфрой или системным программированием, вам эти знания нужны, да, но тут мы вернёмся к моему тезису выше: не надо искать универсальные ответы там, где их нет, скатываемся в абсурд.
Оси:
завимости разрулить, из исходников чего собрать без прямого make install, посмортеть какие либы к бинарю прилинкованы, быть в курсе про strace и wireshark, не бояться демонов во всём их многообразии,
Не надо в 2022 писать прикладной софт на языках, где
make install- популярный инструмент сборки, пожалуйста, людям потом это поддерживать зачем-то придётся. Хочется чего-то простого и легковесного - хотя бы перейдите на Golang, он, конечно, отвратителен как язык, но хотя бы не придётся искать, кто забыл память освободить.Разбираться (ну то есть прям разбираться, а не знать, что она в принципе происходит) в линковке библиотек к бинарникам в современных языках при деплоях примерно чего угодно в докер - тоже избыточность, если надо сделать это раз в 5 лет (а мне ни разу не надо было в диапазоне языков от го и джавы любой давности до тайпскрипта, например) - прекрасно заменяется умением гуглить.
Я бы сказал, что это мало. Тут ни пересборки ядра, ни процесса загрузки ОС, ни
awk+sed, ни всякихnspawnи прочих инструментов для виртуализации, ни узкоспециализированных бинарей.awk+sed - как религия и половые органы: иметь и пользоваться можно, остальным рассказывать и тем более агитировать посмотреть не одобряется. :)
Остальное, опять же, нужно только в узких сферах, не проецируйте это на всех. Ваше "мало" - это слишком много в общем случае, а "не мало", видимо, было бы абсурдно много. :)
Хранилища:
На удивление, по большей части согласен - там в принципе общий кругозор, но
Знать SQL и хотя бы один его диалект, подозревать о иных языках запросов
Как бэкэндер говорю - если это не имеет отношения к вашей специализации - и я продолжаю утверждать, что специализация как минимум в сфере разработки (заметьте, не языке, а сфере) важна и игнорировать её в таких вопросах нельзя - забейте вы хер на этот SQL (и уж тем более думать о его диалектах). Мне совершенно плевать, будет ли фронтэндер или разработчик ядра ОС/прошивок микроконтроллеров знать SQL, это такая же ненужная конкретика, как бэкэндеру разбираться в реакте или фронтэндеру в AWS.
Программирование:
после Си любой иной язык - это очень просто
Очень смешное утверждение, спасибо.
На большинство си-подобных по синтаксису языков действительно просто начать писать после него, вот только если у вас освоение языка заканчивается на синтаксисе, то я не уверен, что такое отношение приемлемо даже для джуна, чего там говорить о каких-то гигасеньорах. А научиться писать идиоматичный и тем более продакшн-реди, будучи травмированным Си, скажем, на Котлине, Скале или там Расте, скорее всего только сложнее.
Дальше по большей части ок-норм, но без всякой там конкретики (которой уйма в хардскилловых пунктах), а в ней-то часто все проблемы. :)
Разве что
Кстати, если заметили, во всех вышеозначенных пунктах нет ничего про современные фреймворки, новомодные инструменты, библиотеки с переднего края науки и про прочие свежие и современные вещи. Всё относительно просто, базово и если отмотать лет на 10 назад, то мало что поменяется в повествовании.
Ох попробовали бы вы рассказать кому-нибудь в этакой провинции (не обязательно в прямом смысле, а в смысле подходов в разработке) 10 лет назад про CI/CD, обязательность тестирования и вот это всё. Думается, процентов 80-90 публики вас бы нафиг послало.
NTFS-1
11.01.2022 14:31+2обязательность тестирования
Подтверждаю, не знаю как сейчас, но еще лет 7-8 назад я спрашивал у компаний-разработчиков в провинции, где думал работать, используют ли они тесты - отвечали, нет. Интересовался, как же они тогда могут быть уверены, что условная процедура doSomeMagic() делает именно то, что нужно - отвечали, что запускают ПО и смотрят, как работает.
Конечно, ничто не мешает свой код тестами оборачивать, а на чужой плевать, но это цирк будет, в командной разработке-то.
kovrovdv
11.01.2022 14:57+9И сейчас много где так, потому что это требует существенных ресурсов, а их всегда не хватает, при этом результат, часто, весьма сомнителен.
Номинальная цифра покрытия тестами тешит лишь самолюбие и ничего не гарантирует. Если вы аппелируете к списку требований, то когда он был настолько полный, чтобы действительно описывать все случаи и комбинации, которые стоит протестировать. А если считаете покрытие по методам/строкам, то цифра вообще перестает что-то значить. Идея про тесты по потоку управления... может быть, когда нибудь. Поэтому все как всегда зависит от разработчика и того, как он понимает достаточность процесса тестирования/отладки.
В чем тесты действительно помогают так это в регрессионке - потому что если отломать что-то двух летней давности, то незаметить это с ними довольно сложно.siziyman
11.01.2022 15:17+1Номинальная цифра покрытия тестами тешит лишь самолюбие и ничего не гарантирует
Да, гарантирует что-то только формальная верификация программ, однако это оч сомнительный аргумент в пользу того, чтобы не стараться и улучшить качество кода, и применить инструменты, дающие какую-то оценку качества кода (тесты точно можно отнести ко второму, к первому - обсуждаемо). А не сидеть и ждать silver bullet. :)
kovrovdv
11.01.2022 15:58+1Для улучшения качества кода уже давно придумали "ревью", и уже это требует дополнительных ресурсов.
При виде того, что могут "серьезного" поймать статистические анализаторы у обычного мидла должны волосы дыбом вставать.Не один и не два раза прогонял один известный тут анализатор на своем коде, который говорил все ок. Но это мой код, я отлично знаю в скольких местах там было сделано из говна и палок, только руки не доходили переписать, но статистически все ок.
Как раз анализаторы и покрытие тестами и кажутся серебряной пулей - прочитайте комментарий ниже - меня учили, что все входящие параметры и ответы обязательно надо проверять в коде.. и били по рукам, когда я этого не делал - а, оказывается, за разраба это должны делать... тесты.
Как бы мы не хотели жить в идеальном мире идеального кода приходится опираться на экономическую целесообразность. В начале карьеры, а это было почти 15 лет назад, я работал в конторе, которая писала ПО для банков - вот там тестили и автоматически и вручную вдоль и поперек, и у нас и при приемке очередного релиза уже в банке. Тестирование шло настолько тщательно, что от выполнения релиза до выкатки проходило до месяца (привет непрерывной интеграции и доставке). А все потому, что косяк там это не потеря игроком мега-сабли или не работающая кнопка в интернет магазине, а чуть-чуть посерьезнее, и иммитация борьбы за качество кода там не прокатывала.
P.S. И.... все равно иногда на проде косяки ловилиsiziyman
11.01.2022 16:33+5Для улучшения качества кода уже давно придумали "ревью", и уже это требует дополнительных ресурсов.
А для улучшения аккуратности внешнего вида человека придумали расчёску, что ж теперь, рубашку не гладить (если вы их носите, конечно), если расчесались? :)
Но это мой код, я отлично знаю в скольких местах там было сделано из говна и палок, только руки не доходили переписать, но статистически все ок.
Как раз анализаторы и покрытие тестами и кажутся серебряной пулей
Если кому-то кажутся - ну, это их проблемы, совершенно очевидно, что ими они не являются в реальных случаях, кмк. Это просто ещё один (ну, точнее, два, если мы статический анализ и тестирование зачем-то в один ряд поставили) инструмент обеспечения качества кода.
меня учили, что все входящие параметры и ответы обязательно надо проверять в коде.. и били по рукам, когда я этого не делал - а, оказывается, за разраба это должны делать... тесты.
Простите, что? Это какой-то произвольный набор слов. Ну то есть вы или в чём-то не разобрались, или очень плохо формулируете мысль.
А все потому, что косяк там это не потеря игроком мега-сабли или не работающая кнопка в интернет магазине, а чуть-чуть посерьезнее
Спасибо, я знаю, что такое банки (а также знаю, что процессы в них бывают очень и очень разными, это если по секрету).
и иммитация борьбы за качество кода там не прокатывала
Ну, не имитируйте, а боритесь. В том числе автотестами можно.
zaqqq13
11.01.2022 17:33Я вот тоже не совсем понял предыдущего комментатора, такое ощущение что человек реально не пользовался статическими анализаторами и тестами, сам таким был в свое время, сейчас сижу на проекте с покрытием тестами домена на 100%, остальная ерунда вроде контроллеров не покрывается, да и незачем особо, на git push стоит pre-hook с запуском анализатора и тестов и знаете что? Да это прекрасно и дико удобно, плюс реально повышает читаемость кода и облегчает поддержку
siziyman
11.01.2022 17:59+1Контроллеры может и да (хотя тоже зависит от, особенно если у вас есть сервисы-клиенты, внешние для вашей команды - я бы призадумался, возможно), но, например, поддерживать и тестировать то, что вы корректно (де)сериализуете объекты запросов-ответов, бывает крайне полезно.
0xd34df00d
11.01.2022 19:04+4А что там тестировать, если этот код почти всегда может быть спрятан в отдельной библиотеке? Это как тестировать условный стандартный sort, как по мне.
siziyman
11.01.2022 19:26Контроллеры? Что вы, например, не напортачили с тем, какие коды ответов отдаёте (да, это могут быть и примитивненькие сквозные функциональные тесты). Сериализацию? Что имена полей (если мы о джейсонах, например), формат сериализации (а бывает даже так, что сущности одного типа надо по-разному сериализовывать - грубо, где-то вам нужно 2 знака после запятой у числа оставить, а где-то 4) не перепутали. Что дата парсится именно в том формате, в котором надо, если речь о десериализации.
0xd34df00d
11.01.2022 20:19+3Как вы проверите, что ваши тесты адекватны реальности? Ну, что вы тестируете, что сериализуете в жсон, и заказчику на самом деле нужен жсон?
siziyman
12.01.2022 13:56Я чуть ниже ответил, потому займусь самокопипастой (самому неловко так делать):
Я не предлагаю тестить логику библиотеки. Я предлагаю тестить, что вы не нарушили согласованную спецификацию (набор и нейминг полей, их формат), потому что в жизни такое происходит сильно чаще, чем хотелось бы. Особенно если у вас какие-то сложные ДТО.
0xd34df00d
12.01.2022 19:13+1Мой вопрос в том, как вы будете это тестировать?
Если это интеграционный тест, где вы запускаете вашу систему вместе с другой системой — вопросов нет (на самом деле не совсем, но неважно). А иначе-то как?
zaqqq13
12.01.2022 09:38Сериализация/десериализация делается готовой либой, которая давно покрыта тестами от самого разработчика, по поводу дат и нейминга полей в json - покрывать такое как минимум странно и не особо продуктивно, получается что мы пишем тесты ради тестов. Тесты должны покрывать бизнес-логику, а не парсить json и ругаться если где опечатка в проперти. Вопрос об опечатках решается просто и всего двумя вещами - первая, это апидока, которая автоматом генерируется по responseDto, вторая, это тесты на стороне клиента, сломали апи, у клиента упал функционал на тестах, все, приехали, фиксим. В теории можно конечно покрывать тестами все подряд, можно даже парсит файлы с классами и прогонять чтобы никто не запушил матерно обозванные переменные или методы, но всего один вопрос - а стоит ли оно потраченного времени? Тут главный посыл скорее в том, что надо отделять все же бизнес-логику от данных и контрактов, это немного разные вещи
P.S. Ну и насчет вашего кейса со временем - не надо ничего думать, оперируйте не datetime string, а таймстампами и используйте под капотом utc как на сервере, так и на клиентах, тем более что из utc перегнать в нужную timezone для отображения юзеру не то чтобы большая проблема
siziyman
12.01.2022 10:59Я не предлагаю тестить логику библиотеки. Я предлагаю тестить, что вы не нарушили согласованную спецификацию (набор и нейминг полей, их формат), потому что в жизни такое происходит сильно чаще, чем хотелось бы. Особенно если у вас какие-то сложные ДТО.
И да, бизнес-логика - однозначно не единственное, что нужно тестировать. Потому что бизнес-логика не поможет, если вы начали отдавать не тот код ответа, который согласован в спецификации. :)
первая, это апидока, которая автоматом генерируется по responseDto
Хорошо, если у вас есть стек технологий разработки, который такое полностью бесшовно поддерживает, но это почти никогда не работает, как надо, если логика сериализации сложнее "вот набор полей, подставляй".
вторая, это тесты на стороне клиента, сломали апи, у клиента упал функционал на тестах, все, приехали, фиксим
То есть для того, чтобы вам узнать, что ваш код сломался, кто-то ещё должен увидеть, что сломался его код исключительно по вашей вине. Не много ли промежуточных шагов? :)
(вопрос со звёздочкой - теперь представьте, что ваш клиент - это команда бэкэнд-разработчиков другого сервиса, которые работают в другой стране и другом часовом поясе, и вы сломали им АПИ и пошли на новогодние каникулы, а у них рабочая неделя в это время)
Ну и насчет вашего кейса со временем - не надо ничего думать, оперируйте не datetime string, а таймстампами
Нет, таймстемпы - не серебряная пуля, потому что иногда в том числе клиенту нужно знать таймзону как "контекст" запроса (например, если ваш клиент - не фронтэнд, а другой сервис).
Ну а ещё если вам хоть когда-то приходится дебажить своё АПИ или читать его логи, таймстэмпы категорически хуже.
NTFS-1
12.01.2022 10:23Ну не знаю, не знаю. Может, в Enterprise всё иначе, но на мелких проектах в один-два кодера.. когда я не ленился и писал тесты, которые проверяли, возвращает ли функция площади квадрата x*x, а периметра - 4*x, то всё было хорошо. А когда по неопытности налетал на заказчика, который требовал работу "вчера" -соответственно, откладывая тесты на завтра - уже через пару месяцев функция площади могла вернуть что угодно, включая бесконечность и Access Violation. И проект превращался в тыкву.
ИМХО, хуже от наличия тестов никогда не бывает, а вот лучше - вполне возможно.
vedenin1980
12.01.2022 12:08+3хуже от наличия тестов никогда не бывает
Еще как бывает, тесты ВСЕГДА увеличивают время на обновление функционала. Условно возможно для того чтобы заменить одну строчку в коде — вам придется поправить сотню строчек кода в тестах.
Да, часто это окупается надежностью рефакторинга, но тесты не бесплатны и черзмерное увлечение тестами может приводить к еще более плохому коду, чем их отсутствие.
Вообще, unit test'ы это не про проверку текущего функционала, для разовой проверки, что все работает, можно пройтись с дебагером или просто вывести в консоль результаты работы разных функций.
Основная задача unit test'ов это облегчения добавления нового функционала и рефакторинг или обновление старого. Поэтому unit test'ы не очень нужны для прототипов, unit test'ов должно быть минимальное количество, которое гарантирует надежность рефакторинга, не нужно добавлять тесты на то, что потенциально не может сломаться в будущем или вы гарантировано не будете менять.NTFS-1
12.01.2022 12:22просто вывести в консоль результаты работы разных функций.
Я не очень понимаю, как это должно работать. У меня в проекте 10 классов, у каждого класса 10 методов, каждый метод может иметь 10 вариантов параметров - мне нужно просмотреть 1000 строк и сравнить с ожидаемым?
для того чтобы заменить одну строчку в коде — вам придется поправить сотню строчек кода в тестах.
Честно говоря, не могу представить себе эту ситуацию даже теоретически. Худшее, что может быть с кодом - это удаление методов или классов, но даже тут рекомендуется не удалять из кодовой базы, а помечать как устаревший.
потенциально не может сломаться в будущем
В программировании сломаться может всё, что угодно. Я недавно решил опробовать на небольшом учебном проекте VS2019 - и он поломал работу с сишными функциями работы со стандартным потоком. Ну то есть, зуб не дам, что именно поломал (может, напротив, починил) - но один и тот же простенький код в vs2012 и vs2019 работал по-разному.
Возможно, мы просто говорим о разных вещах или с позиций принципиально разного опыта, не буду наставить на своей точке зрения.
vedenin1980
12.01.2022 13:40У меня в проекте 10 классов, у каждого класса 10 методов, каждый метод может иметь 10 вариантов параметров — мне нужно просмотреть 1000 строк и сравнить с ожидаемым?
А с unit-test''ами вам нужно не просто посмотреть 1000 строк, а заранее их подготовить и написать сравнения каждой строки. Что быстрее (для единоразовой проверки)?Честно говоря, не могу представить себе эту ситуацию даже теоретически. Худшее, что может быть с кодом — это удаление методов или классов, но даже тут рекомендуется не удалять из кодовой базы, а помечать как устаревший.
Значит у вас классы и логика очень простая, иногда для покрытия одного метода приходится написать сотни строк кода — оберткой того что он принимает, сотни строк для те методы, которые он импортирует, и еще множество методов для проверки результата. Но суть не в этом — даже если не замечаете — исправление unit-test'ов отнимает время.Худшее, что может быть с кодом — это удаление методов или классов
Худшее, что может быть с кодом это полное изменение всей его бизнес логики. Условно, вы сделали велосипед, потому что решили, что это нужно заказчику, а ему нужна подводная лодка.В программировании сломаться может всё, что угодно.
Если у вас есть стандартные java геттеры и сеттеры, они, конечно, тоже могут сломаться, но только при таком пушистом и полном писце, что тесты вас уже не спасут. Но вы правы, всегда нужно найти место, где вы должны остановится, так как сломаться может, что угодно, вопрос только в вероятности и цене ошибки. Вы все равно не сможете покрыть тестами 100% весь свой код и все библиотеки, которые используете, и все особенности языка и операционной сиситемы, которые используете,
siziyman
11.01.2022 15:07ничто не мешает свой код тестами оборачивать, а на чужой плевать
На самом деле, если ваш код хоть как-то зависит от чужого внутри, так разве что не хуже: вы не знаете, сломался ваш код как таковой, или какая-то его внутренняя зависимость, где Вася П. из соседней команды что-то напорол.
BetsuNo
11.01.2022 15:39+1Понятно, что всё это в 99% случаев в высокоуровневой разработке не нужно, но понимание этих вещей по-хорошему необходимо. В первую очередь для того, чтобы легче поределять возможные узкие места в архитектуре "на глаз" и "пятой точкой". Ну, и в случае возникновении нетривиальной проблемы, чтобы не гуглить сутками на пролёт, а сразу отсекать пласты возможных источников этой проблемы. От себя добавлю, что ещё неплохо было бы иметь минимальный опыт написания програм для микроконтроллеров на языке ассемблера. Это нафиг не надо никому, кроме embedded-разработчиков, зато отлично помогает понять основные принципы работы процессора на практике, плюс скромное понимание того, как на смом деле под капотом может работать любимый метод в любимом фремворке под любимый язык программирования. А то вы тут сидите, и не знаете "где сейчас ваш указатель стека".
Да и в целом знания лишними не бывают, ибо чем больше знаешь, тем больше нейронных связей образуется в мозгу, и тем лучше соображалка соображает. При чём не так важно, из какой области, но для технического специалиста приоритет очевиден.
Ваш тезисы напоминили мне одно, некогда знаменитое, литературное произведение. Там ещё был персонаж, который говорил, что ему не надо знать географию потому, что есть извозчик, который довезёт куда надо.
SirEdvin
11.01.2022 15:58+2Это нафиг не надо никому, кроме embedded-разработчиков, зато отлично помогает понять основные принципы работы процессора на практике, плюс скромное понимание того, как на смом деле под капотом может работать любимый метод в любимом фремворке под любимый язык программирования.
Мммм, не поможет. embedded процессор и реальный отличаются как небо и земля. Виртуализации, оптимизации и прочий мотлох
siziyman
11.01.2022 16:02+3Понятно, что всё это в 99% случаев в высокоуровневой разработке не нужно, но понимание этих вещей по-хорошему необходимо. В первую очередь для того, чтобы легче поределять возможные узкие места в архитектуре "на глаз" и "пятой точкой".
Нет, вещи, которые я прокомментировал, как раз не нужны даже для понимания узких мест, если они для вас out of scope. Что на глаз, что пятой точкой, что любым другим органом чувств. :)
Ну, и в случае возникновении нетривиальной проблемы, чтобы не гуглить сутками на пролёт, а сразу отсекать пласты возможных источников этой проблемы.
Как правило, нетривиальные проблемы как раз-таки специфичны - имеют отношение к языку программирования/библиотеке/фреймворку/конкретной комбинации используемых технологий (как внутри программы самой по себе, так и какие-то внешние для неё системы, с которыми вы взаимодействуете, будь то, например, БД или что-то другое). Такой общий кругозор тут поможет меньше, чем умение читать, гуглить и ковырять исходники.
ещё неплохо было бы иметь минимальный опыт написания програм для микроконтроллеров на языке ассемблера
Опять же, как человек, который писал для микроконтроллеров и писал на ассемблере (правда, по отдельности - под микроконтроллеры писал я на C) - нет, нахер не надо, лучше пойдите Таненбаума почитайте (в т.ч. разделы про процессоры и вот это всё). Это как если я скажу системщикам "вам надо написать хотя бы парочку высоконагруженных веб-сервисов, чтобы понимать, нахрена вы свои сетевые драйверы вообще пишете".
Да и в целом знания лишними не бывают
Во многой мудрости много печали; и кто умножает познания, умножает скорбь. :)
А если чуть серьёзнее - да, наверное, знать больше полезно, но это не является обязательным или даже ожидаемым знанием от программиста, для которого "низкоуровневая" или системная разработка не является непосредственно сферой деятельности. Более того, если я нанимаю, допустим, фронтэндера, мне будет глубоко пофиг, пересобирал ли он ядро, знает ли про ARP-протокол и программировал ли микроконтроллеры - это бесконечно низко в списке того, что для меня является факторами при найме. Приоритет, как вы и говорите, очевиден, просто не в ту сторону, в которую очевиден для вас. :)
Ваш тезисы напоминили мне одно, некогда знаменитое, литературное произведение. Там ещё был персонаж, который говорил, что ему не надо знать географию потому, что есть извозчик, который довезёт куда надо.
А вот передёргивать нехорошо! Я не говорю, что это вообще бесполезные знания. Я говорю, что в статье с заголовком "Что нужно знать, чтобы быть синьором?", претендующей на то, что это применимо к любой сфере разработки ПО, этому совсем не место, потому что это очень узкоспецифичные знания.
svr_91
11.01.2022 16:11+2А кстати, зачем нужно знать географию?
tommyangelo27
11.01.2022 19:19+3Можно понтануться в компании под пивко знанием столицы Чили. Ну или там прикинуть в уме расстояние от Новосибирска до Пскова (с той же целью)
svr_91
12.01.2022 08:45Ну страны и сталицы мы учили на последних 2-х уроках последнего года обучения географии. Прикинуть расстояние не учили, но думаю, примерно за тоже время можно выучить. Чем мы занимались остальные 4 года 11 месяцев? Кто-нибудь помнит?
tommyangelo27
12.01.2022 09:52+3У меня учителем географии была классный руководитель, поэтому мы даже страны и столицы не учили. Каждый урок географии разбирали почему Петя плохо учится, и почему Вася толкнул Лену, и всё в таком духе.
Iceg
12.01.2022 00:06А как без этого выбирать место для релокации или хотя бы отпуска?)
0xd34df00d
12.01.2022 19:19+1Место для отпуска — соседняя комната, конечно.
А для места для релокации школьная география не поможет, боюсь.
Loriowar Автор
12.01.2022 19:44Почему же не поможет? В первом приближении можно прикинуть климат по широте… а климат — это половина успеха! ))
agilovr
12.01.2022 08:21+3Это действительно сложно объяснить почему фундаментальные знания имеют положительное влияние на принятие решений по прикладным проблемам скажем на JS. Это сложно объяснить, но легко почувствовать на себе.
У вас неплохо получилось, может быть кто-нибудь даже задумается.
0xd34df00d
12.01.2022 19:20+1Если это сложно объяснить, но легко почувствовать, то, возможно, это когнитивная ошибка.
vedenin1980
12.01.2022 19:28сложно объяснить, но легко почувствовать на себе.
Влияние гороскопов на то, что с тобой происходить тоже сложно объяснить, но легко почувствовать.
Увы, субъективные ощущения часто обманчивы, особенно если потратил много сил на фундаментальные знания, математику, олимпиадное программирование и т.п. вещи — то проще верить, что это все было не зря.agilovr
13.01.2022 11:09Дело в том, что я как раз прошел путь не от "олимпиадного программирования" до продуктового а наоборот. Может быть, если травмировать себя слишком сильно фундаментальными знаниями, потом сложно делать что-то прикладное, тут спорить не буду.
HenadziMatuts
12.01.2022 12:54По-моему, автор описал вещи, которые кажутся полезными лично ему, и описал своего личного "идеального специалиста в вакууме".
Тащемта автор сказал об этом в самом начале статьи. Но я бы предположил, что автор описал самого себя.
MinimumLaw
11.01.2022 14:17+2Проблема в том, что, судя по вакансиям на рынке, именно таких и ищут, но не понимают сколько они реально стоят и какой на них спрос. Или не хотят понимать?
Мне кажется, что ищут как правило "кодера за недорого", но в требованиях расписан именно "сеньор-помидор" в вашем изложении. На всякий случай. А вдруг прокатит? Потому и зарплата указана в объявлении чуть больше, чем просо для "кодера за недорого".
И, как следствие, мне кажется вы переоцениваете спрос на таких вот реальных товарищей. Но правы в том, что оные товарищи планомерно покидают родную гавань. Ровно также "придавлены" они к местам скорее не бонусами, а жизненными обстоятельствами.
Впрочем, я вашему описанию соответствую процетов но 85. С тестами, с CI/CD, да с управлением людьми не очень. За то остальное даже шире. ТАк что может подтянусь - мнение поменяю. Правда, если совсем честно, именно в этом направлении тянуться ну совсем не хочется. С техникой проще.
Phoen
11.01.2022 14:55+4Лучше хороший инженер, чем плохой менеджер и наоборот. Но иногда стоит попробовать чтобы убедиться)
p.s. Синьоров-разработчиков соответствующих написанному в статье за последние 10 лет видел от силы пару раз, а в среднем по больнице это ребята просто глубоко погруженные в конкретные язык/стэк технологий/предметную область (админы, дба, сетевики). В целом статья скорее про senior/teamlead devops.
Zmops
11.01.2022 19:18+1--Синьоров-разработчиков соответствующих написанному в статье за последние 10 лет видел от силы пару раз
потому что они почти все ушли в архитекторы. А те, кто не ушел, обзавелись лычками принципалов и экспертов.
Loriowar Автор
12.01.2022 10:30+2Справедливости ради и спора для хотелось бы заметить, что архитекторы — это не панацея и что места без архитекторов/принципалов/экспертов вполне себе существуют и неплохо живут. Там вокруг просто инженеры без всех этих лычек. Сами придумывают архитектуру, сами же пилят придуманное и потом поддерживают напиленное в работоспособном виде. Если что, я не про стартапчики из 2.5 землекопов, а про автономные компании размером в сотни человек.
Phoen
12.01.2022 18:00Спорить лень, а дисскуссию чего б и не поддержать? :)
А можно примеров таких компаний? Я к тому, что архитекторы бывают разные (ea, sa итд), и вот я как-то слабо себе представляю как возможно их отсутствие где-то, где основной бизнес завязан на IT. А лычки... При всей демократизации процессов в it, у кого-то все таки должно быть право последнего голоса, что впрочем обычно несет с собой и конечную ответственность за результат.
vedenin1980
12.01.2022 18:37слабо себе представляю как возможно их отсутствие где-то, где основной бизнес завязан на IT
Роль архитектора, конечно, кто-нибудь должен исполнять, но с этим может справится старший/ведущий разработчик, тим.лид, тех.лид, СТО и т.д.у кого-то все таки должно быть право последнего голоса, что впрочем обычно несет с собой и конечную ответственность за результат
Почему? Команда синьоров может решить архитектурные вопросы банальным голосованием (да и, как правило, у опытных специалистов редко возникают принципиально неразрешимые споры о архитектуре при которых нельзя придти к компроммису). Да и команда может нести конечную ответственность за результат тоже вместе.vedenin1980
12.01.2022 19:13А можно примеров таких компаний?
А что это вам даст? Можете посмотреть мой профиль на список мест, где я работал, выделенные архитекторы, которые имели право последнего голоса там скорее были исключением, чем правилом (если в одном проекте/команде — они были, то в другой команде/проекте той же работы — все решали сами программисты).
Вообще, agile, kaban и т.п. техники разработки не очень стыкуются с ролью выделенного архитектора с конечным голосом и конечной отвественностью. Архитектор с жесткой линией — «делай как я сказал» это больше про водопад. ИМХО.
Loriowar Автор
12.01.2022 19:38По большей части, я SA имел в виду. Все эти бизнес/ентерпрайз сущности, называемые архитекторами — это отдельная песня. Касаемо примеров: с ходу вспоминается revolut (хз как щас, но несколько лет назад он под описанный кейс подпадал), поменьше — kikoff, поближе — в Минске была пара таких компаний, осталось напрячься и вспомнить названия. Вообще, тут в пору вспоминать Спотифай, плоские команды и вот это вот всё.
Право последнего голоса, обычно, за владельцами компании. В большинстве приличных айти компаний они вполне себе вовлечены в процесс разработки и могут развернуть всё на 180 градусов, ибо деньги и компания их. А ниже них, при правильной организации и подборе персонала, никому нафиг не надо иметь такое право.
Если же копнуть глубже, то большинство случаев строгой иерархии в компании/команде я видел исключительно из-за низкой квалификации и сложности в поиске кадров. То есть, условно, дешевле и быстрее взять пучок мидлов и погонщика, чем хотя бы парочку отцов. Плюс, отцы могут банально не согласиться на однообразную муть, которую хочет бизнес. Отсюда логично вытекают юзкейсы плоских и вертикальных команд. Таки да, про плоскую компанию я ничего не говорю кроме случаев стартапа на 10 человек, где 90% так или иначе код пишут. Посему, иерархия в компании — это норма. Так же как с определённого уровня команды норма — это плоская структура.
HellWalk
11.01.2022 14:28+6Изучить очередной js-фреймворк при наличии знаний в программировании? Да не вопрос! Освоить новую фишку очередного языка программирования? Позвольте, это же давно забытое старое и мы это уже знаем!
Начали за здравие, кончили про упокой...
Если человек говорит, что между языками нет разницы - значит он, по-хорошему, не знает ни один язык.
Плюс мой жизненный опыт показывает, что действительно профессионалы не употребляют слово легко в принципе. Потому что не раз и не два сталкивались с ситуацией, когда казалась бы элементарная задача или проблема оказывалась на практике невероятно сложной.
Loriowar Автор
11.01.2022 14:55+2Между языками разница есть. Подчас она очень существенна. Но после нескольких языков уже сложно увидеть что-то радикально новое. Да, комбинации операторов и инструментов разнообразнейшие, подчас адаптированные под конкретную область (или даже аудиторию), но не более. И да, "80 на 20" автор так же не отрицает. Нюанс в том, что первые 80 могут быть освоены за пару недель-месяцев и этого хватит для большинства задач. А оставшиеся 20 да, довольно трудозатратны в освоении, наполнены очень необычными и красивыми вещами, но крайне редко применяются а боевых условиях, ибо поддерживать такое ну очень накладно.
Здесь я вообще вижу тренд, что как только появляется большАя потребность использовать те самые 20 процентов для реализации хотелок, то довольно быстро прокачивают язык, делают библиотеку или отдельный инструмент, дабы то же самое сделать быстро и просто. Посему да, можно сказать, что автор не знает ни одного языка программирования на достойном уровне.
SirEdvin
11.01.2022 15:12Но после нескольких языков уже сложно увидеть что-то радикально новое.
И тут на поле боя выходит golang, rust, dlang и так далее. То есть нет, в каких-то маргинальных формах их основные фишки вполне себе существовали, но как основное мейнстримное течение явное не использовались.
Причем нельзя же сказать, что эти фишки входят в 20% языка, которые можно не осваивать.
HellWalk
11.01.2022 16:20+1И да, "80 на 20" автор так же не отрицает. Нюанс в том, что первые 80 могут быть освоены за пару недель-месяцев и этого хватит для большинства задач. А оставшиеся 20 да, довольно трудозатратны в освоении, наполнены очень необычными и красивыми вещами, но крайне редко применяются а боевых условиях, ибо поддерживать такое ну очень накладно.
Не знаю о каких 80 на 20 вы говорите. Я с php работаю с 2008 года, и считаю что значительная часть знания этого языка заключается в понимании какие фреймворки использовать не стоит (к слову, не только я отмечаю, что хороший специалист это не только тот, кто знает как и что работает, а тот, кто также знает что использовать не нужно). Потому что можно сколько угодно пытаться сделать качественный продукт на Yii2 - это будет тоже самое, что плыть против течения.
А вот чтобы понять, что в языке есть, но использовать не нужно - нужны годы опыта и наблюдений разных проектов и команд.
Хотя и такое понимание приходит только тогда, когда перестаешь довольствоваться тем, что код «просто работает».
Сейчас изучаю Go в свободое время, и то, что я что-то написал на нем, и оно как-то работает - вообще не показатель знания языка. В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте. Через месяц работы - рассказать о судьбе проекта в будущем (жду, когда научусь это делать сразу на собеседовании).
В общем, знать синтаксис и уметь написать что-то, чтобы оно работало - это вообще не говорит о каком-то знании языка. Другое дело, что к сожалению кто-то на таком уровне и остается на всю жизнь.
GooG2e
11.01.2022 16:24+3Кто-то и до него не доходит) Видел я веб-разработчиков, которым показывал консоль разработки в браузере и они делали круглые глаза. И это были не джуниоры, а люди, которые лет по 10 этим занимались минимум.
Но вот именно такой опыт и экспертную оценку очень полезно иметь и перенимать - жаль, что не всегда такое есть
kirik
11.01.2022 18:35+1Знания того или иного языка != умению применить их в реализации той или иной задачи, увы) В моей жизни встречались разработчики, которые так глубоко закапывались в нюансы разработки, что порой забывали что они на самом деле делают. А ведь бизнесу нужен не классный код с применением самых модных паттернов, а, всё-таки, продукт.
В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте.
Очень сомнительное заявление, особенно про уровень команды, не обессудьте :)
michael_v89
11.01.2022 20:00+1Потому что можно сколько угодно пытаться сделать качественный продукт на Yii2 — это будет тоже самое, что плыть против течения.
На текущем месте работы я работал на 2 проектах, на Yii2 и на Symfony. Не сказал бы, что на Symfony происходит сильно меньше багов. Потому что баги происходят не во фреймворке, а в коде самого проекта, который пишут разработчики.
А еще в проекте на Symfony где-то там рядом Highload, и все эти правильные инструменты типа Доктрины кое-где выкидываются в пользу сырого SQL. Причем как раз на Yii можно было бы в условиях возросшей нагрузки продолжать пользоваться ORM, так как там и оверхед на создание моделей меньше, и вызовы QueryBuilder-а практически 1-в-1 мапятся на SQL.
В итоге фактическую пользу приносит только DI-контейнер, который есть во всех фреймворках, а там где нет, можно поставить какой-нибудь пакет через composer.И еще могу сказать, что по моему опыту с legacy на Symfony всегда было работать гораздо сложнее, чем с legacy на Yii и Laravel. Насколько бы ни был плохой код на Yii, там всегда можно было разобраться и переписать нормально, потому что там нет десятков интерфейсов фабрик декораторов, модифицирующих свое поведение аннотациями и магическими тегами в конфигах. И DI-контейнер не билдится по 3 минуты при каждом изменении конфига.
JustDont
11.01.2022 19:45Да, комбинации операторов и инструментов разнообразнейшие, подчас адаптированные под конкретную область (или даже аудиторию), но не более.
Вот только вы почему-то считаете, что это "не более", хотя на самом деле это скорее "не менее": знание/понимание наиболее выгодных комбинаций и приемов применительно к целевой прикладной области — это как раз то, что на практике отличает тех людей, которым имеет смысл платить много денег от тех, кому не стоит.
Сама по себе энциклопедичная полнота знаний при этом мало что стоит, хоть там 80% есть, хоть все 100%. Важна именно способность эти знания применить, а для сеньора — не просто применить, а еще и применить наилучшее и не применять хреновое.Ну и очень большая доля новых решений (новых, а не нескучных) — таки как раз имеет этот самый аспект новизны, не выражающийся в "комбинациях операторов и инструментов". Вам уже заметили про golang, rust, и прочие, а для прикладной веб-разработки есть typescript, который тоже можно "знать для решения большинства задач", но при этом напрочь игнорировать его основную концепцию, фигачить any везде, где типы выводить стало чёт сложно (видимо попало в 20%), и так далее. Это нихрена не сеньорский уровень, который выливается в продукты, развивающиеся потом исключительно силами мегасеньоров за N*крыло от боинга денег. Которые обычно лажают поменьше (или если лажают, то срочно чинят, пока никто не заметил), а потому хреновое качество кода уровня "годится для решения большинства задач" не превращается в проблему. Но при передаче в руки менее квалифицированного персонала это всё стремительно превращается в тыкву. Несмотря на то, что по сути производимых действий в них нет ничего сложного.
panzerfaust
11.01.2022 14:50+8Сразу скажу, что титулы "синьор реакта", "синьор AWSа" и подобные - это какая-то хрень... Синьор - это про фундаментальные знания и успешный опыт множества серьёзных разработок с применением этих знаний
Сразу скажу, что чемпион мира по легкой атлетике или чемпион MotoGP и подобные - это какая-то хрень. Чемпион - это фундаментальные навыки в спорте и успешный опыт множества соревнований.
Вот так вот легко сбросить мишуру с вашего основного тезиса.
Стандарта нет. Вот например на протокол TCP есть стандарт, а на квалификацию кодера нет. Поэтому нельзя сказать "реальный TCP - это когда розовые пони летят по проводам". Потому что есть стандарт. А про "реального сеньора" можно словоблудить хоть каждый день - что мы и наблюдаем.
Короче, у вас в трудовой написано "старший" и вы получаете по рынку как "старший" - все, achievement unlocked, вы сеньор. И никаким словоблудием вы этого не достигнете, если данный конкретный работодатель вас оценит ниже.
BetsuNo
11.01.2022 15:51+2Как мне кажется, вы путаете тёплое с мягким. Лёгкая атлетика и MotoGP - это не фреймворки, которые сегодня есть, а завтра нет (хотя на счёт MotoGP не уверен). Автор, опять же, как мне кажется, говорит о том, что набор фундаментальных знаний ценнее, нежели набор скилов, заточенных под конкретную технолонию.
SirEdvin
11.01.2022 16:01+1Да нет, очень правильная аналогия. Вот в олимпиаде есть метание ядра, которое отлично можно сравнить с cobol, к примеру.
Общий подход в спорте очень часто одинаковый, но вам нужно задрачивать конкретные действия. Так же можно предположить, что какой-то мастер спорта в смежном виде вполне сделает стандартного разрядника. Но смысл тезиса это не меняет.
splinehip
11.01.2022 16:05+1Тут ближе будет аналогия, что чемпион MotoGP на сузуки, а на ямахе уже нет )
siziyman
11.01.2022 16:16+2Вот только нет, не будет, потому что фронтэнд-разработчик на реакт-стеке и разработчик, не знаю, системных утилит на Си - это не люди, делающие одно и то же разными инструментами (мотоциклами). Это люди, делающие разные вещи разными инструментами.
MentalBlood
11.01.2022 14:55+12Ибо, например, после Си любой иной язык — это очень просто
Императивный, разумеется
emerald_isle
11.01.2022 16:23+2А что нужно знать, чтобы быть staff/principal/distinguished?
kaapython
12.01.2022 04:40+1В первую очередь уметь общаться с людьми, писать внятные, однозначно интерпретируемые тексты, уметь планировать и делать много полезного на уровне компании, а не только одного проекта. Staff Engineer: Leadership beyond the management track довольно хорошо это описывает. И, в общем случае, это уже не совсем разработчики в классическом понимании.
Neferot
11.01.2022 16:53+2"СЕНЬО́Р, -а, м. В средние века в Западной Европе: земельный собственник, обладавший властью государя на принадлежавшей ему территории." - мы все умные люди, и нормально можем интерпритировать это приложение в наши реалии =.=
"Лидер — лицо в какой-либо группе, организации, команде, подразделении, пользующееся большим, признанным авторитетом, обладающее влиянием, которое проявляется как управляющие действия."ПС. Зачем плодить сущности философствуя/размышляя - "а что это значит быть...". Как бы эти названия были не из воздуха взяты =.=
wolfy_str
11.01.2022 18:52+1Насчёт запада - тут можно сказать - кто-то хочет за бугор, кому родные берёзки милее. Чисто идиологический спор. Хотя есть позывы власти все щели закрыть и чуть ли ни границу.
Насчёт зарплат по "двадцаточке" - ну тут с одной стороны хайп, с другой дикое обесценивание доллара и уж тем более других валют. Многогранная тема про разделение на богатых и бедных, вымывание среднего класса, можно спорить бесконечно, только те же машины уже по полтинику штук долларов стоят в штатах для машины средней паршивости, а дом за 400к по медиане стоит, у нас так же дома и квартиры дорожают.
Да локальное падение цен на программистов возможно, но оно не более чем локальное.
Loriowar Автор
11.01.2022 19:50+1Запад, нынче, понятие растяжимое. Кому-то там хочется целиком находиться, а кому-то достаточно работы с ними из-под родных берёзок. Вирус и удалёнка это ещё пуще разбавили. Плюс, государство наше как обычно: с одной стороны щели конопатят, с другой стороны шикарные налоговые условия и любовь к входящей валюте. Поэтому, здесь поле для обсуждения и споров самое благодатное.
nameless323
11.01.2022 20:57+1и дисперсией, не поддающейся никакой оценке
Прочитал как "и депрессией, не поддающейся никакой оценке". В общем то все равно по смыслу подошло.
garwall
11.01.2022 23:26+2<irony>
Есть хорошая старая копипаста "Теоретический минимум программиста", думаю можно использовать в качестве отправной точки
</irony>
z0ic
12.01.2022 04:18-2Сеньоры и сеньориты, каждый месяц в конце месяца новенький спорткар под дверью. Главное требование - знание языка COBOL-XXX, никому не известный диалект применяемый в одном швейцарском банке специально для транзакций больше миллиарда долларов.
shybovycha
12.01.2022 07:47-1За годы успел повидать разное, и вот складывается впечатление, что на просторах СНГ (а если точнее - то конкретно для выходцев из СНГ, с таким вроди бы уже не СССР, но еще и несформировавшимся майндсетом) видение сениора - это про скилы и года опыта. Вот еще бы к каждому скилу - количество лет опыта с данной технологией приписать - вообще идеальный (анти-)пример получается. И ни слова про подход к решению проблем (тот же "майндсет"). И в то же время в западных кругах - с точностью до наоборот - сениором называют человека, умеющего решать проблеммы (именно что "проблеммы", а не "задачи"), а не накодить там чего, погрепать порты да понастроить сервера.
Loriowar Автор
12.01.2022 08:29+2Но всё-таки, оба подходя тесно связаны и не могут существовать друг без друга. Крайне сложно знать кучу инструментов ни разу их не используя (кроме случаев каких-нибудь мнемонистов и фанатов запоминания всего подряд) так же как крайне подозрительно уметь решать широкий спектр проблем не понимая чем и как они решаются (Ванга?). Имхо, оба подхода равноправны с более-менее одинаковым количеством плюсов и минусов, которые, однако, у каждого из подходов свои.
Myxach
12.01.2022 08:34+2Английский
Его бы стоит знать вообще всем, ну кроме работников завода.
Loriowar Автор
12.01.2022 08:40+2Думаю, последним тоже не повредит. Да и вообще, есть мнение, что каждый новый изученный язык крайне позитивно влияет на мозг и мышление. Так что пару языков надо бы в обязательный человеческий минимум включить. А ещё сколько-нибудь — в качестве факультатива и развлечения ради (ну и пользы для).
Dechjo
12.01.2022 10:30+1Стоит добавить ссылочку на "Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com" https://habr.com/ru/company/htmlacademy/blog/254825/
AlexanderS
12.01.2022 12:41+2Кстати, самая лучшая похвала в архитектуре, это когда на презентации результата тебе недоумённо говорят «и вот эти три квадратика вы два месяца рисовали?!» и больше никаких косяков найти не могут. То есть всё на столько просто получилось, что «очевидно же!» и не может туда быть закопано несколько сотен человекочасов.
В два-три квадратика любое решение можно врисовать) Так сказать «обобщённая схема». Я когда последнюю прошивку «рисовал» у меня ушло те же два месяца, но квадратиков было где-то три десятка и, самое главное, стрелочки с подписями обеспечивали «беспроблемные» связи квадратиков. Но про вопросы типа «чего тут два месяца рисовать» всё равно верно подмечено)
gecube
12.01.2022 13:45https://habr.com/ru/company/oleg-bunin/blog/501488/
https://slurm.io/from-middle-to-senior - видео выложены на ютуб, надеюсь, кому-то полезны будут
hungry_forester
12.01.2022 14:05+1Настоящий сеньор должен иметь вассалов...
Loriowar Автор
12.01.2022 14:57Честно говоря, я бы от этого архаизма перешёл к более практичному "иметь добрые отношения с ещё десятком синьоров и активно с ними кооперировать".
prohodil_mimo
12.01.2022 19:30По-моему, это уже "шашечки", а не "ехать".
Джун - это когда человек не может без посторонней помощи сделать работу.
Миддл - это когда человек может сделать без посторонней помощи работу.
Сеньор - это когда человек может предложить сделать эту работу самым оптимальным способом, а заодно и подсказать "снизу" что-то по рискам проекта - по технической части, не по договору или надёжности клиента.
Соответственно, сети, файловые системы и инглиш - это инструменты выполнения работы, а не цель. И тогда непонятно, зачем мне, например, сети и файловые системы, если я, скажем, калькулятор калорий на андроид делаю? Или фронт на интернет-магазин.
Loriowar Автор
12.01.2022 19:53+1Если душа не просит приключений и калькуляторы калорий клепать норм, то и проблемы нет. Но, обычно, во-первых, всегда хочется бОльшего, а во-вторых, сани хорошо бы готовить летом, иначе говоря, когда внезапно понадобилось понять что с сетью/осью или иной штукой, то курить мат.часть поздно.
Ну и в вашем определении сеньора часть про "делать эту работу самым оптимальным способом" очень сильно намекает на широкий кругозор. Слишком много раз я видел, когда заказчик не понимал что хочет на самом деле. Без кругозора и некоторого опыта просто делается что запросили, но это далеко не оптимальная штука. Точнее, это локальная оптимизация в рамках ограниченных познаний, а не глобальная оптимизация в рамках исходной проблемы.
prohodil_mimo
13.01.2022 11:35Калькулятор калорий - это тоже работа, точно такая же, как ПО для ракет Маска или ГТА 5. Там тоже есть ТЗ, планы, бюджет, РП, программисты и т.п. И главное - там есть бизнес, который понятия не имеет ни о каких сетях и файловых системах и которому нужен только конечный продукт. Соответственно, каждый участник этого проекта должен быть максимально полезен для этой (единственной!) цели, иначе непонятно, зачем его нанимать и платить ему деньги.
Поэтому, если, например, я собеседую сеньора (или миддла, или архитектора, или РП) на этот проект, то мне важно только одно - насколько они будут полезны для выполнения этой задачи. И если этот сеньор, например, понятия не имеет о сетях, но знает и доходчиво объясняет, на чём мне писать этот калькулятор, а на чём не писать, быстро осваивает ТЗ, с вопросами-предложениями, и в целом понимает, как нам успешно сдать этот проект - он мне подходит. Не понимаю, зачем бы я вообще спрашивал о сетях, если у меня на проекте их нет?
То, что вы описываете, бонус, а не цель. Да, неплохо бы, чтобы этот сеньор знал сети, файловые системы, 5 иностранных языков и 25 ЯП, в т.ч. ассемблер, мог взломать пентагон с кнопочной нокии, умел красиво танцевать и петь, летать и жить на дне океана - мало ли что из этого теоретически может понадобиться на каком-то из проектов? Такие бонусы могут быть полезны, например, если человек идёт работать в Гугл. Там очередь из желающих, все они отлично знают всё о любом проекте и как его сделать, а выбрать как-то надо. Тут уже такая же система, как у богача в автосалоне - на его деньги можно купить любую машину, каждая из них будет ездить, поэтому надо выбирать по максимуму допов.
Но не Гуглом единым жив этот мир. Есть множество работы по "обжиганию горшков". И там тоже нужны кадры.
sdudnik
12.01.2022 21:48+1Статья, видимо, хорошая, но из-за излишка сюсей и пусей абсолютно нечитаемая. Автору спасибо за труд, однако.
PNSpasskiy
13.01.2022 13:36+1Потом попадаешь на собес к синьору с такими взглядами и руки опускаются. Про это тут много историй, когда джун приходит формочки на сайт клепать, а с него матан и нанэ технологии спрашивают.
Стремление к постоянному развитию и получению новых знаний, это очень хорошая штука. Но не нужно забывать о синдроме, когда те знания, на получение которых лично мы затрачиваем годы жизни, в дальнейшем нам почему-то начинают казаться элементарными и обязательными для всех и каждого.
Хорошо, когда самообучение и развитие это хобби. Плохо, когда начинаешь своё хобби навязывать всем и каждому.
Может быть отсюда и растут ноги у выгорания?
Loriowar Автор
13.01.2022 15:03+1Имхо, это не есть следствие большого багажа знаний собеседующего, это, скорее, его личные тараканы из области воспитания/психологии (тут ещё детские травмы любят упоминать, но это на любителя). Когда выучил кучу всего, а потом начинаешь этим над головой махать перед каждым собеседуемым, повышая ЧСВ или свято веря что всё это надо знать и уметь. Навык интервью — это вообще отдельная сложная штука, о которой у нас никто не говорит. Хотя и стоило бы. У меня была пара статей по этому поводу. Но там слишком большая тема, чтобы хоть как-то её в тексте изложить. Поэтому за всех не скажу, кажу только за себя: исповедую подход, когда после интервью человек уходит в лёгкой задумчивости и со знанием чего-то нового. То есть интервью — это двусторонний процесс, а не допрос или способ закрытия личных потребностей в доминировании. Поэтому вести его приходится очень по-разному. Для этого хорошо бы иметь хороший багаж знаний, дабы к одной и той же теме была возможность подойти с разных сторон, чтобы кандидату было комфортнее, ибо интервью — это в любом случае стресс и первым делом надо найти такой путь, который будет наиболее удобен/приятен кандидату, чтобы он показал свои реальные знания и опыт, а не переживал за то как выглядит в глазах других и как бы удовлетворить ответами "экзаменатора". Ну и развлечь кандидата — тоже полезно, если есть время и возможность. Тогда, при любом исходе собеседования, тебя и компанию запомнят и либо порекомендуют знакомым, либо позже ещё раз зайдут.
А касаемо выгорания, тут могу прямо противоположный аргумент привести. Желание изучать всё подряд — это хороший путь прямо в противоположном направлении от выгорания. Когда изучаешь что-то вообще не из рабочей среды — это всегда отдых, любопытство, интерес и переключение на неизведанное, то есть отвлечение от основных дум и отдых для мозга. Кто-то резьбу по дереву в гараже практикует между митингами и кодописанием, кто-то в хоре поёт, на квадрокоптерах летает самосборных или психологию изучает. Опять же, могу пример из своей жизни привести: если заглянуть в профиль, то года полтора назад у меня несколько статей про биологию было. Просто интереса ради копал молекулярную биологию и иммунитет. Нахрен не нужные знания для разработчика… но потом случился коронавирус и пригодилось. Плюс, нашлись очень прикольные связи биологии и разработки, что помогло по-новому посмотреть на давно известный процесс. Так что никогда не знаешь что и где пригодится. Поэтому, имхо, лучше всегда искать что нравится и изучать это, чем верить в то, что знания могут быть лишними и бесполезными.
morgangso
Достаточно хорошо знать проект на котором работаешь
Loriowar Автор
А что нужно знать, чтобы быть в состоянии понять проект?
SirEdvin
А это зависит от проекта.
Loriowar Автор
А можно ли выделить базовый набор навыков/знаний, чтобы зависимость от проекта минимизировать или вообще заменить зависимостью от предметной области? То есть не под каждый новый проект требования придумывать, а использовать одни и те же, которые закроют бОльшую часть случаев?
SirEdvin
Проблема в том, что нельзя. У меня не то, что бы прям большой опыт (где-то 6 лет), но я уже успел побывать на разных проектах. Часть из них требовала просто несколько недель онбординга, что бы человек начинал писать код, часть из них была построена так, что серьезное знание предметной области требовалось только от одного человека, а часть их них содержала только знания предметной области.
Разумеется, если вы строете проект и у вас хватает возможности проконтроллировать все, то у вас может и получится. Но синьор вроде не строит проекты, он на них работает.
GooG2e
Я уже лет пять работаю вот примерно в таких же проектах, где нужно погружение в предметную область, но вот чем больше работаю, тем больше прихожу к мысли, что необходимость прям сииильного погружения в предметную область возникает, если либо процессы выстроены неправильно, либо собственно сама архитектура проекта построена так, что не понимая всего ты не можешь понять частности.
Правда как бороться с этим в состоянии вечных дедлайнов не особо понятно(
olegbask
Ну это уж точно не ОСи, деревянные pid'ы и ключики к sed...
Loriowar Автор
А почему это точно не они? И что же тогда должно быть в списке вместо них?
RealPeha
Достаточно долго на нем работать
palage4a
Достаточно для чего? Для того, чтобы трястись за свое место, пока не придет "молодой и удалой" заместо тебя?)
MaksimusDecius
Судя по количеству перечисленного, для того, чтобы одному выполнять функции целой команды.
Loriowar Автор
А что в этом плохого? Нынче, много знать и уметь уже зазорно? Или обидно, что за такой широкий спектр работ не будут доплачивать? Кто же мешает отстаивать свои убеждения и привлекать упомянутого в тексте "продажника", чтобы труды за команду оплачивались сообразно результату, а не кол-ву человек, выполнявших работу?
Zmops
Так и появляются синьоры и архитекторы "одного проекта", лиды и ПМы одного департамента.
usv_usv
Синьор 1 проекта, это вовсе не синьор в широком смысле. Если пройти весь проект с нуля то по твоему выходит целая команда синьоров получится.
Но по факту на других технологиях и других ЯП все они могут оказаться джунами.
highter
вот поэтому и существует такое понятие как "матрица компетентности" (https://github.com/omreps/programmer-competency-matrix), чтобы понять кем твой коллега является
saboteur_kiev
Ну это вы путаете сеньорность и ключевая позиция на проекте.
Сидя на одном проекте, можно не понять что может быть иначе. Потому что по верхам ты может быть и почитаешь но без нюансов - нет, а в нюансах весь смысл.
Kanut
И при смене проекта или даже работы такой сениор автоматически снова становится джуном? Или как?
progreccor
и не выгореть на этом проекте...