Как стать автором
Обновить

Комментарии 34

Коллега: Смотрите, ваша кнопка не работает!

Если не назначен ответственный и проблему впихивают не через таск-трекер, за эту задачу естественно никто не возьмётся, потому что всем явным образом уже назначены задачи, уже достигнуты договорённости по планам и никто не станет резко менять их из-за того, что коллега решил поиграть в чайку.

Всегда можно в чат написать «да, такая проблема похоже есть — добавь задачу в трекер». Или «да, мы уже знаем про проблему, вот тикет». А может оказаться и что «это не бага а фича, мы обсуждали и решили так сделать потому-то и потому».

Да, но кто должен писать это в чат? Все разработчики или участники чата сразу? Да нет. Писать должен отвественный. А кто им назначен - уже не столь важно. Суть в том, что когда в чате пишут "все пропало", то никогда не понятно, кто и в каком приоритете должен это решать.

В нормальной имплементации решения такой проблемы в чатах всегда есть люди, к которым непосредственно можно обратиться по проблеме, не дергая весь чат и обижаясь потом на всех, что мол "буки неразговорчивые, тут же кризис мировой назревает".

Любой кто может содержательно ответить по проблеме. В том числе указав на «ответственное лицо» к которому надо обратиться, ибо в больших командах, увы, сложно наизусть знать кто из десятков человек за что отвечает.

В больших командах это нивелируется отдельным "чатом" с ротацией ответственных, задача которых и есть отвечать на все запросы. Есть сообщение - есть ответ, т.к. есть отвественный и обязанность.

Неужели вы не встречали ситуацию, когда на один вопрос получается два противоположных ответа, и в треде этого вопроса начинают устраивать баталии на тему "как должно быть"? Зрелище так себе. Уж лучше отсутствие ответа.

