Комментарии 48
Я познал уровень своей квалификации, когда занимаясь любимым делом (программирование), создал проект, который приносит доход, сопоставимый с очень хорошей ЗП senior или тимлида. До этого пробовал многое, но таки добился своего. Но у меня и цель была работать на себя и не зависеть от "дяди".
Работа становится лёгкой и однообразной, нет ощущения вызова
А она всегда такой была О_о Это ж кто как место работы выбирает
разговаривать с непосредственным руководителем и просить задачи сложнее, брать больше ответственности.
Насколько я себе представляю, начальство просто выделить больше часов работы каждый день, чтобы увеличить нагрузку. Потому что, если им нужно сверстать страничку, то никакой сложности в этом не прибавится, разве что сверстать две странички.
По поводу лёгкости - мне либо по жизни не везёт, либо я сам ищу работу, в которой прям сложно
Да, важно просить не больше задач, а задачи сложнее. Если их в компании нет, тогда и роста в компании тоже нет(
Попросил у компании время на самообразование. Ответили, что это можно, если я письменно опишу, почему им это выгодно. Вспомню школьный опыт написания сочинения нужного размера на любую тему.
Они не найдут более сложных задач, пока я не начну движуху по их внедрению и продвижению. У них-то и так всё работает и шевелится, зачем им что-то менять?
а если опыт 30 лет, то кто тогда?
Как я иногда над собой шучу на очередной свой ДР.
Я: жена, нам сегодня не звонили на домашний?
Ж: Откуда
Я: из пенсионного фонда
Шутка, конечно, но дальше, IMHO, идёт Эксперт или Инженер с большой буквы. А, это позиция может шлифоваться бесконечно долго :)
Ведь только такой Спец может уверенно сказать: "Trust me, I'm an Engineer"
опыта или стажа?
outdated, expired и legacy :)
У нас опыт больше 30 лет, но в реальности всё что лежит за пределами 10 летнего опыта - либо устарело либо забыто и годится только для побурчать на тему "а вот в наши времена"©
У более умных товарищей правда есть еще human networking, но тут мы мало что можем сказать, т.к. не прокачивали это в принципе.
Есть ещё один момент.
Если человек реально спец старой школы, он не попадает во все эти сетки, грейды и специализации. Просто потому что для айтишника старой школы всего этого не существует.
Условно, один из моих знакомых был IT-директором в нескольких банках, знает банковский бухучет не хуже главбуха; может спокойно залезть софтайсом в ядро винды и пропатчить пару dll-ок по своему усмотрению; прекрасно админит как винды, так и линуксы, в равной степени легко пишет хоть на C# с хранением данных в mssql, хоть на php с хранением в постгресе, которые он же и админит, техлид финтех-конторы, инфраструктуру и все процессы которой строил сам.
Кто он? Админ? Разработчик? Девопс? Менеджер? Да всё сразу. Просто потому что для олдскула есть просто IT в широком смысле. И таких людей я знаю немало.
Но по факту, у таких людей код - лютая мотня, которую могут поддерживать только они сами. Потому что пробелы знаний в лучших практиках того же дотнета по верхам не схватишь. Я очень часто замечаю, что специалисты старой школы не знают что такое контейнеры, инверсия зависимостей, они не пишут нормальных модульных тестов и плохо работают в команде. Это супергеройская разработка человека самоучки, которая оказывает медвежью услугу всем участникам процесса. Работодатель получает басфактор, а исполнитель - огромную кучу проектов, которые нужно поддерживать.
Не без этого. Потому что тесты, инверсия зависимостей и ещё очень многие паттерны и идеологии наподобие того же DevOps - это костыли, придуманные рынком в ответ на массовое снижение квалификации IT-специалистов.
Да, в ситуации, когда над простейшей задачей должны работать 8 человек, потому что придумывает один, разворачивает инфраструктуру другой, деплой настраивает третий, а ещё пятеро кодят, потому что у каждого в голове не укладывается больше одного экрана кода - становятся жизненно необходимы тесты, деление на микросервисы и прочие обвязки.
Когда же это всё может сделать один инженер - ему не нужен сине-зелёный деплой, не нужны юнит-тесты и не нужна команда.
У нас с коллегой был случай однажды: звонят из одного банка, куда коллега ещё лет за 10 до того момента продал самописный софт. Мол - сломалось, помогите. Пришли, стали смотреть. Оказалось, что на сервере, на котором это всё крутилось 8 лет, сдохли диски, но этого никто не заметил, потому что сервис работал в памяти и ничего никуда локально не писал - и в этом состоянии сервер проработал ещё два года. Ну а после ребута, понятное дело, машина уже не поднялась.
То есть изначально код пишется с расчётом, что он будет работать вечно. Люди, писавшие софт, когда оперативка измерялась десятками килобайт, умеют писать так, чтобы не допускать утечек памяти и лишних операций. На кой чёрт им контейнеры, если движок докера упадёт раньше, чем собственно приложение, состоящее из одного исполняемого файла, собранного статически, а весь деплой заключается в копировании этого файла и запуске его?
Потому что тесты, инверсия зависимостей и ещё очень многие паттерны и идеологии наподобие того же DevOps - это костыли, придуманные рынком в ответ на массовое снижение квалификации IT-специалистов.
Не только. Это все бывает очень полезно при работе с очень объемным проектом, который просто никто не в состоянии удержать в голове полностью.
Другой вопрос, что всеми этими практиками часто злоупотребляют, иногда даже исхитряясь получить противоположный результат - дополнительное увеличение сложности разработки и общее снижение качества.
А потом ваш супергерой ушел на пенсию или ушел на более жирную котлету, а вам в наследство остался проект, на который вы на рынке не найдете специалиста для поддержки. Даже если у вас будет какая никакая документация, руководства, КД, ТЗ и куча другой макулатуры, это все против нескольких лет разработки в уникальном костыльно-прикладном стиле ничего не стоит.
Да, здесь согласен. Именно поэтому динозавры, кто остался в рынке, тоже вынуждены изучать нафиг не нужный им докер. Впрочем, для них это ещё одна технология из сотен уже изученных.
Именно поэтому динозавры, кто остался в рынке, тоже вынуждены изучать нафиг не нужный им докер
Про ненужность докера не согласен. И динозавры вряд согласятся - они, скорее всего, тоже с "адом зависимостей" по жизни сталкивались. В худшем случае - ещё и когда виртуализации на базе VM не было (ну как не было, у IBM от VM/SP до z/VM она с незапамятных времен была).
Другое дело, что докер - это инструмент скорее для эксплуатационщика, а не для разработчика. Разработчиов им менеджеры напрягают, особенно те, которые которые поэффективнее, чтобы заставить разработчика делать дополнительную работу за те же деньги.
Ад зависимостей можно разрулить самыми разными средствами, на докере свет клином не сошёлся.
Какое-нибудь веб-приложение вполне можно запаковать в deb-пакет, например. Когда доступна гипервизорная виртуализация и под отдельный проект вполне можно развернуть отдельную виртуалку - на кой бы чёрт в ней поднимать ещё и докер - особенно если речь идёт о сайтике на php? Как бы кощунственно нынче это ни звучало - подчас проще залить проект по sftp руками, чем потом разбираться с контейнером. У меня был случай - отдали виртуалку с небольшим сайтом, в котором надо было поправить пару строк. А он в докере) Вытащил, конечно, и поправил, но времени ушло на порядок больше, чем если бы он просто лежал в /var/www.
Или вот эти разговоры о том, что докер-окружение, мол, позволяет получать одинаковую конфигурацию у разработчика и на проде. Чёрта пухлого она будет одинаковой, если в контексте разработчика связка поднимается под docker-compose локально, а в боевой среде - под кубернетесом с его ингресс-котроллером, ещё и с лоад-балансингом и с кластером БД на выделенных физических машинах.
Нет, я не отрицаю, у докера и кубов тоже есть своя область применения. Когда это уровень какого-нибудь Яндекса или ВК, с командами девопсов и SRE, которые умеют это всё приготовить и где действительно нужны фишки контейнерной виртуализации с деплоем десятков тысяч микросервисов на тысячи нод. Но пихать докер куда ни попадя, с учётом всех минусов лишних слоёв абстракции - ну такое себе.
А в такие конторы динозавры обычно и не пойдут - им там и делать нечего, да и не возьмут их. Широкая специализация там не нужна, а вот упомянутый бас-фактор действительно для них играет роль, там проще сотню джунов-шестеренок нанять.
А потом ваш супергерой ушел на пенсию или ушел на более жирную котлету, а вам в наследство остался проект, на который вы на рынке не найдете специалиста для поддержки.
Вы - менеджер? Тогда я понимаю вашу печаль. Но не сочувствую: я - не менеджер, а вы - нанимайете настоящего программиста ( за другие деньги, да ).
А у наемного разработчика такой проблемы нет - его судьба проекта, по большому счету не касается. Если он, конечно, сам волноваться сверх меры не будет: уведомит менеджера о качестве кода и будет в нем ковыряться со своей скоростью. Заодно навык чтения чужого кода потренирует. В жизни это всяко пригодится, а там, чем черт не шутит - сам станет настоящим программистом.
А если менеджер проявит неадекватность - невелика беда, рабочих мест для спецов даже среднего уровня на рынке сейчас хватает.
Я очень часто замечаю, что специалисты старой школы не знают что такое контейнеры, инверсия зависимостей, они не пишут нормальных модульных тестов и плохо работают в команде.
То же самое часто замечаю у специалистов "новой" школы. Это скорее проявление нежелания учиться новому (которое вечно), чем "новизны" школы. Что-то выучили в вузе/на курсах, что-то вдолбили в первые годы (или даже месяцы) работы - и все, больше ничего знать не хотят. Если в течении этого периода обучения не было перечисленного, они этого не знают и знать не хотят.
Не стоит принижать новичков, которые работают вместе с нами, они во многом стараются походить на нас. Если вы видите в них какой то негатив, то это больше эффект зеркала, присмотритесь внимательнее.
Причем тут принижение новичков? Новички, точно так же, как и старички, бывают разные. Нежелание учиться часто свойственно и тем, и другим. Реже (и у тех, и у других) бывает наоборот.
Чаще всего - нет, не стараются.
Ключевая разница айтишников старой школы и вайтишников "новой" - мотивация. 30-40 лет назад в ИТ денег ещё не было и шли в эту область исключительно гики, в хорошем смысле этого слова. Те, кому это нравилось, кто поднимал фидошные ноды "потому что могу", паяли сами себе "спектрумы" и писали под них на асме.
Подавляющее большинство новичков же - банальные ремесленники, они идут в ИТ исключительно за деньгами, они "анализируют рынок", "изучают то, что сейчас востребованно", работают ради зарплаты и знают только то, что прописано в должностной инструкции.
Нет, безусловно, среди новичков тоже есть такие, кто запускает Doom на тесте для беременности или строят нейросеть для определения развода мостов в Питере. Вот из таких можно воспитать нормальных айтишников - но, чаще всего, они воспитываются сами, потому что сами этого хотят.
Ключевая разница айтишников старой школы и вайтишников "новой" - мотивация. 30-40 лет назад в ИТ денег ещё не было и шли в эту область исключительно гики, в хорошем смысле этого слова.
Не исключительно. Шли и те, кого родители "пристроили" (я помню конкурс на факультеты ПМ, когда там сильно подняли стипендию относительно других факультетов). А у "гиков" мотивация не у всех вечная. Выгорание (в том числе и в бытовом смысле, когда человек просто пересматривает свое отношение к жизни) никто не отменял.
Подавляющее большинство новичков же - банальные ремесленники, они идут в ИТ исключительно за деньгами, они "анализируют рынок", "изучают то, что сейчас востребованно", работают ради зарплаты и знают только то, что прописано в должностной инструкции.
Тем не менее, часть этих "ремесленников" вполне понимает, что для сохранения конкурентоспособности надо все время учиться, не бояться нового.
Начнем с того что люди в принципе идут работать за деньги (а не как хотелось бы работодателям- за идею), так что не надо фокусировать внимание на этом как на чем то плохом (если вы не работодатель конечно). Но вот желание/нежелание учиться- это не проблема IT. Это наблюдается в любой сфере. Я вот наблюдаю это в нефтедобыче уже 13 лет (хотя осознаю это явление только последние 5 лет), из которой хочу стать вайтишником (в 36 я наконец то понял кем хочу стать когда вырасту )и изучаю "эти ваши" базы данных, питоны и прочие зоопарки(привет Hadoop). Но при этом я прекрасно понимаю что учиться придется до могилы: мир развивается семимильными шагами, новые технологии вылазят из под каждого куста. Но при этом у меня в лаборатории есть сотрудники младше меня (и иногда намного) для которых разобраться в одном документе или, не приведи Вселенная, сделать расчетный xlsx, подобно всем подвигам Геракла вместе взятым. И они не хотят учиться, но если спростшь- все хотят ответят что хотят стать как минимум ведущими инженерами. Но что б стать из лаборанта инженером нужно учиться. И до этого я постоянно учился. А ваши "динозавры", на мой взгляд, перестав учиться, какими бы они не были суперспециалистами- начинают умирать на спецы, как инженеры. Их просто переезжает двигающимся дальше Миром.
Чет простыня получилась...
Я с Вами, в общем-то, согласен. Но разве я где-то писал, что динозавры перестают учиться? Я за компом с 1989-го - и мне не надоело, я не выгорел (тьфу-тьфу), я продолжаю осваивать новое и мне это нравится. И те люди, о которых я писал, тоже не стоят на месте, хотя они постарше меня лет на 5-10 и за комп сели, когда я сам сидел на горшке - при этом, хотя они писали ещё на асме под PDP-11, они спокойно пишут и на вполне современных Go, Rust и прочих.
Это, заодно, и ответ на Ваш тезис о том, что "люди работают за деньги". Работают - да, возможно, потому что кушать хочется всем; но для хорошего айтишника работа - это не только ремесло, позволяющее заработать на хлеб с маслом, это ещё и хобби. И в свободное время эти люди (равно как и некоторые молодые, впрочем) всё равно пишут пет-проекты, развивают опенсорс, просто изучают новые какие-то вещи - не ради денег и не чтобы остаться в рынке, а просто потому, что им это нравится. Ну вот как другие ходят в турпоходы (неделями спать в палатке, топать десятки и сотни километров под дождём, бр-р); другие бесплатно какие-то модельки клеят, просиживая часами за кропотливым трудом, третьи ещё что-то делают. Но им такое в кайф.
А айтишникам старой школы нравится айти. Они туда пришли - почти все - по зову души, их хлебом не корми, дай чего-то эдакое сварганить. Естественно, что и учиться этому им тоже в кайф.
Но по факту, у таких людей код - лютая мотня, которую могут поддерживать только они сами. Потому что пробелы знаний в лучших практиках того же дотнета по верхам не схватишь.
Тут возможны два варианта. Если такой универсал никогда не писал много кода, то да, код у него вряд ли будет понятен. Но, с другой стороны, кода будет мало - и понять проще, и переписать, в случае чего, вполне реально.
А если такой спец старой школы кода писал таки много, то у него свои лучшие практики уже выработались. Ну да, менеджерам они, зачастую, незнакомы и вчерашним студетнтам - тоже. Но программист, даже если он не совсем настоящий - он эти практики по ходу дела распознает, потому что навык чтения чужого кода имеет. Если имеет, конечно. Но работодателям такой программист обойдется дороже, да.
Насчет наилучших практик сужу по себе. У меня был долгий перерыв на админство, а потому про этими практиками, в том виде, в котором они были заботливо собраны и превращены в догму теоретиками, я особо не морочился - мне и ITIL хватало. А потом, когда-таки полез разбираться, нередко обнаруживал внезапно, что, оказывается, какая-нибудь давно мне знакомая полезная штука имеет у теоретиков красивое название - а я ее использовал и название это не знал. Правда, я видел, чисто по опыту, и другую сторону всех этих "наилучших практик": например инверсия зависимостей реально мешает при анализе текста: зачастую хрен там без отладчика поймешь, какой код в реальности изображает из себя этот замечательный интерфейс - то есть, где конкретно багу искать.
Работодатель получает басфактор, а исполнитель - огромную кучу проектов, которые нужно поддерживать.
Проблемы работодателя исполнителя волновать не должны: это - не его код и не его деньги. И то, что для работодателя bus factor, для исполнителя - job security.
Ну, а самому исполнителю, таки да, нужно оценивать, на что он реально подписывается, и просить больше денег / решить "анунафиг". Ну и, иметь навык работы с чужим кодом - которому сейчас толком не учат.
но в реальности всё что лежит за пределами 10 летнего опыта - либо устарело либо забыто и годится только для побурчать на тему "а вот в наши времена"©
Не все столь однозначно. Есть, конечно, опыт устаревший (знание какого-нибудь странного языка вроде ЯУЗ или ЯМБ, например). Но есть и вечное - умение разобраться в проблеме, умение программировать (от языка мало зависит и со временем только обрастает новыми знаниями о всяких новшествах, например, когда-то таким новшеством стало ООП).
Насчет устаревания сильно поспорю.
Судить что опыт 10-20-30 лет устарел, могут только и исключительно те люди, у которых этого опыта никогда не было.
Как пример приведу, недавно клиент попросил сделать задачу, с которыми я работал лет 15 назад , с теми инструментами которые были доступны 15 лет назад = то есть мой опыт типа устарел на 15 лет.
Сейчас и инструменты другие и реализация другая, но задачи у бизнеса те же.
Я подумал что неплохо бы обновить опыт в этой области, за проект взялся, и практически очень мало увидел нового в новых инструментах, инструменты новые а правила игры все старые. И буквально за пару недель обновил таки знания по инструментам, и как обещал через месяц выдал результат, и получил денежку.
В реальных задачах пока у человека две руки, две ноги, и голова которой он ест, задачи которые он будет решать для жизни или бизнеса - будут неизменны.
Поэтому опыт не может устареть.
---
Скажу на своем примере, одно время после 15 лет плотной работы в ИТ, имел период где-то в 8 лет когда занимался совсем другими делами, даже компьютер не включал не нужен он был для работы вообще.
А когда 3 года назад - постепенно стал брать ИТ-задачи и возвращаться в эту область не увидел ничего кардинально нового, ну новые интерфейсы, новые подходы, но в основе как все было так и осталось, как там под капотам перебирались единички и нули , так они там и перебираются.
Ну другими командами, иногда на других языках, иногда по более эффективным алгоритмам, иногда только интерфейс более удобный стал у инструмента, иногда новые угрозы нужно учитывать и так далее.... - но это все осваивается на лету, так как конечная бизнес-задача практически неизменна....
"Маг вне категорий" (c)
Вот и ходют и ходют стада на собесы и шлют и шлют свои резюме направо и налево, чтобы проверить свой уровень квалификации. А кто реально ищет работу, кому и жрать почти нечего скоро будет, того даже роботы отсеивают уже из-за переизбытка соискателей😁
Странные дела... Читаю периодически аналитические сводки на Хабре и то мне кажется, что я мало зарабатываю, то вроде как очень неплохо (относительно показателей хабр.зарплаты). При этом уровень моей ЗП и грейда - весьма стабильны.
Лычки не важны, главное — провести банальный анализ рынка, выучить, что нужно, и вкатиться. Дальше от компании к компании все равно все будет по-разному.
Границы, которые описываются в подобных статьях, не работают в реальности. Все зависит от компании и твоих амбиций, а также планов руководства.
По каким критериям были посчитаны средние зарплаты? То есть и у синьора веб разработчика и у синьора инженера по ML одинаково средняя 210 тыс? Чёт дохера навалили ЗП для миддла
Всегда считал, что единственной объективной метрикой может считаться рабочий процесс.
Джун - работаешь под менторством.
Мидл - работаешь сам.
Синьор - менторишь других.
С такой формулировкой есть проблема. Допустим у тебя пол года опыта и ты приходишь допустим бекэндером в команду к фронту, тестировщику и менеджеру. У тебя будут неизбежно происходить проблемы с пониманием каких-то вещей, но обратиться не к кому - другие члены команды не шарят в твоём стеке. С проблемами приходится разбираться самому. Даже не то что приходится, иногда так специально и делают - специально берут что бы разбирался с проблемами, на которые у других нет времени разбираться.
Получается, что работаешь сам, потому что менторить тебя некому, но по знаниям ты джун. Вроде нельзя сразу стать мидлом, потому что мидл это про какой-никакой опыт. В итоге - по знаниям джун, по зп джун, по данной метрике мидл. Джуны тоже могут выполнять сложные задачи, вопрос только за какое количество времени и с каким качеством
Если пытаться оценивать разработчика в отрыве от конкретного рабочего процесса, то тут с любой формулировкой будет возникать такая проблема.
Т.е. мы не можем сказать "по знаниям Вася - мидл", потому что всегда найдётся супер-хай-тек компания, в которой даже к джунам/стажерам требования значительно выше. И наоборот, всегда найдётся компания, где Вася на три головы выше уже работающих там синьоров.
Но в рамках одной компании такое разделение вполне работает. В приведённом примере если разработчик работает самостоятельно и справляется - он мидл (работает в качестве мидла). Если добавить в команду ещё одного бека и даже не говорить, кто какую роль выполняет, то распределение ролей произойдёт автоматически - либо менее знающий программист будет всё спрашивать у более знающего (как джун у синьора), либо они просто будут работать независимо (как два мидла).
Самый нормальный критерий, на мой взгляд - результаты собесов. Если готовы брать мидлом, значит мидл, если готовы синьором - значит синьор.
Чето с зп смех какой-то. Или у разработчиков все так плохо? Имхо надо умножать на 2.
А имеют ли смысл подобные грейды? Человек может иметь дисбаланс по навыкам в различных областях. Также все сильно зависит от компании - в одной можно быть сеньором, а в другой могут рассматривать только как джуна.
Тайтлы нужны работодателям, а соискателям нужны деньги
Я предлогаю напомнить работадателям и HR-ам в чем отличие стажера от junior.
Как понять свой уровень квалификации: junior, middle или senior