Душные люди в IT проектах: кто они и с чем их едят
Введение
Оооо, моя любимая тема "душных" людей в IT. Чаще всего этим болеют Разработчики в возрасте и Девопсы. Основная причина наверное возраст, по моим наблюдениям люди в возрасте к любой проблеме относится дотошней и пытаются предусмотреть все пути эскалации, когда задача требует простого как таракан решения. Любой, кто работал в IT, наверняка с таким сталкивался, в этой статье мы рассмотрим, кто такие душные люди, какие признаки указывают на их наличие, и самое главное — как с ними эффективно бороться.
Кто такие душные люди?
Душные люди (или "токсичные" сотрудники) — это те, кто своим поведением и отношением к работе негативно влияет на команду и проект в целом. Они могут проявлять себя по-разному:
Негативизм: Постоянные жалобы, критика без конструктивных предложений.
Микроменеджмент: Стремление контролировать каждый шаг коллег, что тормозит рабочий процесс.
Неспособность к сотрудничеству: Отказ от командной работы, изоляция, неготовность к компромиссам.
Неумение принимать критику: Защита своих ошибок, отказ признавать и исправлять их.
Создание конфликтов: Постоянные споры и разногласия, нарушение атмосферы доверия в команде.
Влияние душных людей на проект
1. Снижение морального духа: Коллеги начинают испытывать стресс и неудовлетворенность.
2.Падение производительности: Время и ресурсы расходуются на разрешение конфликтов, а не на выполнение задач.
3. Увеличение текучести кадров: Сотрудники могут уйти из-за неудовлетворенности работой в такой среде.
4.Проблемы с качеством: Ошибки и недоработки могут быть следствием плохого взаимодействия в команде.
5.Затягивание сроков: Из-за размазывания каши по тарелке теряется много времени.
Как бороться с душными людьми
1. Игнорирование душности и фокус на теме
Самый простой и эффективный способ справиться с душными людьми — это не обращать внимание на их поведение и четко говорить по теме. Сосредоточьтесь на выполнении задач, избегайте вовлечения в негативные обсуждения и не давайте таким людям возможности влиять на ваше настроение и работу. Четкое следование рабочим процессам и конструктивное взаимодействие поможет минимизировать их влияние на проект и команду.
2. Распознавание проблемы
Первый шаг в борьбе с душными людьми — это их идентификация. Признаки, о которых мы говорили ранее, помогут распознать таких сотрудников. Важно наблюдать за поведением коллег и фиксировать случаи, когда их действия негативно влияют на команду.
3. Разговор один на один
Если проблема выявлена, необходимо провести личную беседу. Часто душные люди не осознают, что их поведение является проблемным. Важно дать конструктивную обратную связь, указывая на конкретные случаи и их последствия для команды и проекта.
4. Установление четких ожиданий и границ
Определите правила поведения и взаимодействия в команде. Убедитесь, что все понимают свои роли и обязанности. Это поможет снизить вероятность конфликтов и улучшить рабочую атмосферу.
5. Поддержка команды
Важно создать в команде культуру поддержки и открытого общения. Регулярные встречи, тимбилдинги и другие мероприятия помогут укрепить командный дух и снизить влияние душных людей.
Заключение
Душные люди в IT проектах — это серьезная проблема, которая требует внимания и решений. Идентификация таких сотрудников, предоставление обратной связи, установление правил и поддержка команды — ключевые шаги к созданию здоровой рабочей среды. Помните, что успех проекта во многом зависит от того, насколько эффективно команда может работать вместе и преодолевать возникающие трудности. Один из самых простых и действенных способов — это игнорировать душное поведение и четко говорить по делу, не позволяя негативу проникать в вашу работу и отношения в команде.
Комментарии (98)
brdn1812
06.06.2024 11:27+126"Более 5 лет в индустрии"
"люди в возрасте к любой проблеме относится дотошней и пытаются предусмотреть все пути эскалации, когда задача требует простого как таракан решения"
Кажется, вам еще надо лет 10 походить по граблям, чтобы не увлекаться тараканами.
LaoSan
06.06.2024 11:27+28Вспоминается выражение с картинки гуляющей где то в просторах сети.
Цитирую:
А как так вышло, что необразованные люди смогли сместить фокус со своей некомпетентности в любом вопросе на универсальный ответ: "Хватит душнить" ?
pstor
06.06.2024 11:27+5Идеально и точно! Как только оппонент понимает, что решил спорить там, где ты собаку съел летит вердикт - душнила!
ValeryGL
06.06.2024 11:27+4
"задача требует простого как таракан решения", дальше серьезно читать не смог
forgot10
06.06.2024 11:27+1Потом эти "простые как таракан решения" оставляют публичный адрес с any/any и забывают, что они его вообще открывали, ведь всё должно быть просто, просто перескочили на другую задачу, просто сделали без запроса и не спросили как надо, просто ничего не надо документировать, всё же так просто!
DenSigma
06.06.2024 11:27+36А если в команде весь бизнес обеспечивает именно этот "душный человек", а остальные няшки балду пинают?
Racheengel
06.06.2024 11:27+1Очевидно же решение: больше никто не нужен.
Выгнать всех няшек к чорту, пусть душнила дальше баржу тянет.
DenSigma
06.06.2024 11:27+16Нет, бывает так, что всю архитектуру проекта продумывает один человек. Все идеи, которые потом продает бизнес, придумывает и продвигает он. Он же материт всю остальную команду и требует высокого качества кода (при том, что никаких стандартов предприятия на этот счет нет).
Остальные реализуют классы, пишут юнит-тесты, скрипты, короче всю черную работу.
DMGarikk
06.06.2024 11:27Он же материт всю остальную команду и требует высокого качества кода (при том, что никаких стандартов предприятия на этот счет нет).
ой у нас так было, причем бизнес нам не оплачивал ни рефакторинг ни юниттесты ни реализацию фич
а этот чел постоянно нас материл что у нас этого всего нет и качество хромает
но его задача была стратегию и архитектуру указывать, то что у нас бюджетов нет его не волновало...но вымещал он это почемуто на отдел разработки, а не на бизнес (с его т.з. мы наверное должны были бесплатно вне рабочего времени это все делать ради идеи)
DenSigma
06.06.2024 11:27+2Понимаю. Но я имел в виду - писать качественный код сразу. А не навалить как попало, а потом рефакторить и юнит-тесты дописывать. Бизнесу хочется, чтобы сразу было хорошо. А ваш человек ругался на что - что вы с начала наваливали некачественный код, или что вы не хотели некачественный код исправлять? Это разные вещи.
DMGarikk
06.06.2024 11:27разные согласен, но разработка у нас выглядела так
нужно сделать фичу, сколько оцениваете? две недели... окей, вот вам 4 дня на разработку два на тестирование в пятницу релиз, понедельник дедлайн. точка.
это все на фоне фраз "вы должны сразу писать код без ошибоч чтобы даже без тестирования выливать его в прод и он отлично работал, мы не готовы вам платить за это, и оцениваем вашу работу в 4 дня и так уж и быть даем два дня на тесты" (с)
Observer212
06.06.2024 11:27+3Как сказал классик: "я сделаю эту работу за 4 часа в течении месяца".
От себя добавлю: как же задолбали специалисты с большой дороги. Ты или делай чтобы за тобой не переделывать, либо поумерь своё ЧСВ. За переделки никто не хочет платить, особенно заказчик.
Politura
06.06.2024 11:27+3Хм, а зачем работать в конторе, которая двухнедельную работу заставляет сделать за 4 дня? Если нет взаимопонимания, то ничем хорошим дело не кончится и чем раньше прервать отношения, тем лучше, тк затягивание может привести только к эскалации, конфликтам и прочим выгораниям.
Pryanik71
06.06.2024 11:27Не не не. 2 недели на фичу. Разработка 4 дня, потом тестирование, исправление багов, тест фиксов и релиз. Как раз две недели минимум.
Правило разработка умножить на пи в действии.
DMGarikk
06.06.2024 11:27Вот я там теперь и не работаю :))
Подгорел я знатно конечно, но опыт очень любопытный теперь есть, управлением экстремальной разработкой
cat-chi
06.06.2024 11:27+4Важный вопрос – а это оценка по мнению того самого "душнилы"?
DenSigma
06.06.2024 11:27+1Положим, это оценка бизнеса.
cat-chi
06.06.2024 11:27Тогда выше ответили верно. Выгнать всех к чёрту, пусть душнила тащит
shachneff
06.06.2024 11:27+4Не положено. Партнеры, контрагенты - не поймут, как это в такой блестящей крутой компании (по рассказам, например, гендира или маркетологов), всего 1 ключевой сотрудник ИТ. Нужно "как у всех, эджайл, девопсы, тимлиды, тестеры" и т.п.
P.S. Без смеха, реальный пример из жизни.cat-chi
06.06.2024 11:27+2Тогда пусть душнила уходит и создаёт свою компанию.
А то пока, судя по всей ветке, у нас рисуется портрет не душнилы (хорошее, в общем-то, качество для многих категорий IT-специалистов), а классический токсик с непомерно раздутым самомнением. Так пусть попробует сам поработать без "балласта" и покажет чего он реально стоит
DenSigma
06.06.2024 11:27+4Нет, не верно. С точки зрения бизнеса (при правильном понимании производственного процесса, конечно) выгодно освободить "звузду" от черновой низкоквалифицированной работы, дав ему только "звездные" задачи. Нанять и перетряхивать джунов и мидлов за копейки, пусть черновую, повторяюсь, работу выполняют, а "звезда" путь высокие задачи делает.
Задача тимлида, точнее, начальника группы - именно это и обеспечить. А задача СЕО, кстати - убедиться, что тимлид это понимает и выполняет. И не "душнилу" чморит, а следит, чтобы "звезда" "несла золотые яйца". И варежку недовольным джунам затыкает, если им не нравится со "звездой" работать.
Естественно, если наш душнила на самом деле "звезда", ценная для бизнеса.
cat-chi
06.06.2024 11:27Так изначально же речь не о "звезде" и джунах/мидлах, а о том, что он якобы один работает.
То, что остальные делают рутинную работу – не равнозначно "балду пинают"
ookami_kb
06.06.2024 11:27+65Душнила:
Вообще-то, "душнила" и "токсик" – это не одно и то же. А эти 5 "признаков" не имеют особого отношения ни к тем, ни к другим.
Токсик:
Прежде чем писать подобного рода "туториалы", неплохо бы в вопросе разобраться.
Sergeilunin
06.06.2024 11:27Только людям с двузначным IQ не нравится этот пост
Okeu
06.06.2024 11:27+9Этот комментарий достаточно токсичен по отношению к токсикам и душнилам, или еще нет?
этодругое?
ehots
06.06.2024 11:27Только люди с однозначным iq воспринимают эту проплаканую писанину за пост и ставят нравится
Kill_Voice
06.06.2024 11:27+55Да-да, видел я этих весельчаков которые быстро наговнокодили и не душно катапультировались на другую работу
Ilya_Artemev
06.06.2024 11:27да, духаны встречаютс конечно, а если скажешь ему что он духан, начнет вонять еще больше
Okeu
06.06.2024 11:27+9ты специально зарегистрировался в очередной раз, чтоб написать этот коммент, серьезно?)
И мы после этого духаны?)@Sergeilunin не твой твинк?
IsKaropk
06.06.2024 11:27+29Спрашиваю: "Документ сложный, "размазан" по множеству таблиц. Вполне вероятна ситуация одновременного редактирования несколькими пользователями одного документа. Почему вы используете РСУБД, не поддерждивающую транзакции (и внешние ключи)?"
Отвечает: "Вероятность одновременного редактирования одного документа весьма мала, зачем душнить?"
Да, я старпёр и душнила.
piton_nsk
06.06.2024 11:27+1Почему вы используете РСУБД, не поддерждивающую транзакции
Такие еще остались?
Naves
06.06.2024 11:27+1MySQL The MyISAM Storage Engine
Transactions No
https://dev.mysql.com/doc/refman/8.4/en/myisam-storage-engine.html
MyISAM
MyISAM was the default storage engine from MySQL 3.23 until it was replaced by InnoDB in MariaDB and MySQL 5.5. It's a light, non-transactional engine with great performance, is easy to copy between systems and has a small data footprint.
You're encouraged to rather use the Aria storage engine for new applications, which has even better performance and the goal of being crash-safe.
Until MariaDB 10.4, system tables used the MyISAM storage engine.
https://mariadb.com/kb/en/myisam-storage-engine/
Не все же обновляют БД каждый год.
klis
06.06.2024 11:27Зачем писать что-то, требующее транзакций и внешних ключей, на чем-то, где этого нет? Зачем тут вообще что-то спрашивать, отвечать, обсуждать?... Как СУБД вообще может быть реляционной, если не поддерживает внешние ключи? В чем ее реляционность?
piton_nsk
06.06.2024 11:27+1Почитайте оригинальную статью Кодда про реляционную модель, там вообще почти ничего нет, даже order by.
FlyingDutchman2
06.06.2024 11:27Ну вообще-то Кодд потом разработал свои 12 правил
Внешние ключи относятся к правилу 10: Integrity Independence.
piton_nsk
06.06.2024 11:27Вы абсолютно правы. Но суть в том, что это было потом. И потом было много чего - и ключи, и группировки, и ЕМНИП оконные функции.
Но это уже было поздно)
DenSigma
06.06.2024 11:27А поле с версией может помочь при отсутствии транзакций? При редактировании документа, конечно а не при финансовых проводках.
avegad
06.06.2024 11:27+17Т.е. максимально подложить "соломки", обеспечить возможность обойти большинство грабель, и подводных камней - душность?
Проигнорировать все советы, рекомендации более опытного сотрудника(а то и руководителя), наступить на все грабли, собрать все подводные камни - это норм?
gleb_l
06.06.2024 11:27+3В современных реалиях разработки - к сожалению, да (. Сплошь и рядом. Радуйтесь, что разработчики вообще задумались об одновременном редактировании документа, могли бы просто наивно пройти мимо, а разваливание логики прикрыть универсальным обработчиком - oops, что-то пошло не так ;( - приносим извинения. попробуйте еще раз.
Skipy
06.06.2024 11:27+3Недавно видел феерический универсальный обработчик. Сообщение пользователю: "Дело в нас. Войдите еще раз"
kFourth
06.06.2024 11:27+8Похоже на ситуацию, при которой очень поверхностно знакомый с темой человек начинает неадекватно реагировать на уточняющие вопросы "душного человека".
VBKesha
06.06.2024 11:27+11проблеме относится дотошней и пытаются предусмотреть все пути эскалации
Ага ты им говоришь CAN через MQTT в вашем случае не передать, у вашего железа таймаут 25мс на ответ. Неее ты душный всё будет ок, ребят да пинганите свой сервер в амазоне и гляньте время, ты ооочень душный. Кидай нам пакеты в MQTT и всё будет ок. Ну ок, мне не сложно, вот вам пакеты. Ой у нас ничего не работает......
Skipy
06.06.2024 11:27+62Ну что, поехали душнить.
Негативизм: Постоянные жалобы, критика без конструктивных предложений.
Принесли мне как-то разработчики список интеграций по проекту. Из более чем 50 - ни одной целевой. JDBC к чужим БД, DB-линки, SOAP. Корпоративным стандартом была сервисная шина. Внимание вопрос. Какое конструктивное предложение мне им дать? Использовать рекомендованные? Тогда они не успеют за две недели вау-эффект дать. Это основная их цель была. А моя цель - контроль соблюдения стандартов и проверка применимости правильных технологий. Это мои должностные обязанности, я не имею права им разрешать этот лютый трэш
Дальше больше. Собрались на троих директор программы, директор проектного офиса и технический директор. И решили, что архитектору, то есть мне, хватит пять дней на создание архитектуры проекта. Потом три дня на согласование, потом два дня на утверждение, и через две недели они откроют проект. Регламент - согласование БТ сколько потребуется, 15 рабочих дней минимум на архитектуру, 22 рабочих дня на согласования, минимум неделя на утверждение, если звезды сойдутся. БТ нет как явления. Проект - дичь. Критически важны НФТ, но их никто не в состоянии сформулировать. Уровень аналитики - мне пришлось объяснять, что части заложенного в проект бизнеса в банке нет как явления. И никогда не будет. Внимание вопрос. Какое конструктивное предложение им дать? Почитать регламенты и следовать им? Разработать БТ? НФТ? Тогда они не успеют за две недели вау-эффект продемонстрировать, цели не изменились глобально.
Итог. Жалоба моему руководству, что я всем вставляю палки в колеса. Истерика руководства - этот проект надо делать проактивно. ТРИ МЕСЯЦА на согласование архитектуры - это не от меня зависело, и я с самого начала объяснил, что будут именно так, ибо проект - дичь, и НФТ нет. Утверждение... и еще одна истерика моего руководства - как мы вообще на это подписались? Проект - дичь! Именно. Я это говорил с самого начала. Но у всех складывается пост-ощущение, что именно я жалуюсь, критикую и не даю никакого конструктива.
Неспособность к сотрудничеству: Отказ от командной работы, изоляция, неготовность к компромиссам.
Приходит такая команда и говорит - а давай мы тут накостылим, наговнокодим, а исправим когда-нибудь потом. Нам квик-вины нужны и вау-эффект. Нет, говорю я, это пойдет в пром, извольте делать правильно. Всё, это отказ от командной работы и неготовность к компромиссам
Микроменеджмент: Стремление контролировать каждый шаг коллег, что тормозит рабочий процесс.
За следующий месяц я пять раз ловлю команду на попытках мошенничества. Реализации костылей, на которые я не согласился. Завышение трудозатрат, дикое - на xslt-преобразование на шине, на которое я на прямое и обратное потратил минут 20 с тестированием, заложили 45 человеко-дней. И т.п.
В итоге приходится контролировать каждый шаг. Микроменеджмент. Скорость реализации возрастает в несколько раз, что вызывает сильное недовольство РМ - начинаются вопросы, на что он запрашивал столько денег и времени. Проект передают другому архитектору, который позволяет всё. Через полгода в проме инцидент на 20К евро двойного списания, в котором обвиняют... архитекторов. Которые "разрешили" те самые костыли. И не проконтролировали (!!!), что их исправили. Оказывается, микроменеджмент был нужен.
Неумение принимать критику: Защита своих ошибок, отказ признавать и исправлять их.
Реализовывал я как-то, еще будучи разработчиком, визуальную раскладку графов. Через библиотеку ILOG JViews. Там были несколько менеджеров, дававших красивые и быстрые результаты. На графах узлов в 20 и строго определенной топологии.
И был у шефа любимый граф, очень неудобный для всех раскладок - 450 с лишним узлов, топология... никакая. Неклассифицируемая. Самый красивый результат давал один менеджер - секунд за 15. И это было ну ОЧЕНЬ долго. В итоге шеф сам взял толстенное руководство и отметил все настройки, которые надо применить. Дальше я непосредственному начальнику три часа рассказывал про каждую из них, показывал, как они у меня выставлены, как они меняются и к чему это приводит. По всему выходило, что оптимально всё. А значит, я защищаю свои ошибки, отказываюсь их признавать и исправлять. Далее уже искали повод, чтобы меня уволить. Поводом стало слово "рефакторинг" - я собирался ничего не делать аж две недели.
На мое место пришел студент, который посмотрел на всё это и сказал, что я м-дак, а он всё сейчас настроит. "Ага!" сказал шеф. Настроили. Во время показа шеф открыл любимый граф, нажал кнопку - и всё зависло. Перезагрузили. То же самое. Ушли разбираться. А потом оказалось, что студенческая поделка запускает раскладку в event dispatcher thread - то есть приложение даже отрисовываться перестает. И работает что-то около 45 минут. Случайно оставили после нажатия кнопки, отвлеклись - и дождались окончания процесса.
Но кто там душный, отстаивает свои ошибки? Я, конечно. Студент вообще не при делах, он студент.
Создание конфликтов: Постоянные споры и разногласия, нарушение атмосферы доверия в команде
Собственно, всё сказано выше. Если целью части команды не является сделать дело, а для другой части это задача первостепенная - конфликт неразрешим. Это будут постоянные споры и разногласия. У меня стоит задача уменьшения времени согласования в конечном итоге, это уже известная боль во многих случаях. А продукту нужно вывести в пром новую фичу, а заботиться о согласовании данных они не хотят. Когда-нибудь реплицируются. Нет времени. Нет компетенций. И т.д. и т.п. И конфликты порождает кто? Тот, кто заботится, чтобы им в итоге не прилетело. Но это будет когда-то потом. Или не будет. Бизнес в погоне за прибылью откровенно нарушает законодательство. А когда приходит ЦБ с неудобными вопросами - все бегут к архитектору: а почему мы только сейчас узнали, что мы вот это всё должны по закону делать. А потому что, а) вы не читаете этих законов, хоть это и есть в ваших должностных инструкциях, и б) вам это говорили сделать из общих соображений с самого начала. Но у вас не было времени и желания. И кто в итоге спорит и разногласит? Ну не бизнес же!
Проще говоря. А вы уверены, что всё происходящее - это потому, что я душный? А не потому, что у меня 25+ лет опыта в разработке, а у вас от силы 5?
P.S. Вот это особенно понравилось:
Четкое следование рабочим процессам
По опыту - не родилась еще компания сложнее макдачной, которая сможет досконально прописать свои процессы настолько, чтобы они работали, если им следовать от и до. Да и к макдаку вопросики есть.
А вообще четкое следование инструкциям называется итальянской забастовкой. Угадайте, Автор, почему.
kenomimi
06.06.2024 11:27Душнила и токсик не могут обьяснить свои претензии, потому что они основаны на эмоциях, на зависти, лени, ЧСВ, и прочих подобных вещах. Нытье и баттхерт по любому поводу - основное состояние душнилы.
Недовольный чем-то адекват может доходчиво обьяснить свою позицию с практической стороны, что и видно в этом каменте. Адекват может ткнуть мордой в косяки и обьяснить, зачем так, а не иначе. Душнила не может.
Markscheider
06.06.2024 11:27+16Духан (араб. دكان) — на Ближнем Востоке и в Афганистане лавка, небольшой магазин; на Кавказе и в Крыму название небольшого ресторана или харчевни.
---
Сломал себе всю парадигму о ваш заголовок. Есть же хорошее и широкоиспользуемое слово "душнила" - зачем изобретать велосипед?
MountainGoat
06.06.2024 11:27+7Какие культурные у вас ассоциации.
Взял с собой её Иван,
Положил её в карман.
Там лягушка чуть не сдохла! —
От Ивана шёл духан.
ildarz
06.06.2024 11:27+2Есть же хорошее и широкоиспользуемое слово "душнила" - зачем изобретать велосипед?
Душните. :)
wepp
06.06.2024 11:27+1Широкоиспользуемое, но точно не хорошее. Даже "зануда" в себе содержит меньше негатива. Я вообще решил, что слово "душнила" используют в адрес тебя те, кто просто не хочет/не может понимать/разбираться.
Bluewolf
06.06.2024 11:27+6GPT, уходи!
wepp
06.06.2024 11:27+6Мне кажется, что-то даже в структуре текста такое есть, что выдаёт творчество AI. Ну и в целом, бестолковая статья с нулевой пользой.
BeardedBeaver
06.06.2024 11:27+2Ради смеха попросил гпт-чо написать "статью про душнил в IT с хорошей структуров и не банальным выводом", она вывалила портянку текста, до зубной боли похожую на этот опус
sergyalosovetsky
06.06.2024 11:27+2офигенный способ, никогда не подводит: посмотреть на рейтинг, и если он :
меньше 20 - идти сразу читать коменты
больше 10 - можно читать
больше 100 - нужно читать
если от -20 до 10 лучше сразу закрыть
Porohovnik
06.06.2024 11:27+3Если все им будут следовать, то первые +10 набирать будет нереально.
Но в целом, кроме последнего пункта - метод годный
kenomimi
06.06.2024 11:27Вот сейчас ты его гонишь, а через пять лет он в твоей кошкожене будет душнить в отместку :)
dmitrybaltin
06.06.2024 11:27+16Автор, несомненно душнила, поскольку соответствует как минимум 3-м пунктам своего же определения: негативизм, создание конфликтов, неумение принимать критику.
Впрочем, статья написана просто чтобы немного хайпануть и этого результата достигла.) И ведь получился едва ли не эталон жанра. Модная тема, коротко, доступно. В следующий раз рекомендую написать про эмоциональное выгорание, тоже хорошо залетит.
Skipy
06.06.2024 11:27+5Там не только хайпануть результат получился. Еще -9 к карме - и автор в read only уйдет.
MaFrance351
06.06.2024 11:27Ну не, до той легендарной статьи автору ещё далековато...
khajiit
06.06.2024 11:27Можно чувствовать себя комфортно, если твои соседи по ресурсу не знают ИА Панорама. Или мемов. Или xkcd.
Но не с теми, кто не знаком вообще ни с чем. Это ж все равно что вумансру околоитшного толка.
Vsevo10d
06.06.2024 11:27+4Если имелась в виду карма -10, то я сейчас забил этот последний гвоздь, отметив все галочки, служу Отечеству и Хабру.
aamonster
06.06.2024 11:27+1В следующий раз рекомендую написать про эмоциональное выгорание, тоже хорошо залетит.
У нас всё равно уже нет сил про это читать...
tigreavecdesailes
06.06.2024 11:27+2Тем не менее, эта публикация оказалась полезной для нескольких человек, желающих совершить кармосуицид))
Daddy_Cool
06.06.2024 11:27Автор конечно круто э... заэйджшеймил кучу народа ))). Я уж думал взбрыкнуть, потом прочитал классификацию, перешел к методам решения... Я бы сказал "душный" человек это другое. Зануда не по делу. А люди описанные автором... это токсики (упс, это уже написали). На мой взгляд это люди не на своем месте и значит с внутренними проблемами. В научной среде таких крайне мало (там другие типажи) , но одного я знаю. Человек по сути в ловушке - для научной работы у него нет нужных способностей, а амбиций много, в результате зависть, гиперкомпенсация, конфликтогенное поведение с коллегами на ровном месте. Руководство удивляется, что он делает у нас, почему не уходит (необходимый минимум требований он всё же выполняет).
На мой взгляд, все пункты перечисленные у автора это попытки избегания основной деятельности (ради которой существует группа) с сохранением имеющихся преимуществ и защитой психики.
vlatro
06.06.2024 11:27+7То есть если разработчик вместо того, чтобы прилепить «простой как таракан» костыль (поверх десятка других костылей от предыдущих «няшек»), вникает в суть проблемы и решает её в корне, зачастую - просто поменяв местами пару строчек кода - то он душный?
Поздравляю автора, ебл@н detected. Собственно, использование термина «душный» - это сразу красный флаг.
Pijng
06.06.2024 11:27Люди здесь почему-то проводят строгое равно между «душнилой» и «человеком, который не дает команде говнокодить и костылять и вообще в соло тащит бизнес». Конечно в таком свете он красавчик!
Но это же совсем не обязательные критерии душнилы, разве нет?
Душнила – это не только когда ты написал ужасный код, а он его рационально критикует. Душнила – это еще и когда ты написал хороший код, учитывая многолетний опыт на этом участке, но он все равно сидит и ввиду своей вечного «я знаю лучше» продолжает душить. Говорит как ужасно будет реализовать «вот такое» – ты даешь ему пример кода с адекватной реализацией, а он ему просто… не нравится. И вот вы уже две недели спорите в ревью, а к тебе каждый день приходит техдир с вопросами «ну что там, выложили рефактор? Нас надо следующую интеграцию делать»
Душнила – это еще и когда к тебе приходит фронтенд и спрашивает «а какого черта у вас бэкенд делает/отдает вот так». Идешь смотреть, а это было написано не пойми кем лет 12 назад, за 5 лет до тебя. И почему так было сделано уловить не можешь.
Идешь говорить это, а в ответ «ну это же странно? Ну согласись. Никто так не делает. И вообще из-за этого мы сталкиваемся с X, Y и Z. Или ты не согласен? Ну это ж очевидно».
А ты вообще этот код впервые увидел. Сидишь и думаешь: «к чему ты мне все это пишешь. Просто скажи как тебе хотелось бы и я прикину как это лучше сделать»
Душнила – это еще и когда ты нашёл простое решение проблемы, которую все принимали как должную пару лет и даже преподносили как фичу клиентам, а в ответ прилетает духота с токсом в духе «да не решит это кейс полностью, что если *ситуация, которая как раз решится*. Это нерешаемо. Хотя что мне, хотите себе работы – делайте. Почему звучит как хотели как лучше а получилось как всегда».
А ты выкатываешь доработку и, о чудо, все решилось.
Классно, конечно, выставлять душных людей как последний светлый рубеж в темном потоке говнокода, но это далеко не всегда так.
Gutt
06.06.2024 11:27+1Привет от душнилы! Во вступлении и в основной части рассказывается о разных явлениях.
FlyingDutchman2
06.06.2024 11:27+3задача требует простого как таракан решения
Автор попал прямо в точку!
Когда я был молодым, то все было простое, как таракан.
Но потом я стал более опытным и стал действовать по правилу: "Семь раз отмерь, один раз отрежь".
А сейчас у меня 30 с лишним лет опыта, и правило поменялось: "Семь раз отмерь, потом еще семь раз отмерь, и только потом немного отрежь".
sshikov
06.06.2024 11:27только потом немного отрежь
так чтобы можно было обратно пришить/приклеить?
FlyingDutchman2
06.06.2024 11:27+1Так, чтобы можно было обратно пришить/приклеить?
Точно! Например, в прошлом месяце нужно было удалить неправильные данные из одной таблицы в базе данных. Так я не только удалил, но и создал отдельную таблицу, куда на всякий случай записал удаленные данные. Мало ли что...
Причем эти данные снабжены ID, по какому можно точно узнать, каким именно оператором DELETE они были удалены.
ivandreevich11
Прочитал, проветрил! Кто минусует тот душнила и точка!
AntonSenior Автор
+++