Нет, баталии не встречались. Во-первых у нас в этом плане все всегда весьма уважительно к оппонентам, так что до баталии просто не доходит. Во-вторых сама ситуация что двое человек имеют настолько разные представления что готовы спорить что другой вариант не имеет права на жизнь, говорит о наличии явной проблемы требующей решения. Назначается митинг, на нем проблема обсуждается, по итогу вырабатывается общее решение. Особенно эффективно работает в офисе где можно просто подойти к человеку и обсудить все сразу же у доски, но по вебке тоже приемлемо. У команды все же на мой взгляд должно быть общее видение целей и путей которыми они достигаются и чем раньше выявятся подобные разногласия — тем лучше. Куда хуже когда эта разница во взглядах всплывает лишь в конце и выбор заведомо начинает сводиться к «жить с тем что считаешь г-ом» или «выкинуть результат работы несколько месяцев». Сойтись на варианте который обе стороны считают оптимальным конечно не всегда получается (но довольно часто), но даже если принимается решение с которым один из участников не согласен, то он по крайней мере остается с пониманием почему такое решение принято и в следующий раз в чате озвучит именно принятое решение (вероятно с ремаркой что он с ним не согласен, но у его читателя все равно возникнет правильное понимание ситации. А вот вариант разрешения конфликтов где текущая версия того чем должна заниматься команда зависит от того кто сейчас дежурный меня как-то откровенно смущает.
Это хорошо, когда есть с кем обсудить и есть вероятность, что кто что-то дельное предложит и вообще способен предложить. А когда ты заведомо знаешь, что ничего, кроме тонны словоблудия и ненужных обсуждений с «маркетологами» не получишь — намного эффективней просто тупо взять, и решить проблему, никому ничего не сказав или сообщив о решённой проблеме по факту.

«Наша задача кодить, а не болтать».

(надевает мантию адвоката дьявола) Ну разумеется, именно инженеру надо идти и выяснять - кто и что имел в виду на самом деле.

Непонятно только, почему клиенту обещают

  • менагеры пяти ступеней,

  • руко-водители проектов и групп,

  • лиды и их падаваны,

  • аджайл-мастера и скрам-паладины,

  • бизнес-аналитики и консультанты,

  • архитекторы систем и решений,

  • маркетологи и продаваны,

  • топ-топы и сеньор випи с обоих сторон

    Но потом никто не знает - что в итоге пообещали...

НЛО прилетело и опубликовало эту надпись здесь
Есть куча менеджеров, архитекторов и прочих непонятных людей которые за это получат деньги.


Действительно, понаберут всякого сброда, только под ногами путается. То ли дело мы, Разработчики, соль земли.

Простите, но именно так это и читается в вашем исполнении. И мне, как представителю этих самых непонятных людей, немного обидно. Особенно когда разработчик мой без меня не знает и не понимает, что и зачем нужно делать.
Если эти «непонятные люди» занимаются правильными делами — общаются с заказчиком и составляют корректное ТЗ, продумывают архитектуру, планируют работу так, чтобы минимизировать потенциальные потери и т.д. — это одно, это пусть и непонятные, но полезные люди.
А когда на разработчика (самого, пожалуй, далёкого от заказчика лица) сваливается задача «сделать хорошо» — он и «делает хорошо», только в своём понимании. А потом кто-то из всей этой цепочки «непонятных людей» начинает вздыхать, что всё получилось не так, как задумывалось. Это совсем другое дело — непонятные и бесполезные, посасывающие деньги из компании, люди. Таких надо палкой гнать, потому что они не делают того, чего должны.

«Перекидывание обезьянки» между прочим исключительно важный, и часто полезный прием. Иногда босс уже знает как решить проблему и просто ищет повода высказать решение. Или не знает, но если он умеет делегировать, то скажет сразу, и можно получить карт бланш на поиск решения. В любом случае спрашивая начальство мы намекаем на то, что оно тоже компетентно в данном вопросе.

Если же все время затыкать начальство своими идеями не дав ему высказыватьсч это выглядит не очень хорошо.

Все хорошо описано и мне как менеджеру проекта все это очень знакомо.

Но надо не забывать и о второй стороне вопроса:

Иногда данные подходы вырабатываются из-за непрофессионального подхода менеджеров к инженерам. Такие как:

  1. "Чайка-менеджмент"

  2. "Я начальник - ты дурак"

  3. "Знать ничего не знаю, но чтобы к утру было сделано"

  4. "Вы ни хрена работать не умеете"

Просто мысли вслух... А то иногда на коллег менеджеров посмотришь и печально становится...

Да здесь почти все примеры так или иначе - непрофессиональный или некомпетентный менеджмент.

Во-первых, я такие примеры антикоммуникации (и как инженер, и как менеджер, и как архитектор) часто видел не со стороны инженеров - об этом отдельно - а со стороны менеджеров. Инженер часто человек простой или по крайней мере ведёт себя, как простой: сломалось - скажет что сломалось, задача не готова к деплою - скажет, что не готова. А менеджеры, если не могут спихнуть ответственность (от тимлида до ПСД) начинают играть в игры, потому что факап сразу бьёт по ним.

Во-вторых, можно инженера задавить так, что он будет бояться сказать честно и конструктивно. Или лишить права выбора (а значит и ответственности). Или просто поставить KPI, который будет конфликтовать с открытой культурой (привет, "количество ошибок, выявленных в эксплуатации"). Да, блин, все хорошие корпоративные культуры похожи друг на друга, каждая несчастливая корпоративная культура несчастлива по-своему. Если есть симптомы "антикоммуникации", то в первую очередь истоки надо искать в верхушке менеджмента. И решение примерно там же.

В-третьих, самое отвратительное, что эти антикоммуникации проявляются в работе с клиентами. "Умалчивание, игнорирование и искажение"? Каждый день, особенно крупные компании. "Оправдания вместо решений"? Вспоминаем любую из громких утечек персданных. "Игнорирование"? Пробейтесь через нашего чат-бота, потом и поговорим. "Эмоциональная реакция на конфликты"? Поищите среди топовых статей на хабре с критикой компаний ответы менеджеров этих компаний. "Страх идти на конфликт"? Да каждый день. И инженеры тут ни при чём.

Подобные примеры есть в рассказе Р.Фейнмана (в составе книги «Какое ТЕБЕ дело до того, что думают другие?»: Продолжение невероятных приключений Ричарда Ф. Фейнмана, рассказанное Ральфу Лейтону («What Do You Care What Other People Think?»: Further Adventures of a Curious Character) о том, как он участвовал в комиссии по расследованию катастрофы «Челленджера». Антикоммуникаций там хватало

и в процессе производства шаттла:
Я сказал: «Мистер Ламберт сказал, что предупреждал Вас о том, что нельзя превышать давление в 1200 ф.к.д.»

— Он никогда не предупреждал меня об этом — а почему он должен был это сделать?

Подумав, мы поняли, как такое могло произойти. Предупреждение мистера Ламберта спускалось вниз от уровня к уровню, пока кто-то из среднего звена менеджеров не осознал, что мистер Фичтел работает согласно книге, а значит технологический процесс содержит ошибку. Однако вместо того, чтобы рассказать об этой ошибке мистеру Ламберту, они просто выбросили предупреждение и не стали усложнять себе жизнь.


Я сказал: «Чтобы ускорить процесс, я скажу вам, что я делаю, чтобы вы знали, к чему я стремлюсь. Я хочу знать, существует ли такое же отсутствие передачи информации между инженерами и менеджерами, которые работают над двигателем, какое мы обнаружили в случае с ракета-носителями».

Мистер Ловингуд говорит: «Я так не думаю. В действительности, несмотря на то, что сейчас я — менеджер, я имею инженерное образование».

— Хорошо, — сказал я. — Я дам каждому из вас по листу бумаги. Пожалуйста, напишите на этом листе ответ на мой вопрос: какова, по-вашему, вероятность того, что полет шаттла может не состояться из-за какой-нибудь поломки в этом двигателе?

Они написали свои ответы и отдали мне листы. Один парень написал «чистота 99,44 % из ста» (он повторил лозунг фирмы, выпускающей мыло «Айвори»). 99,44 % из ста означало, что вероятность отказа двигателя примерно 1 шанс из 200. Другой парень написал что-то очень техническое и высококоличественное в стандартном статистическом варианте, аккуратно определяя все данные, что мне пришлось переводить на нормальные цифры — и что тоже значило 1 из 200. Третий парень просто написал: «1 из 300».

Однако на листе мистера Ловингуда было написано:

Не могу дать количественную оценку. О надежности судят по:
• прошлому опыту;
• контролю качества при производстве;
• оценке инженеров.

— Что ж, — сказал я, — я получил четыре ответа, и один из них выказывает попытку улизнуть. — Я повернулся к мистеру Ловингуду: «Я считаю, что Вы улизнули от ответа».

— Я так не считаю.

— Вы не сказали мне, в чем Вы уверены, сэр; Вы лишь сказали, как Вы определили свою уверенность. Я же хочу знать вот что: после того, как Вы определили свою уверенность, чему она равна?

Он говорит: «100 %, — у инженеров отпадывают челюсти, у меня тоже; я смотрю на него, все остальные тоже, — э, э, минус эпсилон!»

Тогда я говорю: «Хорошо, прекрасно. Теперь единственная проблема состоит в том, чтобы узнать, ЧТО ТАКОЕ ЭПСИЛОН?»

Он говорит: «10». Это было то же самое число, о котором нам рассказывал мистер Уллиан: 1 к 100 000.

Я показал мистеру Ловингуду остальные ответы и сказал: «Вам будет интересно узнать, что здесь между инженерами и менеджерами тоже есть разница — с коэффициентом более 300».


и в работе самой комиссии:
— Но не забывайте, — говорил он, — это президентская комиссия. Мы должны сказать что-то для президента.
— Не вижу разницы, сказал я. — Почему я не могу быть объективным и научным, когда пишу отчет для президента?


Она говорит: «Нет, мне его никто не давал».

Тогда я иду в офис Кила и говорю: «Салли утверждает, что у нее нет копии моего отчета».

Он изображает удивление и поворачивается к своему секретарю. «Пожалуйста, сделайте копию отчета доктора Фейнмана для доктора Райд».

Потом я узнаю, что моего отчета не видел и мистер Эчесон.

— Сделайте копию и отдайте ее мистеру Эчесону.

В конце концов, я все понял и сказал: «Доктор Кил, я думаю, что моего отчета не видел никто».

Тогда он говорит своему секретарю: «Пожалуйста, сделайте копии для всех членов комиссии и раздайте им».

В конце концов, я ему сказал: «Я ценю ту работу, которую Вы выполняете, и я понимаю, что трудно запомнить все. Но мне казалось, что Вы сказали мне, что показали мой отчет всем».

Он говорит: «Ну, я имел в виду всем, кто здесь работает».

Позднее, во время разговора с людьми, которые там работали, я узнал, что они тоже не видели моего отчета.

Конечно это эффективнее некуда, сидеть три часа и пытаться самостоятельно разобраться, как работает соседний сервис, вместо того чтобы просто спросить у коллеги и получить ответ за 15 минут.

Ага, ага, можно еще вспомнить фразу «глупых вопросов не бывает» но реальность она другая - чем больше вы в коллективе задаете вопросов, тем больше о вас будет складываться впечатление, что вы ни в чем не разбираетесь.

Самое забавное, раз в своей жизни получал большой упрек (с фактическими последствиями), за слишком много вопросов, хотя этот же человек, до этого ругался на другого сотрудника, который сидит целыми днями и разбирается сам, вместо того, чтобы спросить.

Когда я ему это напомнил, разумеется, получил ответ про «надо знать меру», которая у каждого своя.

Так что сейчас, когда я смотрю на джунов, которые лучше 2 дня будут разбираться сами, вместо того, чтобы спросить и за 10 минут получить развернутый ответ - скажу, что правильно делают.

Может дело все же в том что надо ВНАЧАЛЕ попытаться разобраться самому а ПОТОМ уже спрашивать? Ибо вопросы таки да, бывают разные, и если человек задает слишком много вопросов практически каждый из которых можно было решить за 10 минут самостоятельно то это действительно создает впечатление о его некомпетентности (ну или о том что он пытается свалить свою работу на другого). Ну либо у Вас коллектив достался очень токсичный :), потому что у нас в компании вопросы по делу приветствуются гораздо больше чем игра в молчанку.

Задавать вопросы действительно сложно. Особенно сложно задавать вопросы, которые -- ты сердцем чуешь -- покажутся матерому эксперту глупыми, он закатит глаза, подумает "понабирали тут с остановки" и ответит на отвали или пошлет гуглить (спасибо, сам не догадался).

Я технический писатель, задавать разработчикам глупые вопросы -- моя работа, но мне до сих пор приходится прилагать некоторые душевные усилия, чтобы нажать кнопку "Отправить" под очередным письмом со списком вопросов. А новичку-разработчику с синдромом самозванца во всей красе, который думает, что должен сам это знать, что над ним будут смеяться за незнание, что он отвлекает важных бородатых дядек от *настоящей работы* своими глупыми вопросами -- ему действительно будет гораздо проще двое суток кусать кактус, чем поднять голову и спросить.

Это на самом деле очень плохо, и у меня нет простого решения этой проблемы. Если я еще могу прикрыться тем, что "это не я дурак, я-то всё понимаю, но я пишу для пользователя, поэтому объясните еще раз, как это работает, для протокола", то джуну остаётся только волевым усилием переступать через себя и спрашивать. Если он встретит понимание и получит ответ, то в следующий раз спрашивать будет легче. Если встретит порицание и одергивания, то будет дальше биться головой о стену со всеми вытекающими. Зависит от пресловутой рабочей культуры в коллективе, я полагаю, ну и от конкретных адресатов вопроса.

Лично я для себя вывел привычку начинать любые вопросы, которые мне кажутся очевидными/простыми, с "У меня тупой/глупый вопрос: ... ". После того, как эти "глупые" вопросы несколько раз порождали двухчасовые обсуждения с эскалациями, до меня на эмоциональном уровне дошло то, что я знал на рациональном - глупых вопросов не бывает.
Но фразочку всё равно использую, скрытно прививая её нашим стажёрам и наименее уверенным в себе членам команды.

Дисклеймер: это - не серебряная пуля; опробована только для снятия эмоциональных барьеров в одном дружелюбно настроенном коллективе.

ох, я тоже техпис, и знакома с этой проблемой. мне помогает такое отношение: я понимаю, что это разработчик, который сделал фичу, и только он знает, как именно она здесь работает. только ПМ знает, что именно об этой фиче должен знать юзер. моя здесь обязанность - выяснить, что у них в голове, и с учетом этого сделать мою работу - описать. я сначала, конечно, делаю рисерч, но этого никогда не хватает - все равно надо спрашивать про специфику. а мысли читать я все еще не умею, поэтому спокойно спрашиваю и игнорирую закатывание глаз. я, кстати, редко с такой реакцией встречаюсь, но все равно бывает, и к этому надо быть готовым.

Так что сейчас, когда я смотрю на джунов, которые лучше 2 дня будут разбираться сами, вместо того, чтобы спросить и за 10 минут получить развернутый ответ - скажу, что правильно делают.

Полностью соглашусь. Особенно для молодого специалиста важно и полезно разбираться во всём самому. Да, на ранних этапах это займёт больше времени, зато через пару недель он будет разбираться в проекте. Знания добытые лично куда прочнее, системнее и в целом полезнее, чем те, что достались на халяву

Описанные ситуации ведь не касаются разработчика.

1) На молчание в чате на неработающую кнопку должен отвечать pm проекта, потому что на нем сроки и приотиризация задач. Максимум, в случае если эта кнопка приносит миллионы долларов в секунду, должны дергаться причастные к неработе, да и то через свою иерархию, а не напрямую.

