«Ненавижу». Почему айтишников бесит их работа
Среди солидарно трудящихся нашлось два человека (или остальные просто не готовы к исповеди перед комьюнити), которые признались в ненависти к работе.
И да, «убийца» желания работать — заказчик.
Среди солидарно трудящихся нашлось два человека (или остальные просто не готовы к исповеди перед комьюнити), которые признались в ненависти к работе.
И да, «убийца» желания работать — заказчик.
«Смотришь на новые фичи у профильных блогеров и сравниваешь с „зоопарком“ у себя на работе»
Пётр — fullstack-программист, сеньор:
— Искали того, кто ненавидит свою работу, — это как раз я! Я — fullstack-программист на одном не то чтобы большом, но дорогом проекте. Сеньор.
Мы уже два года пытаемся разобрать вековой монолит на микросервисы, но заказчик почти не видит в этом профита, — хотя после перехода на микросервисы в самых критичных местах стало раз в 100 меньше отказов. Но, увы, заморозки по разработке в монолите нет — и очень часто возникают ситуации, когда небольшая команда сегодня переписывает буквально вчера вышедшее в продакшн от другой команды.
А иногда из-за постоянных накладок и смены планов это происходит параллельно.
Вчера я был очень зол, потому что два часа работал бизнес-аналитиком. Дело в том, что новенькому на проекте выдали таску и он пришёл ко мне за советом.
А я посмотрел — и пошёл в красках описывать РМу, а соответственно, и заказчикам, что это не может быть сделано в том виде, который предполагает задание.
У нас в два раза меньше тестировщиков, чем тестовых серверов. Поэтому 2/3 времени при разработке чего-то нового уходит на полное покрытие юнит-тестами. Нет, это неплохо, многие бы о таком мечтали, — но это невероятно сильно тормозит работу.
Девопсов как таковых у нас нету, поэтому будьте добры знать Kubernetes\докер\CI\CD\bash\powershell — и вообще всё, что может пригодиться, если что-то пойдёт не так. Как вы поняли, ВА отдельных тоже нет, поэтому иногда приходится разбирать «хотелки» вдвоём, втроём, вчетвером вместе с PM и другими программистами, а также QA.
Ещё у нас зоопарк фронтендовых фреймворков… Я просто ненавижу этот проект! И давно — но раньше вопрос иммиграции был важнее, чем моё психологическое состояние.
Какой выход из ситуации — поменять работу. Я в процессе — полгода уже ежедневно посещаю LeetCode, готовлюсь к собеседованиям. Резюме рассылаю. Но поиск идёт небыстро, а вот так уйти «в никуда» я не могу потому, что я — единственный кормилец в семье.
Нет, программистом работать мне нравится — с самого детства (как-то на уроке информатики, пока все справлялись со вложенными циклами, я нарисовал аналоговые часы на TurboPascal).
Но ты смотришь на новые блестящие фичи у всяких профильных блогеров на ютубе и сравниваешь с «зоопарком» у себя на работе из всех подряд фреймворков, начиная от царя Гороха. И понимаешь, что никогда их не применишь с таким-то отношением заказчика к твоей работе. А на пет-проект по вечерам сил уже никаких нет.
Я очень тщательно выбираю новое место работы — если вижу устаревшие вещи в требованиях, то сохраняю в закладки, но подвигаю такие вакансии в конец очереди.
Хотел бы найти работу в Германии — и осесть там. Но меня также устроила бы работа на удалённом проекте для американцев (и обязательно на продукте, никакого больше аутсорса!) — тогда бы я выбрал Испанию и Digital Nomad Visa. Думаю, что до конца лета всё же найду, а может даже перееду (я не в Беларуси, где — не хотел бы говорить).
Что посоветовал бы другим, чтобы не попали в такую же «ловушку». Следите, ребята, за тем, что делает заказчик. Посещайте митинги, даже если не хочется. А если видите неадекватные решения — сразу бегите. Потому что иногда, оказывается, что на тебя «денег нет». Есть на интеграции с сомнительными стартапами, на ещё 2-3 новых маркетинговых сервиса, а на тебя и на новый сервер для баз данных — нет.
«Кофаундеров трое, каждый говорит своё, таски кидают в «личку»
Виктор — Senior Node.js-разработчик:
— Я уже ненавижу свою работу — чувствую апатию и одновременно злюсь, даже мелочи выводят из себя.
Я работаю на американского заказчика, с которым тяжело общаться — он пропадает надолго. Я на проекте соло, кроме меня — кофаундеры, которые раньше его и писали.
Менеджмента ноль, что, конечно, бесит: их трое и каждый говорит своё, таски не нарезают в Kanban, а кидают в «личку». С кодом сложно работать — это просто минное поле. За год с лишним я привёл немного в порядок кодбазу, но сам за это время превратился в какого-то неадеквата.
Пока я не могу уйти с этой работы: она даёт возможность кормить семью. Так что я пытаюсь отвлекаться — играю в видеоигры (но если проигрываю, то снова злюсь). Ещё мне помогают держаться прогулки с женой и дочками, а также общение с другими разработчиками о том, как их тоже «достала» ужасная работа.
Надо сказать, что стресс у меня ещё после работы в предыдущей компании. И тем не менее, с марта я начал искать другую работу, но пока не очень активно. Отновил резюме, закинул посты в линкедин.
Я понимаю, что, конечно, ещё мне нужен отпуск.
Да и вообще очень важно иметь стабильный отпуск (ни в коем случае не пропускайте его!), говорить о проблемах на проекте, а если эти проблемы не решаются — уходить.
А ещё практиковать дни без работы — не думать о ней, не говорить (хотя бы один день). Не трогать гаджеты. И не держать рабочие чаты на телефоне. Это мой совет и себе, и другим — чтобы не отказаться в такой же ситуации, как я сейчас.
А с вами бывает?
«Накинет на себя упряжку — и гонит рысью». Минский психотерапевт о том, как выгорают айтишники
«Накинет на себя упряжку — и гонит рысью». Минский психотерапевт о том, как выгорают айтишники
Как я борюсь с выгоранием? Три простых совета от Миши Ларченко
Как я борюсь с выгоранием? Три простых совета от Миши Ларченко
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
ох уж эти синьеры, им бы только разрушить монолит создаваемый годами. таких перемен вы хотите?
Типа сеньеры этого захотели. Скорее всего идея какого-нибудь менеджера, который уже на другом проекте сидит или лида который уже в другой компании работает. Видели мы таких уникумов.
Там проблема в том, что Петя как программист малокомпетентен, зато обладает большим самомнением.
Как связаны микросервисы и количество отказов? Я тоже не вижу пока что профита.
Конечно нет. Людям надо работать и развивать продукт, а не ждать пока некомпетентная команда перепишет все на микросервисы, не понимая зачем они вообще нужны.
Ох да, правда? Каждому тестировщику обязательно нужен свой сервер? Вторая часть фразы вообще никак не связана с первой. Какое отношение юнит тесты имеют к наличию или отсутствию тестировщиков или тестовых серверов?
"Юнит тесты сильно тормозят процесс разработки" (c) Сеньор Петя.
Без комментариев.
Ну да. Сениор разработчик обязан знать среду где работает его код и отвечать за его сборку, деплой и работу. Подход "я написал невесть что, перекинул через забор девопсам, плевать как оно там собирается и деплоится" не работает в приличных местах.
Пользователь отредактировал комментарий 3 мая 2024, 14:27
Считаете unit тесты как серебряной пулей программирования? Всегда готовы написать unit test на метод GetById(id)?
Пользователь отредактировал комментарий 3 мая 2024, 15:02
Нет конечно, зачем вы приписываете мне то, что я не говорил? Юнит тесты не серебряная пуля.
А человек заявляющий, что юнит тесты как-то связаны с количеством тестировщиков, или заявляющий что они тормозят разработку - просто некомпетентен.
Вы не расписали, что этот метод делает и откуда. Предположу, что он вытаскивает кортеж из какого-то хранилища по ключу. Конечно же, такой метод должен быть покрыт юнит тестами.
ну так всякие есть циклы разработки: где-то разраб пишет функционал и тесты от начала и до обеда, где-то только функционал, а потом перекидывает, как вы говорите, за забор и тестировщик. уже пишет тесты. По поводу девопсов тоже спорно - лучше когда это все в одном месте и ответственность за си\сд несет какя-то одна команда\человек, а не хз кто (рандомный чел которому что-то показалось). Тогда не надо искать - а какая это **** поломала пайплайн и почему вдруг ничего не работает, а вчера было все норм. При этом бесспорно что больше знаний - лучше, особенно для синьера-помидора, особенно фулстека разбираться в докере, кубере, тераформе, дженкисе и т.п. можно например и сказать что мастхэв. Вот взяли тебя такого, а проект надо с 0 поднимать, ну и что ты там напилишь
По поводу девопсов конечно можно спорить. Но сеньор не понимающий о том, где и как выполняется его код, как происходит вообще процесс запуска тестов, как разворачивается приложение не может писать нормальное приложение и видеть проблему в целом.
Как такой человек будет принимать какие-то решения, как мелкие, которые возникают каждый день, так и крупные, архитектурные? Он не знает на какой машине и где работает его приложение, в контейнере оно, или на железе. Он не знает как оно деплоится. Как он будет писать какие-то вещи связанные с пользовательскими сессиями? Миграции данных? Невозможно написать миграцию пользовательских данных, не зная процесс деплоймента.
Пользователь отредактировал комментарий 3 мая 2024, 18:18
Покрытие 1 строки кода юнит тестом занимает значительно больше 1 строки кода.
Количество строк кода пропорционально связано со сложностью системы. С этой точки зрения юнит-тесты многократно увеличивают сложность системы. Увеличение сложности вполне может быть оправдано преимуществами, которые даёт юнит-тестирование.
Однако, найти метрики уровня "применение юнит-тестов удешевляет разработку в x раз и уменьшает количество багов с прода в y раз" - чрезвычайно сложно. Зато очень легко найти проект, на котором юнит-тестами покрыто то, что легче всего покрыть (утилиты и статика), а 20% критически важного (и самого сложного) функционала - нет.
Популярный аргумент "вы просто не правильно используете..." вызывает у меня встречный вопрос - а может ли считаться хорошей практика, которая на большинстве проектов оказывается "неправильно использованной".
Во многих случаях юнит-тест является единственным быстрым способом для разработчика проверить корректность работы кусочка написанного кода большой системы. Но ценность этих проверок в репе зачастую не выше ценности комита в репу файла с breakpoints, используемыми для дебага какой-либо задачи.
Также как на определённом этапе проекта денормализация БД является нормальной, так и удаление юнит-тестов, проверяющих работу утилит, которые никто не будет менять - тоже.
Более того, у меня нет сомнений в том, что при использовании НЕ test-first approach каждый девелопер без проблем вкинет сотни строк зелёных юнит-тестов в проект - сейчас за него это сделает Copilot. А ещё можно сгенерить тысячи строк юнит-тестов на юнит-тесты. Но непонятно, а нужны ли тогда ещё какие-либо уровни тестирования, если девелопер всё может сделать сам.
Аргумент об улучшении архитектуры (гибкости) для меня звучит как оправдание ограничений инструментов разработки. Если бы результат любого системного вызова в контексте юнит-теста можно было переопределить - зачем писать обёртки, интерфейсы и настраивать DI? Почему практики тестирования должны диктовать практики разработки?
Суммируя - я считаю, что на многих проектах инвестирование усилий в интеграционные тесты даёт больше измеряемой выгоды, чем юнит-тестирование самого простого кода.
Не знаю про какое большинство проектов вы придумали. На ВСЕХ сколь-нибудь значимых проектах тесты есть, и они хорошие. Без автоматических тестов на код невозможно поддерживать проект где больше одного разработчика сколь-нибудь долгое время. Если в проекте покрыто 20% кода тестами, а на 80 забили - он станет помойкой очень быстро и его выкинут и начнут все писать заново.
Про выбор между интеграционными тестами и юнит действительно можно долго говорить. Тем более что грань там довольно размыта на самом деле.
Про удаление юнит тестов не очень понял. Зачем? Они бесплатно гоняются. Тем более если никто не собирается менять ничего, их и поддержитвать не надо. А если вдруг соберется менять - эти тесты будут бесценными.
Как и про уровни тестирования. Тесты не проверяют отсутствие багов же. Тесты проверяют отсутствие регрессии.
Пользователь отредактировал комментарий 15 мая 2024, 11:57
По вашей логике врач хирург должен сам за все отвечать? И диагностику проводить и лечение назначать и судно после операции выносить. Тыж врач!
Это очень умный способ ведения спора. Приписать собеседнику идиотскую мысль, а потом ее опровергнуть.
К хирургу который только проводит операцию, и ни диагноз и показания к операции, ни дальнейшее состояние пациента его не волнуют, вы вряд ли хотели бы попасть на стол.
Для меня это звучит аналогично. Почему программист должен отвечать за инфраструктуру, поднимать eks и AD, искать проблемы в данных заказчиков, разговаривать с клиентами, придумывать kpi метрики etc.
Почему операционные системы с изоляцией адресных пространств процессов более стабильны?
Зачем придумали файловые системы, если любые данные это цепочка бит и их можно записать в один длинный файл?
Зачем использовать ссылки, если можно использовать адреса в памяти?
Зачем использовать классы и объекты, если данные хранятся в одном и том же адресном пространстве?
Почему не рекомендуют использовать классы с десятками полей, переменных-членов?
Зачем в языках придумали модификаторы доступа?
Я не вижу никакого профита, так что всем должно быть очевидно, что весь мир разработки программных систем идет не в ту сторону, причем уже давно!
Вы со своими голосами в голове разговариваете? От того что вы мешаете все умные слова в одну кучу, ваши аргументы умнее не выглядят
эх, жаль, я хотел подружиться, ведь вместе, как команда, мы могли бы бросить вызов реальности, поколебать ее устои и принципы
Пользователь отредактировал комментарий 4 мая 2024, 13:00
Дружище, давай я попробую ответить.
Разделение адресных пространств не даёт никакой стабильности. Адресные пространства стараются сделать для процессов одинаковыми, чтобы уменьшить количество настроек адресов в коде в процессе загрузки. Изоляция и контроль доступа делается на сегментном уровне. Изоляция собственно процессов как таковых друг от друга имеет смысл а любой многопользовательской ос с разделением ресурсов, и не только адресных пространств и не только от других процессов а прежде всего ядра.
Файловые системы придумали для того, чтобы обеспечить сменяемость носителя в накопителе и пришли к линейной и древовидной структурам данных, первое для стримеров второе для дисков.
Нет никаких ссылок от уровня Асм и ниже, все это указатели, т.е. адреса данных в оп ссылки как мы их знаем в срр допустим ненужная абстракция, вся соль ссылка не может быть пустой а указатель может но это фактически обман, сделай указатель пустой и разименуй. Ссылка просто такой синтаксический но довольно убогий сахар. Но из-за него ты в месте вызова не понимаешь у тебя объект ушел по значению или по ссылке.
Про классы они про мягкое а вы про теплое. Читайте про ооп и забудьте про адресное пространство вам ни стандарт языка ни ABI ни компилятор никаких гарантий про какое то адресное пространство не даёт. Его вообще может и ни быть
Я не знаю какой идиот вам это не рекомендует, но Профит от класса когда он как абстрактная сущность реализует что то из реального мира. Если реальный объект требует 50 членов так тому и быть
Модификаторы доступа придумали для бестолковой реализации концепции черного ящика позволяя ему быть и белым и серым
Как так то?
Программист всегда прав, и знает всё лучше всех, а тут такой coming out...
Как же надо себя ненавидеть чтобы каждый день заниматься проектом который ненавмдишь. Мдааа.
В пратчем оба человечка из мира вебни, не удивительно.
Есть как минимум одна существенная причина для этого - финансовая. В курсе сколько человек сидят в айти чисто ради бабла?
Можно было выбрать интересное направление где вот как минимум меньше такого бардака.
Нет. Не в курсе. Эта информация мне не интересна и бесполезна. Более того это провал почти всегда.
По факту получается как всегда. Сидели ради бабла, в итоге бабла так и нет (рас нет подушки безопасности позволяющей всё бросить и найти нормальную работу), зато есть выгорание, депресняк и прочие последствия. Заниматься тем что ненавидиш до добра не доводит и деньги тут не спасут.
Конкретно про этих ребят ничего не могу сказать. Скорее соглашусь с вами. Но вот конкретно в моем случае, работаю чисто из-за денег - хотя и далеко не в восторге от того что делаю. Помогает не выгорать особая философия жизни - 2 года пашешь, 3 чилишь и делаешь все что нравится.
И что вам это даёт? Много денег так что тратить не успеваете?
А почесу бы не жить постоянно как 3 годе? Работать над тем что нравиться и при это хорошо получать. Зачем обязательно каждые 3 года 2 мучаться выдавливая из себя работу?
Потому что с вашей колокольни это звучит разумно, а с моей колокольни нет. Мне не нравится айтишка и точка. Сижу в ней чисто ради денег и честно признаюсь в этом.
Так вот мне интересно почему с вашей колокольни нельзя заниматься тем что нравиться (будь то IT или НЕ IT) постоянно и заработывать на это более чем достаточно? Есть ведь люди зарабатывающие и за пределами IT тем что им нравиться? Или ваша сфера интересов совсем не прибыльна? Хотелось бы тогда узнать что это за сфера
Да, и это большая беда, что в РБ большой гэп между ЗП в ИТ и другими сферами (это не повод раскулачить первых). В итоге, проще с финансовой, нервной, временной точки зрения, быть средним айтишником, чем хорошим врачом, ветеринаром, конструктором металлоконструкций и т.д. Да, в последних сферах тоже есть крутые спецы с айтишной ЗП или даже выше, но их единицы. Хотя, по факту, айтишник это нормальная инженерная специальность как и любая другая.
IT это отрасль, заливаемая инвестиционными деньгами в надежде на быструю прибыль. Поэтому цель владельцев большинства проектов - рубить бабло, равно как и цель наёмных работников.
Это влечёт за собой массу глобальных последствий для индустрии, от экспоненциального наплыва людей, проходящих те же грабли, что и предыдущее поколение 4-5 лет назад (которые к этому моменту уже "эксперты" и учат других правильно проектировать методом пересказа увиденных в интернете решений задач с других проектов), до волн хайпа, создающих для инвесторов иллюзию прогресса ради выкачивания денег.
Расскажите, а что вы будете делать, если потеряете работу, а интересную для себя не сможете найти?
Пользователь отредактировал комментарий 6 мая 2024, 12:05
Нервные они какие-то. Спокойней нужно быть. Свое здоровье дороже, чем какие-то там проекты и заказчики.
Ну а если хочется делать то, что хочется, то это нужно делать лично для себя. А когда делаешь для других и они за это еще платят, лучше просто принять как факт то, что делать нужно те вещи, которые хотят они.
все правильно говорите, не нужно выгорать. десяткм тысяч людей работают на заводах и фабриках, что-то не видно прогрессивных коучей которые им советуют выйти из зоны конфорта. или борцунок с харазментом в сталелитейках
кто за ужин платит - тот девушку и танцует
А так это уже обсуждали, редакция повторяется
The Expert (Short Comedy Sketch)
https://www.youtube.com/watch?v=BKorP55Aqvg
"Кафаўндараў трое, кожны кажа сваё, таскі кідаюць у РМ"
Знайшоў чым сдзявіць: у меня адзін СЕО але таскі 3 разы на дню новыя, "важнейшыя". І гэта ён яшчэ ігнора тое, што з тэхнічнай часткі "гарыць"...