Комментарии 34
Все время удивляюсь как оказаывается таких мудрых правил именно семь? Колдовство какое-то...
В радуге сколько угодно много цветов. Но когда Ньютон разложил солнечный свет с помощью призмы в спектр, он насчитал семь, ну немного исхитрился в подсчёте, чтобы цветов получилось ровно семь. Семь нот, семь планет (тогда было известно столько), ну и цветов по мнению Ньютона, очевидно тоже должно было быть семь.
Ну это как финальные доработки в последний день дедлайна, хотя проект длился нескольео месяцев а то и год :)
порой наивность прям таки убивают... джун, мидл и сеньор - это сейчас по сути своей должности, то есть ставки. Есть ставка - кого то двинут, нет ставки - все сидят на своих местах и от опыта это зависит почти ни как... понятно, что при наличии ставки и отсутствия внутренних кандидатов по той или иной причине, например, мало опыта никого на сеньора двигать не станут, но вот если ставки нет - да хоть ты венду сам с нуля напиши - так и будешь ждать освобождения вакансии.
Это романтические представления времен "большого взрыва" айтишечки (особенно на постсоветском пространстве) 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/
Все хорошо, но почему ревью женского рода?)
Круто, такая же статья нужна для статей на хабре. Чтобы люди перед тем, как статьи писать, проверяли её - не является ли она рекламой, не пишешь ли ты её исключительно чтобы показать, что ты нетакуся, а все вокруг джуны, не пытаешься ли ты выдать себя за того, кем не являешься, не выставляешь ли ты текущего себя за эталон идеального программиста и т.д. и т.п. Статья выглядит как попытке потешить эго, но работа программиста - принести бизнесу деньги. И если сеньор приносит больше, чем получает, пусть он хоть в клоунском костюме на работу приходит и разговаривает только мемами.
7 признаков профессиональной стагнации разработчика