2) Боссу варианты предлагают уже не разработчики, а лиды, продуктологи, архитектурный комитет или кто там еще. Когда разработчик начинает это делать самолично, он чаще всего огребет проблем, т.к. его резко перекинут реализовывать выдвинутые им варианты без нормальной детализации, т.к. "ну ты сам лучше знаешь, ты же инициативный". Разработчику будет гораздо полезнее выдвигать предложения в его команде при груминге или детализации задач, нежели при общении с боссом.

В остальных пунктах диалоги идут непосредственно не с разработчиками, а с какими-то лидами,ВП, котами.

В статье ни одного полезного примера общения с разработчиками, но начинается она с упрека в их сторону. Удивительная профдеформация написавшего эту статью БОССА.

Констатация общей проблемы коммуникаций применительно к IT- сфере.

Хочется спросить и ЧТО? Есть предложения по решению?
PS Например, старап IT-Продукта, для повышения уровня коммуникаций (вроде средств формирования "рейтинга полезности" внутри группы разработчиков или шире команды, конторы, сообщества..?)

Есть такие специальные смешные ребята, работа которых -- бегать от разработчика к аналитику, от аналитика к заказчику, от заказчика к ПМу и от ПМа к разработчику, за всеми записывать, что они как поняли и что они как сделали, и лепить из этого хаоса тортик, который всем придется по вкусу.
Они называются специалистами по техническим коммуникациям, или, в простонародье -- техническими писателями.

