Комментарии 109
Имхо ровно наоборот. Когда разработчик не понимает, как работает им написанное в лайве и какова реальная цена тех косяков, что он понаписал — «качество разработчика» только падает.
Это да, но когда на пятом собрании ты отчитываешься не о том как завершил задачи, а что продолжаешь заниматься настройкой деплоя — тебя виртуально начинают пороть.
Хотя всё мысленно и понимают — что это нужно, а твоя работа не совсем об этом и вообще ты молодец, а DevOps в команде отсутствует в принципе, но нужно таски завершать и воображаемые дедлайны соблюдать, а не всякие улучшения в инфраструктуре творить.
И так каждый раз, когда собираюсь что-то улучшить со своей профессиональной точки зрения, я встаю на путь в котором спасибо не скажут, а скорее наоборот — отчитают. И начинается — если задачу не удаётся решить за день, то рабочий день становится 16 часов, а рабочая неделя семидневной, чтобы поскорее завершить свой процесс и дальше делать таски, которые уже горят.
От этого не только физическая усталость от беспробудной работы, но и беспокойство о том, что всё это ты делаешь на свой страх и риск и близко наказание за инициативу.
Так НЕ ДЕЛАЙ? Вообще я бы в мраморе эту фразу выбил и каждому при рождении татуировку бы делал.
Потому что именно тот факт, что многие относятся к работе так, будто бы должны делать что-то большее, чем входит в их непосредственные обязанности, проводит к ухудшению ситуации на рынке труда и далеко не в сторону работников.
Причем это не только про IT.
Эта недальновидность меня поражает.
Я могу и дальше заливать проект суперклеем по настоянию менеджера, но что будет со мной через год когда я вынужден буду грызть этот клей, чтобы в залитое место впихнуть ещё что-то?
Нет дорогой. Я повышаю качество условий своего труда чтобы и дальше работать над усложняющейся архитектурой своего фронта́ и спасаю себя от ещё больших мук по сравнению со муками совести от незакрытых тасков.
Было бы здорово если бы это заботило не только меня. По возможности я стараюсь донести скрытый смысл своих магических пасов, насколько это возможно. Но иногда быстрее самому решить и сделать, чем утонуть в море объяснений на тему — зачем это мне нужно.
С другой стороны я могу безропотно позволять стрелять в обе ноги, двойным залпом из двух двустволок. Писать костыли, бетонировать и дублировать код. Положить болт на SOLID и вообще всё, что не касается текущей реализации, выдавать работоспособный код раньше дедлайна и вообще быть лапой. А там хоть трава не расти.
Когда мы поймём, что произошёл в коде натуральный коллапс и его весь этот код к чертям вообще весь нужно переписывать заново — я разведу руками и скажу — «Ну мне как говорили я так и делал.»
К тому времени когда это произойдёт, как-то улучшится ситуация на рынке труда? Как она улучшится? Почему? Где гарантия, что наговнокодив я не решу срочно менять место работы, не оставив документации после себя — потому, что таски нужно перетаскивать, а не документацию писать? Что подумает новый человек с этого рынка труда когда откроет этот говнокод?
Бревно (С.Баруздин)
Лежало на пути бревно,
Мешало путникам оно.
Один сказал: -Нехорошо!
Сказал — и знай себе, пошёл!
Второй взглянул, потом вздохнул
И то бревно перешагнул.
А третий путник промолчал.
Он с виду был и хил, и мал.
Он молча скинул полушубок
И в сторону бревно убрал.
Подчеркну, что тут речь не о том, что меня нагружают работой на которую я не подписывался, а о том, что я иногда делаю не свою работу, с целью улучшить положение себя и других разработчиков. Тот же автодеплой например.
По разному бывает. Иногда под это получается выделить часы, иногда по своей инициативе, иногда неизвестно сколько потребуется часов.
Звучит конечно диковато, но и позиция «мопед не мой» — тоже не очень хороша.
Видимо хочется признания, поэтому сублимирую здесь. А ещё хочется, чтобы появился DevOps, а не просто админ, который умеет nginx и автоматизацию.
Звучит конечно диковато, но и позиция «мопед не мой» — тоже не очень хороша.
Нет, она как раз хороша. Если вам не готовы выделить время — то те, кто не выделил, пусть потом ответственность и несут за результат. Зачем вы покрываете этих людей? Пускай они страдают. Тогда, быть может, в следующий раз они прислушаются к мнению специалиста и время выделят.
Или другими словами, если к вам перестают относиться как к честному разработчику и пытаются применять бизнес-методы продавливания, то может надо и самому
Это да, но когда на пятом собрании ты отчитываешься не о том как завершил задачи, а что продолжаешь заниматься настройкой деплоя — тебя виртуально начинают пороть.
Разработчику не нужно заниматься настройкой деплоя в большой команде.
Автоматизацией деплоймента занимается девопс или configuration engineer.
Но Девопс не может заранее знать что за приложение вы пишете, какие у него требования и как вообще его запустить, если оно состоит из десятка сервисов.
Разработчик должен четко знать как его приложение запустить руками, и собственно эти знания и передать.
А девопс или инфраструктурный инженер уже занимается автоматизацией деплоймента, после чего деплой делается нажатием кнопки в CI или CD инструменте.
Если же компания скидывает эту обязанность на разработчиков — ну это уже проблемы компании, и вопрос нужно поднимать на менеджера.
Если же компания скидывает эту обязанность на разработчиков — ну это уже проблемы компании, и вопрос нужно поднимать на менеджера.
о каком размере компании говорим?
Разработчику не нужно заниматься настройкой деплоя в большой команде.
Автоматизацией деплоймента занимается девопс или configuration engineer.
большая команда это тупик. Как говорится, наиболее эффективно работают команды (проектные или продуктовые) размером, что они могут съесть две большие пиццы и насытиться ) Плюс в такой команде однозначно будут люди, которые подменяют друг друга ) А не то, что "ты девопс — ты и пили пайплайн". И компании в общем-то ехало-болело как конкретно в каждой команде сделан деплой. Работает? Хорошо работает? Сбоев нет? Ну, и хорошо. Я хоть сам и за централизацию — т.к. она позволяет реально экономить много денег и не переизобретать велосипед по 10 раз, но избыточная централизация таких вещей вредна: теряется гибкость и скорость (блин, говорю почти как по методичкам эджайлистов).
А то доходит до того, что девопс, за 100500 денег, не понимает того как работает стек TCP/IP или там DNS или не может написать элементарного правила iptables и вот тут начинается
это не девопс, а самозванец ) И не нужно называть инженера девопсом — это баззворд, который ничего не означает, тем более, если Вы принимаете, что devops это методология или философия. У нас шутят, что девопс разве что картриджами не занимается....
инфраструктурщики и админы.
согласен с тем, что может существовать инфраструктурная команда, которая поддерживает платформенное решение. А может, что ее и нет, если продуктовая команда деплоится, например, в облако (ну, ок, поддержка облака все равно никуда не девается — она по сути на стороне провайдера, но как будто ее и нет).
То-есть смысл в том, что девопсы, оиентированные на разработчиков и их цикл работы, никак не могут заниматься ещё и инфраструктурой.
не уверен, что это верный тезис.
Вообще посмотрите
http://devopstopologies.ru/
https://www.engineerbetter.com/blog/kill-the-devops-team/
Очень занимательно.
Просто есть глобальные решения внутри компаний, которые предлагают какой-то SAAS, и там сидят ускоспециализированные админы.
А есть девопсы, которые автоматизируют CI/CD, помогают улучшить и автоматизировать SLDC, контролируют релизы. Если они при этом пользуются готовыми SAAS, не обязательно в них разбираться глубоко.
большая команда это тупик
Большая команда нужна для больших проектов.
MS Office не может написать 10 человек. Для этого нужно гораздо, гораздо больше. А для эффективности, их можно делить на мелкие команды, которые занимаются отдельными компонентами. Девопс не обязательно нужен для каждой команды, ведь продукт один, поэтому команда инфраструктурных инженеров может совместно поддерживать несколько команд разработчиков.
В маленьких командах вопрос девопса нет особого смысла поднимать, поскольку там SDLC несложный.
Так в том-то и дело, что тот же ms office явно разрабатывался помодульно. Отдельными "командами".
Девопс не обязательно
Вообще забудьте это слово ) с одной стороны — в каком-то смысле у ms было больше девопса, чем есть сейчас у многих (почитайте про то, как они разрабатывали windows — там были все те же проблемы с тем, что хотели одно, получали другое, да и по тому же интерфейсу была куча итераций), а с другой стороны его в нынешнем понимании там не было. Тем более "девопс инженеров". Да и опять же — есть роли build engineer, release engineer, configuration engineer…
SDLC — да. Ребята реализовали. Кажется именно они у истоков этого термина (и подхода) стояло. А иначе и не могло быть )
Ну, и вообще есть определенная разница между коробочной разработкой (как ms office) и разработкой своего же сервиса ( девопс как направление появился именно как ответ на вызов, проблемы разработки и поддержки одними людьми — именно на пике бума веб сервисов).
Разработчику не нужно заниматься настройкой деплоя в большой команде.
Мир состоит не только из больших команд. Более того, больших не так уж и много...
И начинается — если задачу не удаётся решить за день, то рабочий день становится 16 часов
Зачем? Сегодня не успели — делайте в следующий рабочий день.
Это да, но когда на пятом собрании ты отчитываешься не о том как завершил задачи, а что продолжаешь заниматься настройкой деплоя — тебя виртуально начинают пороть.
Что то не то в головах ваших старших технических специалистов, которые так организовали вашу работу.
Индивидуальная многодневная настройка деплоя вместо разработки?
Бойлерплейтов да Кибернетсов на вас нет.
Если проект типовой — да, бойлерплейты. Если нет, то все равно придется настраивать пайплайн индивидуально.
Кубернетес? В каждый дом? Нет, увольте, не надо так. Каждой задаче — по своему инструменту.
Если нет, то все равно придется настраивать пайплайн индивидуально.
Да, но не:
Это да, но когда на пятом собрании ты отчитываешься не о том как завершил задачи, а что продолжаешь заниматься настройкой деплоя — тебя виртуально начинают пороть.
Что это за индивидуальная настройка пайплайна 5 дней на готовом бойлерплейте?
Кубернетес? В каждый дом? Нет, увольте, не надо так. Каждой задаче — по своему инструменту.
Это условная отсылка. К тому что уже существуют инструменты готовые, которые берут на себя значительную часть описанных вами задач.
Если вы не можете их использовать, так, может, и деплой автоматизированный полностью на ваших масштабах и не нужен?
Главное качество разработчика — уметь разобраться с любым подходящим инструментом, который решает задачи. Проблемы оплаты — это проблемы вашей договоренности с работодателем: что мешает перейти на почасовую оплату, например?
Нельзя быть хорошим программистом, если вы не можете продумать архитектуру приложения. Сложно быть хорошим архитектором, если вы понятия не имеете, как приложение будет (или может быть) задеплоено.
А еще я искренне считаю плохими разработчиками тех, кто не расширяет свой кругозор, не интересуется IT отраслью и не пытается делать свои хобби-проекты (собственно откуда черпается бОльшая часть знаний).
Ну вот :) Так и появляются неадекватные интервьюверы-фашисты, гнобящие всех, у кого пустой гитхаб.
А ведь я не такой уж ужасный разработчик, но пет-проектов никогда не было. Кругозор расширяю просто обзорным знакомством с технологией, а потом, в случае необходимости просто трачу неделю-другую на более глубокое погружение.
Даже людям без пет-проектов и гитхаба обычно есть что рассказать на интервью, и они могут оказаться лучше — вклад в OSS и свои проекты не делают разработчика хорошим сами по себе — дело в другом: по пет-проектам и вкладу в OSS складывается первое впечатление: i.e. перед вами активный контрибьютор в условный rust, пишущий по выходным своего убийцу твиттера, и просто разработчик без вклада в OSS и без своих проектов — интереса к первому не будет больше?
И мне в последние лет 7 не доводилось работать с людьми не имеющими ни того, ни другого, что тоже влияет на мою предвзятость.
Как активное участие в OSS сообществе и пет-проекты связаны с невозможностью растить детей, играть в дум и прочим? Я, например, не считаю себя новым Маском, однако вполне успеваю и работать, и учиться в вузе, и читать/гулять/пилить свои проекты в свободное время. А вклад в OSS (помимо того, что моя работа в принципе — FOSS, тут повезло) это нормальный побочный эффект работы с кодом: тебе надо сделать для работы что-то, что библиотека, которую ты используешь, не умеет — ты берешь и делаешь, а потом сабмитишь изменения в ту библиотеку (в некоторых компаниях после согласия менеджмента, но обычно это лишь формальность).
Как активное участие в OSS сообществе и пет-проекты связаны с невозможностью растить детей, играть в дум и прочим?
Временем они связаны, разве не очевидно? На все это нужна уйма времени и сил. Особенно на маленьких детей :) Добавить к этому обычные проблемы обычных людей — ремонты, походы в магаз, хобби какое + совершенно нормальное желание просто поваляться на диванчике под сериальчик — и вот как-то уже и времени на все не хватает.
однако вполне успеваю и работать, и учиться в вузе, и читать/гулять/пилить свои проекты в свободное время
Ну, а я не успеваю и что мне теперь, жопу рвать, чтобы успеть? Оно мне надо? Когда я был студентом, я тоже обладал кучей времени, но главным образом потому, что я был моложе и мне банально хватало сил на всё, даже при недостатке сна, после пьянок, девушки, работы админом на полставки и учебы по ночам.
Все было новым, все казалось очень захватывающим и интересным. А главное важным. Просто как и качество моих проектов, так и уровень погружения в OSS — были довольно унылые :) Когда я бросил "распыляться" на всё, в том числе и на OSS и сконцентрировался на работе — качество моего софта существенно выросло и мне за это стали платить куда больше денег.
Не очевидно благодаря большому числу знакомых либо активно участвующих в OSS, либо делающих свои проекты, при этом имеющие время на семью, хобби и сериал по выходным.
что мне теперь, жопу рвать
да хоть каждый день сериалы смотрите — дело ваше. Для кого-то и английский язык учить, или новый ЯП — "жопу рвать" и оно не нужно. А другим это просто интересно.
был моложе… даже при недостатке сна...
я не то, чтобы особо молод, да и сплю по 8 часов практически без исключений
когда я бросил распыляться
проблемы тайм-менеджмента
качество выросло, стали платить больше
по сравнению с вами, распыляющимся? Ну логично.
А если детей и жены нет… То да, я тоже такой был в универе. И кучу своих проектов пилил, и английский изучал, и в педагогический универ через дорогу к девчёнкам бегал, и в выч. центре универа подрабатывал, и проекты за деньги на стороне пилил, и монстров на компе отстреливал. А вот когда появились жена, двое малолетних детей, ипотека, тёща со своей дачей, нормальная постоянная 8-и часовая работа — всё исчезло.
Есть жена, есть свои проекты, есть много путешествий (да, сейчас меньше, но все же есть), есть постоянная фуллтайм работа и дистанционная вышка в процессе. За наш брак не беспокойтесь — у нас все прекрасно, а жена занимается любимым делом.
Дети не пугают; ипотека (в России) — нет, спасибо; теща прекрасная, огороды нас с женой не привлекают и мы там никому не сдались.
Скажем так. Закончить школу и поступить в институт — жизнь несколько поменяется.
Закончить школу и устроиться работать — жизнь несколько поменяется.
Жениться — жизнь несколько поменяется.
А вот дети — это другая жизнь.
Есть жена, есть свои проекты, есть много путешествий (да, сейчас меньше, но все же есть), есть постоянная фуллтайм работа и дистанционная вышка в процессе.
И сколько, конкретно, времени в день у вас уходит на жену, на свои проекты, на путешествия, на работу, на вышку?
На жену — постоянно, мы работаем дома, вместе круглосуточно.
На проекты — час-два по будням, на выходных по обстоятельствам.
На путешествия в среднем 2 дня на перелеты/обустройство и дальше по паре часов в день на изучение города плюс выходные по обстоятельствам. Последний раз в путешествие ездили на днях на неделю и даже с учетом сильно запутанного и затратного по времени процесса выезда и въезда в РФ, удалось и поработать 40 часов, и город посмотреть, и свои проекты поделать, и полтора дня потратить на общение с ответственными лицами по миграционным вопросам. Хотя у меня сейчас "каникулы" в универе, наверное в этом все дело? :)
На работу — 30-50 часов в неделю (последние пол-года не меньше 40)
На вышку около 8 часов в неделю и 1-2 полных дня в месяц на подготовку/доработку tutor-marked assignment, а также 3-5 дней на подготовку/доработку end-of-module assignment.
На работу — 30-50 часов в неделю (последние пол-года не меньше 40)
На вышку около 8 часов в неделю
Смотрите, простая математика: 8 часов в день вы тратите на работу, в среднем полтора часа на вышку, полтора часа на проекты. Вас «нет дома» 11 часов. А ещё завтрак/обед/ужин, одеться/умыться/побриться/почистить зумки, сходить в магазин и т.д… Я понимаю, сидя в одной комнате с женой 24 часа в сутки, желания вечером пойти с ней погулять по городу не возникнет, но просто примите к сведению, что ваш образ жизни весьма «самобытный», и крайне мало кому подойдёт. Пет-проекты, вклады в опенсурс по вечерам — это по-большей части дело для одиноких холостяков или молодёжи.
основное правило при Agile в менеджменте соблюдено, виновный найден
Какой бы менеджмент ужасный не был — всё в твоих руках. Либо меняй атмосферу на работе и доказывай обратное — либо меняй работу. Это в принципе так, не только с данной темой.
Что касается DevOps, я с Вами не согласен.
Я не считаю, что DevOps должен делать всё, как Вы описываете. Появилась под-ниша в разработке ПО, а не как Вы говорите, нашли «эникейщиков».
Эникеи всегда были — я их называю философами. Смотрят широко но не глобоко. И не стоит их путать с DevOps.
Другое дело, я считаю что и разработчики, не смотря на присутствие ДевОпса, должны расширить свой кругозор, ибо разработка не стоит на месте, нормальный разработчик должен понимать о взаимодействии его творения с остальным миром.
DevOps, как и сокращение и гласит Development & Operations тоже свое рода филосов, сконцентрировавшийся на снижении порога между разработчиками и сисадминами. При том для меня (как я и есть) DevOps должен иметь больше опыта из разработки чем сисадмина.
Короче, то что Вы написали, отношу к «накипело». Никакой ценности от этой статьи не увидел.
Вашу аналогию считаю не оправданной.
Работать по 14 часов за оплаченные 8 — как себя нужно не ценить, что бы такое позволять...? Отсюда и остальное становится более понятным… но это не точно…
Каждый делает свою работу хорошо, а все вместе они DevOps Team.
нет, это антипаттерн. Я ниже давал две ссылки, почему если у Вас DevOps Team, то DevOps у Вас не будет никогда.
http://devopstopologies.ru/
https://www.engineerbetter.com/blog/kill-the-devops-team/
продублировал, чтобы Вы не искали )
Все эти статьи похоже работают в фантазиях авторов или на очень мелких продуктах/проектах. У нас на 4000 разработчиков, несколько сотен CI проектов и тысячи аппликейшенов на опеншифтах с разными наборами конфигураций. Если бы каждый разработчик обязан был с этим разбираться, это просто десятки тысяч дней оверхэда на решение различного рода проблем.
Заминусуют полюбому, но я потсараюсь достучаться
Ноков не ищут потому что есть Prometheus Alert Manager + PagerDuty.
DBA не нужны потому что повсеместно NoSQL.
Билд инженеров потому что девелоперы сами делают helm create и степы для github actions могут скопипастить из мануала.
А если серьёзно — чем по вашему должен заниматься идеальный девопс инженер? Что является истинно вашей задачей?
DBA не нужны потому что повсеместно NoSQL.Можете, пожалуйста, развернуть эту мысль? Я не особо понимаю как NoSQL бд отменяют DBA.
Вы точно не путаете NOC (которые сетевики) и дежурную on-call смену?
Может и путаю. В моей практике ноки всегда были на звонке, следили за продом, открывали страницы сайта, смотрели в графану и заббикс, подымали разработчиков если что. У них были кое какие инструкции как что рестартануть, но на простейшие кейсы.
Upd: Ввиду лимита на 1 комент в час добавлю сюда, что они не спят ночью как дежурные админы. Они 24/7 мониторят и это очень похоже на определение noc
это не noc'и, а обычная "дежурная on-call смена".
Это примерно на том же уровне, что давайте переименуем админов в девопсы без изменения обязанностей ) суть-то не в названии, а в функции, в роли.
NOC — центр сетевых операций — Network operations center.
Во вторых, если у вас есть есть инструкции на простые кейсы и их выполняют дежурные инженеры, вы спускаете бюджет в унитаз. Автоматизация 1 инструкции на ансибл занимает максимум час, проще не инженеру регулярно платить, а за код 1 раз заплатить. Ведь у вас всё равно есть мониторинг и это ваши вычислительные ресурсы на которых вы можете выполнить этот код.
Во вторых, если у вас есть есть инструкции на простые кейсы и их выполняют дежурные инженеры, вы спускаете бюджет в унитаз.
Скорее соглашусь. Действительно нужно автоматизировать. Но только лишь с учётом того, что реальный мир сильно более многообразный, чем предполагают инструкции.
Автоматизация 1 инструкции на ансибл занимает максимум час,
Слово "максимум" надо заменить на "минимум". По факту — заложить вечер надо (ну, с нормальным написанием плейбука, а не тяп-ляп, с тестированием, документацией и учётом тех же флапающих ситуаций)...
Раньше был тяжкий бареметал провайжнинг — теперь два скрипта на терраформе. Раньше сервер поднимали за месяц — теперь за 4 минуты. Девопс — это сисадмин, который не сидит в ожидании «пожалуйста подождите», а конкретно работает большую часть своего времени.
Естественно, экскаватором нужно учиться пользоваться, а лопатой нужно уметь копать. Но в конечном итоге лопаты останутся за любителями, а города будут строить экскаваторами.
После бесконечного тыктыканья в далее-далее-готово девопс — это глоток свежего воздуха. Причем как для администратора, так и для его руководства.
Раньше был тяжкий бареметал провайжнинг — теперь два скрипта на терраформе.
бареметал провижионинг никуда не делся ) не все могут и не все хотят идти в облако. И в любом случае под капотом любого облака те же железки.
Вместо классического подхода к СХД теперь всюду multi-tier. Рейды в прошлом, шпиндели потихоньку тоже остаются только для специфических задач.
Провайжнинг физического хоста теперь сводится к конфигурации iscsi boot target в bios setup, остальное само. Образы ОС для этих хостов тоже собираются сами и тестируются тоже сами. Обновления фирмварей и биосов идёт напрямую от вендора и ставится в течение 8 часов после выхода новых версий. Хотите 10% тестовую группу — пожалуйста, хотите тайринг 10-30-50-100 — пожалуйста. Любой каприз!
Это хорошее решение, никто не спорит. И нужно стремиться к максимальной автоматизации.
Но бывают ситуации:
- Ты пришел, уже есть Легаси. Зоопарк.
- Чего там с мультидц? Ты сам-то умеешь в динамическую маршрутизацию? Bgp? Ospf? Mpls? L2/l3vpn? И все их тонкости? Вот только честно. А то это на картинках в букваре все видели. Конечно, зачастую это не мешает решать бизнес задачи и без этого ) но всякое бывает. И, кстати, одно из последних предложений о работе подразумевало именно хорошие навыки сетевого инжиниринга.
- Нельзя говорить руководителю "нет" — это как красная тряпка. У них в головах иногда рождаются странные идеи и это нужно прям на корню подрубать, но прям нужен очень грамотный софтскиллз. Предложить альтернативу. Аргументировать свою точку зрения.
Но бывают ситуации:
Ты пришел, уже есть Легаси. Зоопарк.
Это совершенно рядовая нормальная ситуация.
Мы не потому сейчас имеем кучу крутого ПО, что нынешние программисты круты.
Прошлые программисты, в среднем, как раз были более круты, они были типично научными работниками, а нынешний типичный программист просто ремесленник.
Мы имеем крутое ПО на сегодня потому что многие и очень многие вещи написаны до нас.
То есть легаси — это совершенно нормально и естественно.
Ты пришел, уже есть Легаси. Зоопарк.
Бывает, конечно, что до тебя на проекте работали обезьянки.
Но, как правило, это ровно такие же люди как и ты.
И то, что ты оставишь после себя будет восприниматься последующими коллегами как ровно такой же говнокод, как и то как ты воспринимаешь работу предшественников.
Это совершенно обыденная ситуация.
Бизнесу не нужно красиво.
Бизнесу нужно чтобы работало уже вчера.
Иначе у бизнеса не будет денег на твою зарплату.
И, строго говоря, бизнес тебе не последние штаны отдает на зарплату, поэтому если проект работает, но слишком дорог в поддержке — бизнес не загнется.
А вот если проект не говнокодный, идеально написанный, но стартовал на 2 года позже необходимого бизнесу из за слишком уж тщательной разработки — то денег на зарплату тебе бизнес уже не сможет заработать.
Прошлые программисты, в среднем, как раз были более круты, они были типично научными работниками, а нынешний типичный программист просто ремесленник.
+
Мы имеем крутое ПО на сегодня потому что многие и очень многие вещи написаны до нас.
+
Ну, либо уже понятно как решать какую-то проблему. Мы действительно ездим на технологиях 30-летней давности.
И то, что ты оставишь после себя будет восприниматься последующими коллегами как ровно такой же говнокод, что ты воспринимаешь работу предшественников.
+
вполне возможно, что "будущий ты" тоже с ужасом взглянет на артефакты, созданные "настоящим тобой".
., но вот беда, компании почему-то перестали искать ноков, dba, инфруктурщиков и build инженеров – сейчас это всё DevOps инженер в единственном лице.
Всё очень просто: соотношение компаний, которым реально есть чем занять таких узких специалистов, как dba и build-инженер к компаниям, в которых они 90% своего времени не будут делать ничего, примерно одна к к десяти тысячам. Цифра, конечно, условная, но зуб даю на отсечение, порядок я угадал.
В общем случае «узкий, но глубокий» специалист по каким-то инфраструктурным направлениям в разработке ПО и не требуется. Нужен как раз DevOps, который знает всё, но в общих чертах. Он может настроить запуск скриптов на SQL-сервере, но ему не нужно уметь в тонкий тюнинг производительности. Он может настроить автоматическую сборку и деплой, но ему не нужно знать все тонкости настройки платформы сборки на уровне build-инженера, потому как такие вещи — это обычно разовая работа, и на крайняк можно погуглить, когда надо, сделать, и через полгода забыть.
Видел я этих ноков, и ДБА видел: и правильно делают, что не ищут их теперь. Про всю эту шайку давным-давно был доклад от известного русского девопс-евангелиста Аркадия Райкина. Называется «Кто сшил костюм?», меньше трёх минут.
По-разному бывает, ну, и не стоит в госухах работать )
зарплата там рыночная.
это не соответствует действительности (ваш бывший коллега из госов). Возможно, что есть госы с рыночной з/п или околорыночной з/п, но не нужно обобщать.
В мелких фирмах нужны мастера на все руки, потому что команду узких спецов просто не чем загрузить.
Когда у фирмы 100500 проектов тогда узкие спецы всегда будут при работе и ни когда не будут простаивать.
Но в целом, если не устраивает организация работы, то зачем продолжать?
Всегда можно уйти
Специально зарегестрировался чтобы написать вам. Работаю я не в вашей сфере, но ситуация была подобная. Я переживал за продукт, старался всё сделать как лучше, буквально ночами не спал. Как итог со временем из-за постоянного напряжения и недосыпания я стал "косячить", а руководство меня за это, естественно, наказывало. Но посмотрев на сослуживцев из своей команды я решил поменять своё отношение к работе. И о чудо, "косяков" стало меньше, свою работу я стал выполнять лучше, а на не свою "болт положил", зарплата увеличилась, а отношение начальства ко мне стало лучше. А за "косяки" уже начали наказывать тех людей, кто был виноват в их появлении. Как итог, перестаньте выполнять за других их работу, деньги они получат (или не получат) за свою работу в любом случае, а у вас жизнь будет гораздо спокойнее.
А тут почитаешь, все разработчики, все программы делают. Дак все смешивают роль разработчика и кодера. Дайте каждому нормально работать и не будет суеты.
DevOps или как мы теряем заработную плату и будущее IT-отрасли