Comments 44
Все время удивляюсь как оказаывается таких мудрых правил именно семь? Колдовство какое-то...
В радуге сколько угодно много цветов. Но когда Ньютон разложил солнечный свет с помощью призмы в спектр, он насчитал семь, ну немного исхитрился в подсчёте, чтобы цветов получилось ровно семь. Семь нот, семь планет (тогда было известно столько), ну и цветов по мнению Ньютона, очевидно тоже должно было быть семь.
Ну это как финальные доработки в последний день дедлайна, хотя проект длился нескольео месяцев а то и год :)
порой наивность прям таки убивают... джун, мидл и сеньор - это сейчас по сути своей должности, то есть ставки. Есть ставка - кого то двинут, нет ставки - все сидят на своих местах и от опыта это зависит почти ни как... понятно, что при наличии ставки и отсутствия внутренних кандидатов по той или иной причине, например, мало опыта никого на сеньора двигать не станут, но вот если ставки нет - да хоть ты венду сам с нуля напиши - так и будешь ждать освобождения вакансии.
Это романтические представления времен "большого взрыва" айтишечки (особенно на постсоветском пространстве) N лет назад. Когда молодой да юный на старте пишет хелловорлд за пачку доширака, через пару лет он уже неплохо оплачиваемый специалист, свысока смотрящий на десяток таких, каким он был пару лет назад. Еще через пару лет он, или хотя бы сын маминой подруги - почти небожитель с джипом той же модели, что и у директора ближайшего ларька. А т.к. гребли в индустрию в основном "до 30-и" этот аттракцион неслыханной щедрости ими мысленно экстраполировался на всю видимую часть вселенной. Без моделирования ситуации куда же будет расти джун/мидл, когда в компании уже все забито под завязку старпёрами с 2-х/4-х летним опытом, а вселенная расширяется уже не так быстро :)
Джун это не состояние а уровень ответственности.
Это самое универсальное объяснение работнику, почему его всё ещё не повышают: Да, Olku, ты хороший специалист, и твоя компетенция не вызывает сомнения, но тебе нужно больше ответственности!
При этом что это за ответственность такая не знает никто. Но объяснение работает на отлично. Работник уходит ковыряться в себе и изыскивать способ изменить себя, чтобы избавиться от фантомных недостатков, а босс потирает руки, довольный тем, что ещё один лопух купился на этот фокус.
Мне кажется то что я 1, 6 и 7
Я давно в профессии, но на зарплате джуна. Тестов от меня никогда не требовали, ревью никогда не делали и я сам не делал, временные решения бывают, сеньором не притворяюсь, нейросетями практически не пользуюсь.
Авторы статей почему-то как правило пишут об айти, где всё красиво, правильно и дорого. Полагаю, чтобы туда устроиться — нужно академическое образование либо сильная увлечёнеость. Наверное, работникам галер просто не о чем писать, поэтому такой перекос.
Спасибо, озвучили реальность.
Знакомая ситуация. Я взял за правило в среднем каждый месяц проходить минимум одно собеседование. Просто чтобы понимать, что актуально, сколько платят, кто я по уровню. Ну и что-то получше найти таким способом всяко проще, чем ждать, что "куда-то позовут".
Мне работа всегда попадалась как-то сама собой. Недавно встретил бывшего коллегу, попросил его найти мне вакансию. Он поузнавал и сказал, что там, где он думал, сейчас туго с айти-направлением. Видать, пока не пришло время. Когда придёт, работа сама найдёт меня. Полагаю, я ещё не готов. Вместо того, чтобы заполнять пробелы в знаниях по своей специальности, мне интереснее изучать новый язык, который может вообще не пригодиться. А может быть, это моя будущая работа, я не знаю.
какие-то наивные рассуждения и не менее наивные выводы. Делать как раз стоит наоборот. плыть по течению можно но не постоянно. отдохнули и сновыми силами в бой.
Сам, от части, являюсь таким же и мне кажется, что вы правы на счёт увлечённости.
Разработчики занимаются решением проблем. Путь к росту лежит через самостоятельное решение проблем. Думалка на этом пути у большинства людей весьма ограничена. Когда мы сталкиваемся с сложными задачами в условиях дедлайна - не всегда есть возможность вникнуть на достаточно глубоком уровне, но, к сожалению, такое оправдание очень легко входит в привычку:
Закралось подозрение в повторении участка кода - не проверил, возможно, отложив на попозже.
Не обдумал возможные дальнейшие шаги после реализации решения и просто сделал, что требуется сейчас.
Дописал фитчу и быстро закрыл задачу вместо ещё одного взгляда. Возможно где-то нужна декомпозиция?
Таких примеров можно придумать множество...
Если смотреть под таким углом, то все это выглядит, как лень и попытка оправдать себя. Единственный способ расти в такой ситуации - это действительно тяжёлая работа, в первую очередь, над самим собой.
Без увлечённости, сформировать новые привычки или изменить старые - будет на несколько порядков сложнее.
Редко встречаю материал с которым согласен на 99% в данном случае все расписано идеально, ни добавить ни убавить.
Знаю огромное количество примеров подтверждающих статью.
Единственное все-же с чем не согласен это с тем, что описаные это признаки "джуна", тут описаны признаки не дают стать настоящими сеньерами.
Не пиши «TODO» просто в коде. Создавай полноценную задачу в трекере с описанием проблемы и желаемым решением. Так о ней не забудут.
Это если есть трекер. И если есть проблема. Мой проект, как правило, при сборке выдает пяток варнингов, все они результат кода типа
#warning FixMe: I don't know border value now
#warning ToDo: This time input garbage ignored. May be error generated here?И даже если трекер есть, то я добавлю сюда код в трекере. Ошибки и предупреждения при сборке мозолят глаза. И когда их становится критично много с ними приходится или как-то бороться или удалять как неважные.
Безусловно, такой подход требует написания "чистого кода", в котором собственные предупреджения не потеряются на фоне многочисленных предупреждений компилятора (к слову ненавижу VHDL за генерацию простыни предупредений в абсолютно любом проекте - но это и не про программирование как таковое). Впрочем, мне кажется что это просто правила хорошего тона, и говорить о их соблюдении как-то странно. Они или безусловно соблюдаются, или безусловно игнорируются.
Пока автор рефлексирует о «грехах старого джуна», моя реальность — это дедлайны и требование простого, рабочего кода КАК МОЖНО БЫСТРЕЕ. Я просто пытаюсь закрыть задачи в срок.
9 из 10 синьоров, которых рынок воспринимает как джуниоров, буду иметь как раз противоположные проблемы: они делают много сложной конкретной работы и в это время полностью выпадают из актуальных трендов технологий. Т.е. синьор годами поглощен конкретными проблемами конкретного проекта и больше не может не то что поверхностно рассуждать о модных концепциях, но вообще о них толком не слышал.
Автор с 25-летним стажем строит всю статью вокруг модели J/M/S, которая массово пришла к нам лет 15 назад. Получается, целых 10 лет автор как‑то жил и работал в IT без этих священных грейдов. Хотелось бы узнать, как тогда выглядела «стагнация» или «рост»? Неужели за те 10 лет автор не увидел, что IT бывает очень разным и не всегда укладывается в прокрустово ложе J/M/S?
Он не может объяснить технические концепции простыми словами.
Верно подмечено. Пожалуй это самое значимое. Это фактически означает, что «джун в маске сеньора» не понимает физики кодируемого процесса. А спросить у кого-либо это ниже его "достоинства".
Тут самое время воспользоваться советом:
Всё начинается с честного взгляда на себя.
Стоит добавить - чтобы развить в себе способность объяснить что-то, нужно попробовать себя в роли ментора, хотя бы проводить вебинары и отвечать на вопросы. И даже если какую-то не особо сложную тему ты, казалось бы, знаешь хорошо, то когда готовишь презентацию, подготавливаешь стенды, виртуальные машины, и т.д. - прорабатываешь массу нюансов, и когда рассказываешь новичкам это - сам находишь "белые пятна", которых и сам не знал. Последующие вопросы от новичков приносят ещё больше такого опыта, т.к. бывают настолько необычные, но по теме, что сам бы не стал даже в эту сторону смотреть, и это самого заставляет развиваться.
Кстати, можно скачать по своему направлению программу любых курсов и по каждому разделу задать себе вопрос: "готов ли я провести про это занятие и объяснить другим?". Если да - ок, проведи, и посмотри что получится. Нет - вот и готовое направление для собственного развития. Единственный нюанс - часто бывает человек профессионал, но в плане "рассказать другим" всё очень печально, тут всё-таки несколько отдельный навык (который тоже можно развивать). Часто такие люди думают "мля, мне проще самому за 5 минут сделать, чем этим идиотам объяснять полчаса" (и делают за 5 минут).
Посмотрел тут пару бесплатных "уроков" от одной известной обучающей российской конторы, так выглядят просто удручающе. А казалось бы - лектор! Кстати, деньги получают смешные.
Но в то же время очень распространён подход "гугли только задачи, которые встали перед тобой, остальное тебе пока не нужно". Когда я говорю, что готов начать чем-то пользоваться, когда прочитаю штуки 3 учебника про это, меня начинают убеждать, что так я никогда не начну. Кому верить?
Просто читать учебник не очень полезно. Надо параллельно пробовать то, о чëм прочитал. Даже если кажется "да тут всë понятно, код простой", через пару глав может стать " что тут вообще происходит? ".
И да, для себя я пришëл к выводу, что не нужно изучать новый софт, технологию или фреймворк/библиотеку, если это сейчас или в ближайшем будущем не понадобится. Иначе это просто забывается, и время потрачено почти зря. Вот и получается, что со временем обрастаешь опытом и знаниями именно в тех вещах, с которыми на практике работал.
Хотя многие базовые области в любом случае стоит изучать - типа работа в linux, основы сетей, git и т.п.
Не-не, я не о "пробовать". Конечно, я пробую, потому что не всем дано доходчиво словами объяснить то, что они понимают в голове. Разным людям требуются разные объяснения, поэтому универсального учебника не придумать.
Я о том, чтобы начать применять в работе, писать в резюме, говорить, что я хотя бы ознакомился с технологией.
На данный момент я прочитал один учебник по Go, одну брюшюрку и ещё 100 страниц другого учебника из 650 страниц. Мне не хватит совести сказать, что что я имею представление о Go как о языке. Я где-то видел, что внутрь файла можно встраивать фронтенд-часть web-сервиса, также я знаю, что в какой-то момент появится тип any, что там будет [T any]. Я этого пока не изучал, поэтому я имею представление лишь о каких-то аспектах языка и, как я считаю, не имею права применять его в работе.
А что насчет предметной области? Вот пришел реакт сеньер помидор, любитель ci/cd, весь тестами покрыт, литкод весь прорешан, знает ddd, tdd, solid и кучу луковых архитектур и эвент сага квери сорсеров. И оказывается ее может в 3d графику на webgl. Сеньер ли он?
А сага нужна во фронте?
Конечно, вы же можете одновременно вызывать несколько апишек, и нужно отслеживать успешное выполнение. https://redux-saga.js.org/
Все хорошо, но почему ревью женского рода?)
Круто, такая же статья нужна для статей на хабре. Чтобы люди перед тем, как статьи писать, проверяли её - не является ли она рекламой, не пишешь ли ты её исключительно чтобы показать, что ты нетакуся, а все вокруг джуны, не пытаешься ли ты выдать себя за того, кем не являешься, не выставляешь ли ты текущего себя за эталон идеального программиста и т.д. и т.п. Статья выглядит как попытке потешить эго, но работа программиста - принести бизнесу деньги. И если сеньор приносит больше, чем получает, пусть он хоть в клоунском костюме на работу приходит и разговаривает только мемами.
Статья написана как бы для разработчиков, но на самом деле - с позиции менеджера.
Это не признаки профессиональной стагнации, а признаки того, что разработчик неудобен для типового менеджера. Ну и недостаточному уровн. квалификации можно отнести только признаки 1,2.
Подробнее по пункатам:
Признак №1 — Джун в маске сеньора
Это не джун, это - вообще человек с другим психотипом, чем тот, который менеджмент желает видеть у разработчика. Этот человек по факту исповедует принцип "казаться, а не быть", В качестве разработчика он, скорее, не на своем месте. Ему бы продажником работать - но продажникам так мало платят!
Признак №2 — ИИ-зависимость
Человек нашел легкий способ делать то, что от него требут - за что его осуждать? Ну, не надо от него требовать решения нестандартных задач - на это в группе разработки найдутся другие люди.
Признак №3 — Мастер временных решений
Это - вообще не джун. Человек реально преобрел нехилую такую квалификацию решать поставленные перед ним задачи здесь и сейчас. Лично мне, кстати, умение засунуть свое чувство прекрасного не буду говорить куда и сделать хоть как-то, но быстро пришлось осваивать с приходом в программирование за деньги, что случилось после многих лет моих типа занятий программированием. Ну, а какие разработчику задачи ставить - это уже задача манджера. Ответственность за качество кода - это его ответственность, а не разработчика. Разработчик же отвечает только за исполнение установленных на предприятии правил. Вот и устанавливайте правильные правила.
Признак №4 — Переусложнитель
Примерно то же самое, что и в предыдущем пункте, но с противоположным знаком.
Признак №5 — Скоростной гонщик
Ни разу не джун - наоборот, больше похож на "настоящего программиста" из тех, что не пользуются Паскалем. Тут опять-таки, забота о поддерживаемости кода - это проблема менеджера. Вот пусть менеджер и выдвигает требования по покрытию тестами (только пусть не забудет дать в три раза больше времени на ту же задачу), на документацию и т.д. Или - находит ведомого, который будет "прикрывать хвост" асу, делая всю эту нудятину.
Признак №6 — Архитектор незаменимости
С позиции разработчика он не делает ничего плохого, даже если он действительно заботится о собственной незаменимости. Это забота менеджера, чтобы было как у Сталина "незаменимых у нас нет". Ну а, кроме того, причина такого стиля работы - не обязательно в желании быть незаменимым. Иногда у разработчика просто мысль сама по себе ходит сложными извилистыми путями. Если чо, я такое видел на практике.
Признак №7 — Мастер пустых ревью
Делать ревью - это в интересах не разработчика, а менеджера. Наемный разработчик в качестве кода вообще объективно не заинтересован, ибо код ему не принадлежит. Так что нет ничего плохого для разработчика в том, что он не действует в чуждых ему интересах и не надо его за это стыдить. А если менеджеру это не нравится - пусть он устанавливает и уточняет правила.
И последнее. Я тут гляжу, что по всем пунктам прописан выход из какой-то там "ловушки". Для разработчика тут никаких ловушек нет. Точнее - они есть исключительно тогда, когда это приводит к снижению его зарплаты. Поэтому, прежде чем выходить из ловушки путем, предложенным в статье, стоит задуматься, во-первых, надо ли выходить вообще, а во-вторых, - не стоит ли это делать другим путем, например, сменой места работы (а в п.1 - так вообще в позиции в рамках ИТ).
7 признаков профессиональной стагнации разработчика