Подход в стиле менеджера, считающего себя эффективным - коммуникации, договоренности, чатики какие-то. Я как разработчик вижу только то, что оформлено надлежащим образом в виде запросов на изменение в джире/тфсе или где-то еще, плачу Ярославны в чатике могу только посочувствовать. Далее, если запрос на изменение оформлен, не в моей компетенции обсуждать его целесообразность: сказано перекрасить кнопку - перекрашиваем.

Дергать коллегу с вопросом "как это работает" считаю допустимым только в самом крайнем случае, когда чтение кода и документации, отладка и гугление не помогли. Коллега - он тоже программист, а не нянька.

Я работал и так и так и на мой взгляд подход с нормальными коммуникациями позволяет добиваться лучших результатов быстрее да и саму работу делает интереснее. Возможно мне повезло с людьми с которыми я работаю, а возможно именно свободное общение позволило собрать отличную команду куда люди из других отделов стремятся попасть. Но да, естественно что эту идею как и наверное любую другую можно извратить и испортить сотней разных способов.

Безусловно, нормальные коммуникации могут повысить эффективность работы, но в случае разработчиков коммуникации - это опция. И касаться они должны, как мне кажется, обмена опытом и практиками, но никак не выяснения или постановки задачи.

По-хорошему есть запрос на изменение, ТЗ или еще какой-то документ, содержащий четкое описание того, что нужно сделать, и как должно получиться в итоге, и этой информации разработчику достаточно. Если этот документ не составили или составили левой ногой в надежде, что разработчики как-то сами разберутся, это значит, что кто-то не сделал свою работу и переложил ее на разработчика, который теперь должен (на самом деле нет) устраивать какие-то там коммуникации.

