Комментарии 103
Прочитал, проветрил! Кто минусует тот душнила и точка!
+++
В общем статью стоило назвать "просто душнилы" или "геть всех кому за 40". Есть люди которые попадают в IT случайно и таких большинство. Лично я попал волей судеб, всегда было хобби. Но однажды, меня можно сказать заставили попробовать поработать. И честно я рад и не жалею. Жалею только о том, что надо было раньше. И вот уже имея достаточный опыт в разных коллективах. Могу точно сказать, что "душнила" это просто случайный человек, с комплексом психологических проблем. Тех же молодых специалистов может бомбить на ровне с "бывалым" просто от того, что у них профильное образование, а понимание задач и скорость и выполнения, хуже чем у " менеджера по уборке". Девочек может бомбить низкая популярность среди мальчиков, мальчиков наоборот ( ну или в любых вариантах)). Троллинг тоже имеет отдельное место в формировании "душнилы". Любого можно затравить так, что он станет всех ненавидеть. Как в той самой песне "собака бывает кусачей, только от жизни собачей...".
Личное КПД. Тут конечно возраст играет роль, но если ты лентяй, и нет личной мотивации, то любой с мотивацией тебя уделает. Работать по 12-18 часов в сутки, в течении недели, пока не начнёт трясти от усталости, не каждый сможет. Конечно не призываю так делать, это очень вредно. Но "душнил" это бомбит. Так как например, вместо работы в 20 лет многим хочется не работать, а просто жечь и я их понимаю и не осуждаю. И вот такие могут спокойно устроить войну одному человеку. Даже если задача, их вообще их не касалась. Их бомбит просто успех, и они становятся "душнилами".
И наверно в конце хочется добавить про личную ответственность. Если уважаемый автор понимает, что вокруг него "душнилы " и он способен проанализировать обстановку то, это накладывает личную ответственность. Я считаю, если тебе дали свыше дар аналитики то пускать его нужно во благо. И вместо того, что бы самому становиться "душнилой", лучше помочь коллективу, стать более сплочённым и постараться сгладить все недомолвки и не до понимания. Человек - должно звучать гордо. Статистика "душнил", дело "статистов")).
"Более 5 лет в индустрии"
"люди в возрасте к любой проблеме относится дотошней и пытаются предусмотреть все пути эскалации, когда задача требует простого как таракан решения"
Кажется, вам еще надо лет 10 походить по граблям, чтобы не увлекаться тараканами.
Вспоминается выражение с картинки гуляющей где то в просторах сети.
Цитирую:
А как так вышло, что необразованные люди смогли сместить фокус со своей некомпетентности в любом вопросе на универсальный ответ: "Хватит душнить" ?
"задача требует простого как таракан решения", дальше серьезно читать не смог
Потом эти "простые как таракан решения" оставляют публичный адрес с any/any и забывают, что они его вообще открывали, ведь всё должно быть просто, просто перескочили на другую задачу, просто сделали без запроса и не спросили как надо, просто ничего не надо документировать, всё же так просто!
Человек не понимает, что таракан - очень сложное устройство.
А если в команде весь бизнес обеспечивает именно этот "душный человек", а остальные няшки балду пинают?
Очевидно же решение: больше никто не нужен.
Выгнать всех няшек к чорту, пусть душнила дальше баржу тянет.
Нет, бывает так, что всю архитектуру проекта продумывает один человек. Все идеи, которые потом продает бизнес, придумывает и продвигает он. Он же материт всю остальную команду и требует высокого качества кода (при том, что никаких стандартов предприятия на этот счет нет).
Остальные реализуют классы, пишут юнит-тесты, скрипты, короче всю черную работу.
Он же материт всю остальную команду и требует высокого качества кода (при том, что никаких стандартов предприятия на этот счет нет).
ой у нас так было, причем бизнес нам не оплачивал ни рефакторинг ни юниттесты ни реализацию фич
а этот чел постоянно нас материл что у нас этого всего нет и качество хромает
но его задача была стратегию и архитектуру указывать, то что у нас бюджетов нет его не волновало...но вымещал он это почемуто на отдел разработки, а не на бизнес (с его т.з. мы наверное должны были бесплатно вне рабочего времени это все делать ради идеи)
Понимаю. Но я имел в виду - писать качественный код сразу. А не навалить как попало, а потом рефакторить и юнит-тесты дописывать. Бизнесу хочется, чтобы сразу было хорошо. А ваш человек ругался на что - что вы с начала наваливали некачественный код, или что вы не хотели некачественный код исправлять? Это разные вещи.
разные согласен, но разработка у нас выглядела так
нужно сделать фичу, сколько оцениваете? две недели... окей, вот вам 4 дня на разработку два на тестирование в пятницу релиз, понедельник дедлайн. точка.
это все на фоне фраз "вы должны сразу писать код без ошибоч чтобы даже без тестирования выливать его в прод и он отлично работал, мы не готовы вам платить за это, и оцениваем вашу работу в 4 дня и так уж и быть даем два дня на тесты" (с)
Как сказал классик: "я сделаю эту работу за 4 часа в течении месяца".
От себя добавлю: как же задолбали специалисты с большой дороги. Ты или делай чтобы за тобой не переделывать, либо поумерь своё ЧСВ. За переделки никто не хочет платить, особенно заказчик.
Хм, а зачем работать в конторе, которая двухнедельную работу заставляет сделать за 4 дня? Если нет взаимопонимания, то ничем хорошим дело не кончится и чем раньше прервать отношения, тем лучше, тк затягивание может привести только к эскалации, конфликтам и прочим выгораниям.
Не не не. 2 недели на фичу. Разработка 4 дня, потом тестирование, исправление багов, тест фиксов и релиз. Как раз две недели минимум.
Правило разработка умножить на пи в действии.
Вот я там теперь и не работаю :))
Подгорел я знатно конечно, но опыт очень любопытный теперь есть, управлением экстремальной разработкой
Положим, это оценка бизнеса.
Не положено. Партнеры, контрагенты - не поймут, как это в такой блестящей крутой компании (по рассказам, например, гендира или маркетологов), всего 1 ключевой сотрудник ИТ. Нужно "как у всех, эджайл, девопсы, тимлиды, тестеры" и т.п.
P.S. Без смеха, реальный пример из жизни.
Нет, не верно. С точки зрения бизнеса (при правильном понимании производственного процесса, конечно) выгодно освободить "звузду" от черновой низкоквалифицированной работы, дав ему только "звездные" задачи. Нанять и перетряхивать джунов и мидлов за копейки, пусть черновую, повторяюсь, работу выполняют, а "звезда" путь высокие задачи делает.
Задача тимлида, точнее, начальника группы - именно это и обеспечить. А задача СЕО, кстати - убедиться, что тимлид это понимает и выполняет. И не "душнилу" чморит, а следит, чтобы "звезда" "несла золотые яйца". И варежку недовольным джунам затыкает, если им не нравится со "звездой" работать.
Естественно, если наш душнила на самом деле "звезда", ценная для бизнеса.
<душнила>
"Из-за размазывания каши по тарелкЕ..."
</душнила>
— Встречали душых людей в IT?
— Конечно встречал, это я.
Душнила:
Вообще-то, "душнила" и "токсик" – это не одно и то же. А эти 5 "признаков" не имеют особого отношения ни к тем, ни к другим.
Токсик:
Прежде чем писать подобного рода "туториалы", неплохо бы в вопросе разобраться.
Только людям с двузначным IQ не нравится этот пост
Да-да, видел я этих весельчаков которые быстро наговнокодили и не душно катапультировались на другую работу
да, духаны встречаютс конечно, а если скажешь ему что он духан, начнет вонять еще больше
ты специально зарегистрировался в очередной раз, чтоб написать этот коммент, серьезно?)
И мы после этого духаны?)
@Sergeilunin не твой твинк?
Не хватает пункта в голосовании "Это я" :)
Спрашиваю: "Документ сложный, "размазан" по множеству таблиц. Вполне вероятна ситуация одновременного редактирования несколькими пользователями одного документа. Почему вы используете РСУБД, не поддерждивающую транзакции (и внешние ключи)?"
Отвечает: "Вероятность одновременного редактирования одного документа весьма мала, зачем душнить?"
Да, я старпёр и душнила.
Почему вы используете РСУБД, не поддерждивающую транзакции
Такие еще остались?
MySQL 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/
Не все же обновляют БД каждый год.
Зачем писать что-то, требующее транзакций и внешних ключей, на чем-то, где этого нет? Зачем тут вообще что-то спрашивать, отвечать, обсуждать?... Как СУБД вообще может быть реляционной, если не поддерживает внешние ключи? В чем ее реляционность?
Почитайте оригинальную статью Кодда про реляционную модель, там вообще почти ничего нет, даже order by.
Ну вообще-то Кодд потом разработал свои 12 правил
Внешние ключи относятся к правилу 10: Integrity Independence.
А поле с версией может помочь при отсутствии транзакций? При редактировании документа, конечно а не при финансовых проводках.
Т.е. максимально подложить "соломки", обеспечить возможность обойти большинство грабель, и подводных камней - душность?
Проигнорировать все советы, рекомендации более опытного сотрудника(а то и руководителя), наступить на все грабли, собрать все подводные камни - это норм?
В современных реалиях разработки - к сожалению, да (. Сплошь и рядом. Радуйтесь, что разработчики вообще задумались об одновременном редактировании документа, могли бы просто наивно пройти мимо, а разваливание логики прикрыть универсальным обработчиком - oops, что-то пошло не так ;( - приносим извинения. попробуйте еще раз.
Похоже на ситуацию, при которой очень поверхностно знакомый с темой человек начинает неадекватно реагировать на уточняющие вопросы "душного человека".
проблеме относится дотошней и пытаются предусмотреть все пути эскалации
Ага ты им говоришь CAN через MQTT в вашем случае не передать, у вашего железа таймаут 25мс на ответ. Неее ты душный всё будет ок, ребят да пинганите свой сервер в амазоне и гляньте время, ты ооочень душный. Кидай нам пакеты в MQTT и всё будет ок. Ну ок, мне не сложно, вот вам пакеты. Ой у нас ничего не работает......
Ну что, поехали душнить.
Негативизм: Постоянные жалобы, критика без конструктивных предложений.
Принесли мне как-то разработчики список интеграций по проекту. Из более чем 50 - ни одной целевой. JDBC к чужим БД, DB-линки, SOAP. Корпоративным стандартом была сервисная шина. Внимание вопрос. Какое конструктивное предложение мне им дать? Использовать рекомендованные? Тогда они не успеют за две недели вау-эффект дать. Это основная их цель была. А моя цель - контроль соблюдения стандартов и проверка применимости правильных технологий. Это мои должностные обязанности, я не имею права им разрешать этот лютый трэш
Дальше больше. Собрались на троих директор программы, директор проектного офиса и технический директор. И решили, что архитектору, то есть мне, хватит пять дней на создание архитектуры проекта. Потом три дня на согласование, потом два дня на утверждение, и через две недели они откроют проект. Регламент - согласование БТ сколько потребуется, 15 рабочих дней минимум на архитектуру, 22 рабочих дня на согласования, минимум неделя на утверждение, если звезды сойдутся. БТ нет как явления. Проект - дичь. Критически важны НФТ, но их никто не в состоянии сформулировать. Уровень аналитики - мне пришлось объяснять, что части заложенного в проект бизнеса в банке нет как явления. И никогда не будет. Внимание вопрос. Какое конструктивное предложение им дать? Почитать регламенты и следовать им? Разработать БТ? НФТ? Тогда они не успеют за две недели вау-эффект продемонстрировать, цели не изменились глобально.
Итог. Жалоба моему руководству, что я всем вставляю палки в колеса. Истерика руководства - этот проект надо делать проактивно. ТРИ МЕСЯЦА на согласование архитектуры - это не от меня зависело, и я с самого начала объяснил, что будут именно так, ибо проект - дичь, и НФТ нет. Утверждение... и еще одна истерика моего руководства - как мы вообще на это подписались? Проект - дичь! Именно. Я это говорил с самого начала. Но у всех складывается пост-ощущение, что именно я жалуюсь, критикую и не даю никакого конструктива.
Неспособность к сотрудничеству: Отказ от командной работы, изоляция, неготовность к компромиссам.
Приходит такая команда и говорит - а давай мы тут накостылим, наговнокодим, а исправим когда-нибудь потом. Нам квик-вины нужны и вау-эффект. Нет, говорю я, это пойдет в пром, извольте делать правильно. Всё, это отказ от командной работы и неготовность к компромиссам
Микроменеджмент: Стремление контролировать каждый шаг коллег, что тормозит рабочий процесс.
За следующий месяц я пять раз ловлю команду на попытках мошенничества. Реализации костылей, на которые я не согласился. Завышение трудозатрат, дикое - на xslt-преобразование на шине, на которое я на прямое и обратное потратил минут 20 с тестированием, заложили 45 человеко-дней. И т.п.
В итоге приходится контролировать каждый шаг. Микроменеджмент. Скорость реализации возрастает в несколько раз, что вызывает сильное недовольство РМ - начинаются вопросы, на что он запрашивал столько денег и времени. Проект передают другому архитектору, который позволяет всё. Через полгода в проме инцидент на 20К евро двойного списания, в котором обвиняют... архитекторов. Которые "разрешили" те самые костыли. И не проконтролировали (!!!), что их исправили. Оказывается, микроменеджмент был нужен.
Неумение принимать критику: Защита своих ошибок, отказ признавать и исправлять их.
Реализовывал я как-то, еще будучи разработчиком, визуальную раскладку графов. Через библиотеку ILOG JViews. Там были несколько менеджеров, дававших красивые и быстрые результаты. На графах узлов в 20 и строго определенной топологии.
И был у шефа любимый граф, очень неудобный для всех раскладок - 450 с лишним узлов, топология... никакая. Неклассифицируемая. Самый красивый результат давал один менеджер - секунд за 15. И это было ну ОЧЕНЬ долго. В итоге шеф сам взял толстенное руководство и отметил все настройки, которые надо применить. Дальше я непосредственному начальнику три часа рассказывал про каждую из них, показывал, как они у меня выставлены, как они меняются и к чему это приводит. По всему выходило, что оптимально всё. А значит, я защищаю свои ошибки, отказываюсь их признавать и исправлять. Далее уже искали повод, чтобы меня уволить. Поводом стало слово "рефакторинг" - я собирался ничего не делать аж две недели.
На мое место пришел студент, который посмотрел на всё это и сказал, что я м-дак, а он всё сейчас настроит. "Ага!" сказал шеф. Настроили. Во время показа шеф открыл любимый граф, нажал кнопку - и всё зависло. Перезагрузили. То же самое. Ушли разбираться. А потом оказалось, что студенческая поделка запускает раскладку в event dispatcher thread - то есть приложение даже отрисовываться перестает. И работает что-то около 45 минут. Случайно оставили после нажатия кнопки, отвлеклись - и дождались окончания процесса.
Но кто там душный, отстаивает свои ошибки? Я, конечно. Студент вообще не при делах, он студент.
Создание конфликтов: Постоянные споры и разногласия, нарушение атмосферы доверия в команде
Собственно, всё сказано выше. Если целью части команды не является сделать дело, а для другой части это задача первостепенная - конфликт неразрешим. Это будут постоянные споры и разногласия. У меня стоит задача уменьшения времени согласования в конечном итоге, это уже известная боль во многих случаях. А продукту нужно вывести в пром новую фичу, а заботиться о согласовании данных они не хотят. Когда-нибудь реплицируются. Нет времени. Нет компетенций. И т.д. и т.п. И конфликты порождает кто? Тот, кто заботится, чтобы им в итоге не прилетело. Но это будет когда-то потом. Или не будет. Бизнес в погоне за прибылью откровенно нарушает законодательство. А когда приходит ЦБ с неудобными вопросами - все бегут к архитектору: а почему мы только сейчас узнали, что мы вот это всё должны по закону делать. А потому что, а) вы не читаете этих законов, хоть это и есть в ваших должностных инструкциях, и б) вам это говорили сделать из общих соображений с самого начала. Но у вас не было времени и желания. И кто в итоге спорит и разногласит? Ну не бизнес же!
Проще говоря. А вы уверены, что всё происходящее - это потому, что я душный? А не потому, что у меня 25+ лет опыта в разработке, а у вас от силы 5?
P.S. Вот это особенно понравилось:
Четкое следование рабочим процессам
По опыту - не родилась еще компания сложнее макдачной, которая сможет досконально прописать свои процессы настолько, чтобы они работали, если им следовать от и до. Да и к макдаку вопросики есть.
А вообще четкое следование инструкциям называется итальянской забастовкой. Угадайте, Автор, почему.
Душнила и токсик не могут обьяснить свои претензии, потому что они основаны на эмоциях, на зависти, лени, ЧСВ, и прочих подобных вещах. Нытье и баттхерт по любому поводу - основное состояние душнилы.
Недовольный чем-то адекват может доходчиво обьяснить свою позицию с практической стороны, что и видно в этом каменте. Адекват может ткнуть мордой в косяки и обьяснить, зачем так, а не иначе. Душнила не может.
Вот я и узнал, как выглядит кровавый энтерпрайз))))
Духан (араб. دكان) — на Ближнем Востоке и в Афганистане лавка, небольшой магазин; на Кавказе и в Крыму название небольшого ресторана или харчевни.
---
Сломал себе всю парадигму о ваш заголовок. Есть же хорошее и широкоиспользуемое слово "душнила" - зачем изобретать велосипед?
Какие культурные у вас ассоциации.
Взял с собой её Иван,
Положил её в карман.
Там лягушка чуть не сдохла! —
От Ивана шёл духан.
Есть же хорошее и широкоиспользуемое слово "душнила" - зачем изобретать велосипед?
Душните. :)
Широкоиспользуемое, но точно не хорошее. Даже "зануда" в себе содержит меньше негатива. Я вообще решил, что слово "душнила" используют в адрес тебя те, кто просто не хочет/не может понимать/разбираться.
Интересно. Получается, что дүкен / дүкөн / dükan и т.д. в тюркских языках -- заимствованное слово?
Знает больше меня, не дает говнокодить, не дает внедрять новый_модный_фрйэмворк - душнила!
GPT, уходи!
Мне кажется, что-то даже в структуре текста такое есть, что выдаёт творчество AI. Ну и в целом, бестолковая статья с нулевой пользой.
Ради смеха попросил гпт-чо написать "статью про душнил в IT с хорошей структуров и не банальным выводом", она вывалила портянку текста, до зубной боли похожую на этот опус
Вот сейчас ты его гонишь, а через пять лет он в твоей кошкожене будет душнить в отместку :)
Автор, несомненно душнила, поскольку соответствует как минимум 3-м пунктам своего же определения: негативизм, создание конфликтов, неумение принимать критику.
Впрочем, статья написана просто чтобы немного хайпануть и этого результата достигла.) И ведь получился едва ли не эталон жанра. Модная тема, коротко, доступно. В следующий раз рекомендую написать про эмоциональное выгорание, тоже хорошо залетит.
Там не только хайпануть результат получился. Еще -9 к карме - и автор в read only уйдет.
Ну не, до той легендарной статьи автору ещё далековато...
Если имелась в виду карма -10, то я сейчас забил этот последний гвоздь, отметив все галочки, служу Отечеству и Хабру.
В следующий раз рекомендую написать про эмоциональное выгорание, тоже хорошо залетит.
У нас всё равно уже нет сил про это читать...
Разработчик, 46 лет. Поставил минус.
Прочитав заголовок подумал что речь пойдет о дедовщине в IT )
Тем не менее, эта публикация оказалась полезной для нескольких человек, желающих совершить кармосуицид))
Автор конечно круто э... заэйджшеймил кучу народа ))). Я уж думал взбрыкнуть, потом прочитал классификацию, перешел к методам решения... Я бы сказал "душный" человек это другое. Зануда не по делу. А люди описанные автором... это токсики (упс, это уже написали). На мой взгляд это люди не на своем месте и значит с внутренними проблемами. В научной среде таких крайне мало (там другие типажи) , но одного я знаю. Человек по сути в ловушке - для научной работы у него нет нужных способностей, а амбиций много, в результате зависть, гиперкомпенсация, конфликтогенное поведение с коллегами на ровном месте. Руководство удивляется, что он делает у нас, почему не уходит (необходимый минимум требований он всё же выполняет).
На мой взгляд, все пункты перечисленные у автора это попытки избегания основной деятельности (ради которой существует группа) с сохранением имеющихся преимуществ и защитой психики.
Я думал, про джунов статья..
А где пункт:
Я не просто душнила, а ещё и токсик?
То есть если разработчик вместо того, чтобы прилепить «простой как таракан» костыль (поверх десятка других костылей от предыдущих «няшек»), вникает в суть проблемы и решает её в корне, зачастую - просто поменяв местами пару строчек кода - то он душный?
Поздравляю автора, ебл@н detected. Собственно, использование термина «душный» - это сразу красный флаг.
Люди здесь почему-то проводят строгое равно между «душнилой» и «человеком, который не дает команде говнокодить и костылять и вообще в соло тащит бизнес». Конечно в таком свете он красавчик!
Но это же совсем не обязательные критерии душнилы, разве нет?
Душнила – это не только когда ты написал ужасный код, а он его рационально критикует. Душнила – это еще и когда ты написал хороший код, учитывая многолетний опыт на этом участке, но он все равно сидит и ввиду своей вечного «я знаю лучше» продолжает душить. Говорит как ужасно будет реализовать «вот такое» – ты даешь ему пример кода с адекватной реализацией, а он ему просто… не нравится. И вот вы уже две недели спорите в ревью, а к тебе каждый день приходит техдир с вопросами «ну что там, выложили рефактор? Нас надо следующую интеграцию делать»
Душнила – это еще и когда к тебе приходит фронтенд и спрашивает «а какого черта у вас бэкенд делает/отдает вот так». Идешь смотреть, а это было написано не пойми кем лет 12 назад, за 5 лет до тебя. И почему так было сделано уловить не можешь.
Идешь говорить это, а в ответ «ну это же странно? Ну согласись. Никто так не делает. И вообще из-за этого мы сталкиваемся с X, Y и Z. Или ты не согласен? Ну это ж очевидно».
А ты вообще этот код впервые увидел. Сидишь и думаешь: «к чему ты мне все это пишешь. Просто скажи как тебе хотелось бы и я прикину как это лучше сделать»
Душнила – это еще и когда ты нашёл простое решение проблемы, которую все принимали как должную пару лет и даже преподносили как фичу клиентам, а в ответ прилетает духота с токсом в духе «да не решит это кейс полностью, что если *ситуация, которая как раз решится*. Это нерешаемо. Хотя что мне, хотите себе работы – делайте. Почему звучит как хотели как лучше а получилось как всегда».
А ты выкатываешь доработку и, о чудо, все решилось.
Классно, конечно, выставлять душных людей как последний светлый рубеж в темном потоке говнокода, но это далеко не всегда так.
Какой же автор душный!
Привет от душнилы! Во вступлении и в основной части рассказывается о разных явлениях.
В последнее время стало много мутных статей от пафосных лиц, которые в ник себе без за зрения совести пихают то "директор интернета", то вот, скромный сеньер решил обратить на себя внимание.
задача требует простого как таракан решения
Автор попал прямо в точку!
Когда я был молодым, то все было простое, как таракан.
Но потом я стал более опытным и стал действовать по правилу: "Семь раз отмерь, один раз отрежь".
А сейчас у меня 30 с лишним лет опыта, и правило поменялось: "Семь раз отмерь, потом еще семь раз отмерь, и только потом немного отрежь".
только потом немного отрежь
так чтобы можно было обратно пришить/приклеить?
Так, чтобы можно было обратно пришить/приклеить?
Точно! Например, в прошлом месяце нужно было удалить неправильные данные из одной таблицы в базе данных. Так я не только удалил, но и создал отдельную таблицу, куда на всякий случай записал удаленные данные. Мало ли что...
Причем эти данные снабжены ID, по какому можно точно узнать, каким именно оператором DELETE они были удалены.
Какая-то ДУШНАЯ статья
Тот самый душнила на связи. Постоянно требую от коллег соблюдать установленные производственные нормы, пользоваться специально подготовленными для них инструментами, документировать свою работу, по-человечески оформлять тексты и красиво форматировать таблицы. При этом в моем подразделении на порядок меньше бюрократии в работе, чем в соседнем похожем, я не душу коллег вещами типа KPI. Работу надо выполнять качественно, с полной отдачей, четко и красиво. И знать границы, где перфекционизм, а где имитация деятельности. Топы будут ценить таких своих сотрудников. А от этого всем только польза (и премии). Спасибо за внимание.
Духаны в IT