Если вашего менеджера устраивает такой подход, то почему нет. Я легко могу представить себе проект где в лучших иметь такого рода полное покрытие заданиями и инструкциями.

Я работал как с разработчиками которым нужно вот так все разжевывать и готовить, так и с теми кто может проявить через себя пропустить задачу и обсудить с кем-то что. В моем случае те кто может нормально общаться в команде ценились больше. Эта повышенная ценность для них выражалась в зарплате или в карьере. В целом мне кажется и по жизни люди которые понимают кого о чем можно спросить имеют больше возможностей.

Но это не значит кстати что человек не хочет или не умеет общаться "хуже" для менеджера. Для менеджера такой человек может быть даже очень ок (например тем кому нравится общение могут закиснуть на проекте где надо одному работать пару лет). Главное чтобы взаимные ожидания менеджера и разработчика были синхронизированы.

Я работал в разных компаниях. Там, где делали продукт, команды были небольшие и не западло было спросить коллег, и работа была в удовольствие, и отношения хорошие. Там где "смотрите документацию, я вам не нянька", плохие отношения в коллективе, куча ненужной работы, местами кафкианство.
В комментах тут какое-то торжество даже не интровертов, а аутистов, но вообще практически все компании стараются улучшить процессы коммуникации и всячески их наладить, а не запретить общение. Потому что понимают, что это влияет на выпуск продукции прямым образом.

Какой эффективный способ коммуникаций?

На такой вопрос надо отвечать уточняющим вопросом: каков критерий эффективности?
Если в качестве критерия мы возьмем вполне логичную вещь — удовлетворение своих материальных интересов — то критерии эффективности с точки зрения разных участников деятельности предприятия — владельца бизнеса, разработчика и разнообразных посредников типа владельцев продуктов, руководителей групп и прочих менеджеров — неизбежно окажутся окажутся совершенно разными. А общий критерий эффективности для этих разных людей — просто-напросто не существующим.
Причина тому простая: материальные интересы этих разных участников деятельности предприятия различаются очень сильно, вплоть до того, что часто можно говорить о непримиримом противоречии между ними. Так, владелец бизнеса заинтересован получить максимум прибыли, разработчик — получить оговоренный оклад наименьшими усилиями (ну, или максимум оклада при тех же усилиях), а все посредники находятся по своим интересам где-то в промежутке.
Поэтому «эффективные» коммуникации по факту оказываются не обменом информацией в рамках некоего «общего дела», а способом отстаивания своих специфических интересов.
И здесь минимизация коммуникаций со стороны разработчиков — у которых умение отстаивать свои интересы в рамках коммуникации обычно развито хуже, чем у других участников деятельности предприятия — является далеко не самой плохой их личной стратегией.
Все написанное выше написано не для того, чтобы побудить разработчиков саботировать работу предприятия, а исключительно с целью показать, что выстраивание коммуникаций эффективным для функционирования предприятия образом — это не задача разработчика, но задача менеджмента. Именно менеджмент должен установить те формальные правила, которым разработчик обязуется следовать, чтобы его деятельность считалась полезной (т.е. — подлежащей оплате), и которые при этом обеспечивают приемлемую эффективность взаимодействия между участниками процесса.
Но статья, что совершенно логично (ибо написана в интересах бизнеса, т.е. его владельца), пытается навязать разработчикам точку зрения владельца на эффективность коммуникаций бизнеса, которая разработчикам может быть совершенно чужда. Здесь мы имеем тот же случай, что и с обязанностями разработчика из предыдущей статьи: попытку сэкономить на процессе управления производством за счет разработчика.

сидеть три часа и пытаться самостоятельно разобраться, как работает соседний сервис, вместо того чтобы просто спросить у коллеги и получить ответ за 15 минут.

Классический пример "мы не можем организовать работу, поэтому будем писать стать и о том, как важна коммуникация".

Работаю с людьми, которые вырасли на таких статьях.

Неделю назад была такая ситуация:
Приходит пуш уведомление от программиста, который настраивает компонент написанный мной. И там вопрос "А как настроить ХХХ"?
Я открываю дискорд, а там сообщения нет. Ну, думаю, баг дискорда. Раписал ответ как настраивать.
На что программист пишет: "Да я уже в документации все посмотрел, там всё понятно, поэтому вопрос удалил."


Если в вашей компании надо что-то у кого-то спрашивать, значит у вас серьезные проблемы с организацией рабочего процесса. Написал я компонент и завтра уволился/ушел в отпуск/на больничный. Искать меня будете? Вместо того, чтобы организовать нормально работу?
15 лет в разработке, грамотная организация полностью заменяет общение.

"Все врут" :-)
Как человек постоянно работающий с легаси кодом, скажу, что не врет только код и отчасти тесты (если они не отключены).
Бумажная документация устаревает быстрее всего. Потом требования и ТЗ.
Чатики и разговоры, вообще никак "к делу не пришьешь".
В конце остаешься ты, код и отладчик. :-)

У меня был коллега, который сразу брал большую задачу, принципиально ничего ни с кем не обсуждал, выкатывал, а потом зачастую мы доделывали-допиливали-переделывали. Зато он чувствовал себя Самостоятельным, Ответственным и Активным

А статья на самом деле про уровень общей культуры людей. Просто разучились быть вежливыми, корректными. Люди предаются эскапизму, "меня ничего не касается". Здороваться элементарно разучились, входя в общее пространство.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий