Вы уволили самого талантливого сотрудника. Надеюсь, теперь вы довольны

https://medium.com/@deusexmachina667/you-fired-your-top-talent-i-hope-youre-happy-cf57c41183dd
  • Перевод
Недавно довелось прочитать статью под названием «Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо делали». [Очень популярная статья, которая получила массу положительных оценок на Medium — прим. пер.]

Давайте присядем, вы и я. Нужно поговорить. Если вы не читали статью по ссылке, то уделите 10–15 минут и прочитайте, впитайте её целиком.

Готовы? Отлично. Теперь разберём этот текст, потому что он значит гораздо больше, чем там написано. Если вы прочитали статью, то понимаете, что автор описывает проблемного сотрудника под вымышленным именем «Рик». Рик — это местный гений с огромным количеством знаний в предметной области, он входит в состав ключевых разработчиков продукта.

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


TL;DR — краткое содержание той статьи

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


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

Лично я считаю, что если нашли такого человека и проводите с ним собеседование, независимо от уровня его таланта, не стоит тратить на него время, по причине той потери морального духа и упадка командной работы, которые он принесёт в коллектив. Это именно то, о чём говорилось в статье — как Рик игнорировал планёрки и принижал своих коллег. И как производительность труда взлетела, когда Рика уволили — все вместе приложили усилия, чтобы спасти положение! Автор рассказывает всё это, чтобы вы возненавидели Рика и сказали: «Да! Долой этого парня! Похоже, руководство наконец-то отрастило яйца и послало эту рок-звезду подальше! Я бы работал с такими ребятами!»


Посмотрите на мою историю! Я буду использовать имена персонажей поп-культуры, мемы и всякое дерьмо, чтобы зацепить аудиторию! Уиии!

Но если вы внимательно прочитаете статью, то обратите внимание на несколько проблемных мест по ходу дела:

«Каждый раз, когда у кого-то были вопросы по коду или нужна была помощь с решением проблемы, они шли к Рику. У Рика в кабинете висела огромная белая доска специально для одной этой цели, всегда испещрённая не до конца стёртыми остатками старых дискуссий.

Каждый раз, когда возникала особенно сложная проблема, ею занимался Рик».

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

Где документация?

Где совещания для обсуждения этих проблем и способов их решения?

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

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


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

«Вскоре Рик прекратил посещать планёрки. У него на них не было времени, потому что приходилось писать слишком много кода.

Рик закрыл свою дверь. К доске больше никто не подходил. У Рика больше не было времени кого-то обучать, потому ему самому пришлось решать слишком много проблем».

Где был менеджмент во время всего этого? Где показатели/метрики? В самом деле, что я выяснил за всё время работы в IT и информационной безопасности — что начальству нужны показатели.

Никого не волновало, что Рик пропускает планёрки?

Никто не замерял открытые/закрытые тикеты?

Никто не документировал проблемы и их решения?

Никто не замечал, что Рик загоняется, набирая всё больше и больше работы?

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


Чего не сделал никто из руководителей компании Рика — так это не задался вопросом, что же, чёрт возьми, происходит.

«На панели мониторинга проекта зелёные флаги сменились жёлтыми. Жёлтые сменились красными. Красные огоньки начали мигать. Один за другим статусы задач менялись на „Затруднённый”. Все ждали Рика».
«Рик штамповал код быстрее, чем когда-либо. Он работал семь дней в неделю, 12 часов в день».

Итак, Рик взял гораздо бóльшую нагрузку, чем мог осилить, а вдобавок к этому работал по графику 12x7.

Никто ничего не сказал, когда заметил, что Рик остаётся в офисе или удалённо подключается в нерабочее время и в выходные дни?

Менеджмент не вступился и не потребовал, чтобы Рик отступил и начал документировать свои действия?

Никто из начальников или менеджеров не проверял загрузку Рика тикетами и не решил, что её нужно распределить среди других сотрудников?

И кроме всего прочего, руководство позволило этой фигне продолжаться целых два года?

В каких облаках витал менеджмент?

Где были тимлиды?


В таких ситуация всегда хочется спросить, где было руководство. Но если это стартап дурацкой Силиконистой долины [в оригинале Silly Valley — прим. пер.], то они наверняка пыхтели с пакетиками Juicero, или что-нибудь такое.

«Мы сели и поговорили с Риком о его роли в компании…»
«Как он отреагировал?

Единственным возможным способом: Рик взорвался.

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

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

Впрочем, вы справляетесь.

Вы держите ситуацию под контролем. Вы можете потом вернуться и исправить эти хаки. Вы можете убрать эти заплатки, импровизационные патчи — и заменить их крепким качественным кодом, которым действительно будете гордиться. Ведь уже некоторые части кода, которые вы когда-то написали, становятся непонятными для вас самого. Мы потом вернёмся, дизассемблируем его и правильно задокументируем. Всё, что нужно сейчас — выдать продукт в RTM/GA, а потом к нему можно вернуться и как следует переработать. Я им нужен. Моя работа важна. Я должен её закончить. У меня нет права на ошибку. У нас заканчивается финансирование. Я не могу потерять эту работу. Жизнь в $BigCity для меня слишком дорога, чтобы допустить неудачу на работе.

Что если не получится?

Как я смогу подняться?

Смогу ли я?

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


Надпись на иллюстрации: «Страж смотрит на вас озабоченным, вызывающим беспокойство взглядом, как тот мужчина, который должен объяснить своей парализованной дочке, что её мечта стать балериной никогда не осуществится».

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

Сколько дней и недель он работал в 12-часовые смены?

Сколько он пропустил семейных ужинов, дней рождения, выходных и так далее?

Есть ли у него семья?

Есть ли друзья за пределами работы?

Возлюбленная?

Дети?

Культура стартапов не предполагает задавать такие вопросы, потому что культура стартапов (и большинство IT-культуры в этом отношении) не предусматривает беспокоиться о вашем благополучии. Только о результатах вашей работы и об ограничении своей ответственности в случае, если вас придётся уволить.

Меня раньше увольняли в ситуациях, которые я считаю не совсем справедливыми. И хотя вырваться из окружения, которому не нравится ваша работа и/или где люди делают не то, что вы считаете правильным — это прекрасное чувство, но есть ещё и не столь приятное ощущение несоответствия требованиям и ужасное клеймо — необходимость объяснять на собеседованиях, почему вы ушли с прежнего места работы на таких невыгодных условиях.

Чувство свободы начинает потихоньку исчезать по мере сокращения остатка на вашем сберегательном счету (учитывая, что автор и его компания находятся в Калифорнии, где стоимость жизни абсурдно высока, остатки на счету сокращаются гораздо быстрее, чем хотелось бы) и быстро превращается в страх, в то время как вас начинают преследовать те вопросы, которые возникали во время работы в компании:

Сможете ли вы своевременно найти работу?

Это те самые события, которые вас сломают?

Почему они вас уволили, если вы дали им всё?

Почему никто не боролся, чтобы вас сохранить?

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

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

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

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

И это вместо статьи о том, как они предотвратили падение сотрудника в необратимое выгорание с помощью своевременного вмешательства, выдающейся командной работы и компетентного менеджмента — того, что сотрудники IT, специалисты по инфобезу и разработчики ДЕЙСТВИТЕЛЬНО хотели бы услышать, они решили сконцентрироваться на токсичном окружении и проблемах, которые как будто проистекают от Рика. Вместо поиска первопричины (эй, мужик, что тебя беспокоит?), они выбрали быстрый и простой метод (эй, Рик, проваливай нахрен отсюда!). Обычное дело, насколько я могу судить.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 430
  • +45
    Было подобное в молодости — когда я поддерживал 3 магазина и работал по 12 дней кряду чтобы у продавцов были нормальные выходные, иначе они бы сбежали из конторы. Делал все, даже то, что не обязан, надрывался, предлагал методы оптимизации. И никакого выхлопа.
    А потом они удивились что я ушел

    Сейчас я все еще готов предлагать себя за те деньги, что мне платят, но:
    — все теперь документировано
    — просто так я не перерабатываю
    — работаю в том темпе, который удобен мне. И пока все задачи решаются руководство это устраивает

    И к людям нельзя так относиться, а потом еще писать восторженные статьи.
    • +2
      Полностью согласен! Когда я был «молод и горяч», в порывах энтузиазма очень сильно перерабатывал. Так и от поведение «Рика» веет молодостью. В последние же лет 5-6 я очень ценю свое время, поэтому предпочитаю обучить и разъяснить коллегам всё как можно более детально, т.к. мне же самому от этого становится намного легче и интереснее работать: снижаем кол-во вопросов по пустякам, разделяем простую работу на большее кол-во сотрудников. Да даже элементарно интереснее общаться с коллегами, когда делишься опытом и они близки к тебе по уровню знаний
      • +1
        Большинство работодателей вообще терпеть не могут инициативных и креативных людей, особенно когда они хотят хоть немного изменить привычный строй… Они жаждут лишь того, чтобы ты работал побольше и требовал поменьше)))
        • +1
          %20 Сорри, не понимаю как удалить случайный коммент )))
          • +1
            Да ну, глупости. Если работодатель действительно преуспел в бизнесе, он уже немножко понимает людей. Просто тут палка о двух концах. Очень много балванов чувствуют себя инициативными и креативными. И хотят изменить привычный строй. Ну и смело идут лесом. Разумеется, недопонятые работодателем. :)

            PS: Да, есть неумные работодатели, но это отдельный вопрос как оне такими стали.
            • +1
              Если работодатель действительно преуспел в бизнесе, он уже немножко понимает людей.
              Или решает, что всё, что он делал, было правильно («ошибка выжившего»)?
            • 0
              Они жаждут лишь того, чтобы ты работал побольше и требовал поменьше)))


              Нифига!
              Многие из ещё требуют, что-бы задание — делалось строго так, как они хотят, и ни шага в сторону!!!
              • 0
                Многие из ещё требуют, что-бы задание — делалось строго так, как они хотят, и ни шага в сторону!!!
                Если бы они этого хотели — жизнь была бы сказкой.

                В большинстве случаев заказчики сами не знают чего хотят — и это нормально. Ненормально — пытаться удовлетворять все их «хотелки» и надеяться, что за это вас «погладят по головке».
                • 0
                  Ну, речь не про заказчиков (уточнение их хотелок тоже входит в «работу») — а про руководство.
                  Которое не только (а иногда и не столько) требует исполнения чего-то — но и хочет исполнения этого вполне определённым образом.
                  «Не смей делать этого вот так! Не смей ничего трогать! Только так, как я сказал!!!»
                  «Никакого С++! Только глобальные переменные и читстый Си! И никаких enum'ов, struct'ов и прочих заморочек!!!»
            • +6
              Но ведь это совершенно другая история! Если Вы читали оригинальную статью, то поняли что ситуация там совершенно не совпадает с Вашей: над продуктом работала команда менее или более одаренных людей. Более того, руководство было готово добавлять ресурсов (автора статьи подключили с другого проекта).
              Но в команде завелся супер-герой, который решил сам спасти мир до конца не видя картины и не имея достаточно опыта в доведении продукта до продакшна (делегирование — нет не слышал).
              Естественно единственный способ — это дать возможность команде начать работать, и попрощаться с суперзвездой.
              • +1
                Естественно единственный способ — это дать возможность команде начать работать, и попрощаться с суперзвездой.

                Самый взаимовыгодный вариант — это перевести «суперзвезду» на другой проект, где первое время он будет пилить MVP водиночку. А потом этот новый проект, в зависимости от успеха MVP, либо передадут команде разработчиков, либо закроют.
                Конечно, передавать проект «суперзвезды» команде нужно намного раньше, чем зашевелились менеджеры Рика.
              • 0
                Все правильно.
                Именно поэтому стартапы обычно ищут на работу молодых, которые еще не приняли Вашу точку зрения и готовы вкалывать в том темпе, который нужен руководству.
                Опытному, зрелому специалисту, нужна такая же опытная компания…
              • +8
                Отличная статья, спасибо!
                По мне, внушать что-то компаниям бесполезно, любой сотрудник = ресурс. Поэтому предупреждающего поведения для таких ситуаций предложу 2 варианта:
                1. Воспринимать работу как подобает работнику продажу своих навыков в течение N часов за M времени, что как можно детальнее указать в договоре и должностных инструкциях. Соответственно не замыкать разработку на себе (это трудно для чуваков, которые получают фан от исключительности знаний и опыта).
                2. Тянуть компанию, но периодически честно и хладнокровно (но без сарказма и вызова) напоминать об этом менеджменту. Повторюсь, не эмоционально, а фактами — обученные люди, закрытые сложные ЧУЖИЕ таски, решения в критические моменты.
                • +3
                  * N часов за M денег, пардон ))
                  • +3
                    М — мало. Нужно Б(ольше) денег. )))
                  • +7
                    это трудно для чуваков, которые получают фан от исключительности знаний и опыта
                    — вот это прям точно подмечено :(
                    • +7
                      По мне, внушать что-то компаниям бесполезно, любой сотрудник = ресурс.

                      А в чем проблема? Да, сотрудник — это ресурс. Но это означает, что не стоит о нем заботится? Наоборот, как раз стоит.

                      • +1
                        Я-то с вами согласен, но сколько компаний в процентном соотношении придерживаются такой же логики?
                        • +2
                          В конце дня все приходят к балансу. Те, кто не выделял ресурсов для заботы о своем ресурсе, потеряли этот ресурс. А те, кто выделял — приобрели потерянный конкурентом за трудовые ресурсы. Все в порядке, все по закону.
                        • +1
                          Бытует мнение, что достаточно платить ресурсу зарплату, а заботится пусть сам.
                          • 0
                            Причем зачастую это мнение самих «ресурсов».
                      • +4
                        Командная работа (:
                        • +7
                          всей командой его выперли
                        • +18
                          В оригинальной статье как-то вскользь, но отмечено, что команду управленцев уволили первыми.
                          His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.
                          Ну а то, что акцент в статье сделан на личности Гения, а не на управленческих просчетах, можно списать не на предвзятость автора, а на то, что это было первопричиной проблем. Возможно, Гений был основателем стартапа, но не смог доверить развивать свое детище другим разработчикам
                          • +6
                            И еще мне кажется, это часть большой истории о том, как в перспективный стартап пришли венчурные инвесторы, жаждущие тысяч процентов роста, а основатели и управленцы не были готовы к взрывному росту. Набрали кучу разработчков, но основатель сопротивлялся, а менеджмент с ним не справился. В результате недовольные инвесторы сменили менеджмент и дали новой команде возможность приступить к полному переписыванию всего проекта с нуля.
                            «Капитализм!» (с) к/ф Красная Жара
                          • +2
                            Та 90% фирм так делает! «Соковыжималки» правило для ІТ. Во первых. Во вторых, посидите полгодика без бабла и перспектив, и будете сами стремится к варианту работы именно Рика. Тактика «стать незаменимым» очень соблазнительна для человека, который полгода-год посидел без работы.
                            • +11
                              Стратегия за этой тактикой дерьмовая.
                              • 0

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

                                • 0
                                  Бизнес хочет, чтобы любого человека можно было просто заменить. Работник же хочет, чтобы его было невозможно заменить.

                                  И у тех и и других есть к этому мотив, и совершенно логично что оба будут стремиться именно к этому.
                              • 0
                                Не надо говорить за всех. Я тоже как-то полгода сидел без работы, но эту дебильную тактику применять не собираюсь. всё равно это произойдёт само.
                                • +3
                                  А я на работе и не скрываю, что хочу стать незаменимым. И знаете, очень легко получается! Сейчас я незаменимый в ведении документации и выкладывания исходников. И на моей работе нет ни одного сотрудника, у кого есть столько документации и репозиториев.
                                  • 0
                                    Неужели бывают настоящие специалисты, которые полгода не могут найти работу? Стоит задуматься, а специалист ли…
                                    • 0
                                      Бывают, если за свою работу хотят существенно выше рыночной цены. Хотя тут наверное не «не могут», а «ищут».
                                      Второй вариант — очень узкая специализация в небольшом городке…
                                  • 0
                                    Любого незаменимого рано или поздно выкинут (в крайнем случае, из-за разорения или перепокупки фирмы, неспособной наладить нормальное управление). Чем незаменимее, тем позднее. Чем позднее, тем труднее потом ему будет искать новую работу и адаптироваться к ней (технологии уйдут вперёд, а он останется незаменим в старых, плюс навыки нормальной командной работы не выработаются). Так что незаменимость — это палка о двух концах, и эффективна только в краткосрочном плане.
                                  • 0
                                    Хорошая статья! В точку проблем не только IT компаний!
                                    • +21

                                      Компания находит сотрудника, которому очень нравится его работа и он в ней преуспевает. Постепенно повышает нагрузку добавляя новые задачи. Он всё ещё справляется, ведь ему нравится его работа и он вкладывает в неё душу, так продолжается довольно долго. В какой-то момент времени при добавлении ещё большего количества задач работник уже не справляется, а компания думает, от чего же так случилось, ведь раньше повышение нагрузки не приводило к проблемам. И решает, что проблема в работнике, и надо с ним разобраться. Но лучше конечно, когда работник сам об этом догадается и вовремя примет решение уйти, не вырабатывая ресурсы своего организма в ноль.

                                      • +16
                                        В какой-то момент менеджментом был потерян контроль над ситуацией. Стратегия управления разработкой свелась к старому доброму «авось». Ведущий разработчик без внешнего контроля и отсутствия времени на банальный рефакторинг под грузом задач в итоге родил мертворожденную химеру, которую, как оказалось проще пристрелить, чем перестраивать.
                                        Я увидел именно такую историю. Причём не только в статье, но и в реальной жизни.
                                        • +6
                                          Заставляет вспомнить все эти:
                                          Если ты хочешь прибавку к ЗП, приди к начальнику и скажи «что я должен ещё сделать для того, чтобы получить прибавку?»
                                          • +5

                                            Иногда можно спросить "что я ещё должен сломать, чтобы получить прибавку?"

                                            • 0
                                              Но не в лоб и не у начальства.
                                          • +2
                                            Вот только тут встаёт новая проблема. Один человек решал кучу вопросов — основные обязанности и много дополнительных, потому что большая часть из них была настолько отлажена, что не требовало от него значительных усилий.
                                            Но человек увольняется (или его увольняют) и на его место берут другого, от которого ждут выполнения не только его основных обязанностей, но и дополнительных. А он и в основные еще какое то время будет вникать.
                                            Вот и получается, что с человеком расстаются, а потом руководств говорит, что человек зажрался и ничего не успевал, а простой народ говорит, как при нем всё было хорошо — он всё успевал и всё знал.
                                            • 0
                                              Уйти единственный вариант для работника? Думаю, сначала стоит попытаться донести руководству идею, что ты крут, но не всемогущ.
                                            • +6
                                              Ага, при прочтении оригинальной статьи возникали похожие мысли. Единственное я бы не стал так уверенно перекладывать всю вину на руководство. В первую очередь, на мой взгляд, виноват Рик — это его здоровье и его карьера, раз он наплевательски относится к себе, почему посторонние люди должны переживать? Вообще сам на первой работе аналогично выгорал, потом получил граблями по лбу и понял, что сам виноват — нужно уметь рассчитывать силы.
                                              • +1

                                                Убейте меня — но я не вижу вины Рика — он получил возможность реализовать себя и делал это на пределе сил и возможностей. У меня у самого лучший код был написан в 4 утра ( и я даже не заметил как рассвет наступил).
                                                И не стоит думать что это был "хитрый план Рика по завладению компанией" — отнюдь, просто другие сливались где он продолжал работать, и пока брали других, они въезжали в курс дела — Рик продолжал выдавать результат на гора, и постепенно количество переросло в качество — Диалектика, ее законы никто не отменял !

                                                • +3
                                                  Так не переросло количество в качество — все обросло костылями и загнулось, потому что он взял на себя слишком много и не вытянул. Лучший код и качественный законченый продукт — разные вещи. Причем реальные деньги, радость, почет и профессиональный рост приносит второе. Когда-то давно меня тоже глубоко возмутило высказывание Макконела типа «Если пишите код по ночам — будьте готовы потратить следующую неделю на его исправление, а то и просто выбросить», сейчас я все еще верю в важность вспышек энтузиазма, но возмущен гораздо меньше)
                                                  • +11

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

                                                    • +1
                                                      У проблемы много корней, и один из главных — Рик позволял годами себя меньше кормить и больше доить. Вообще не факт, что с коровой бы такое прокатывало так долго. Глупые менеджеры — не повод вести себя глупо самому.
                                                      • 0
                                                        Согласен — это основа.
                                                        Равносильно запросам кучи совершенно постороннего народа — тыжпрограммист, сделай!!!
                                                        • 0
                                                          Отнюдь.
                                                          Зарплата Рика тут вообще не при делах.

                                                          Ведь его именно что выгнали, а не он сам ушел — как это было бы если бы его «доили но не платили».

                                                        • 0
                                                          Какой нехороший Рик, расхолаживал начальство.
                                                        • –1

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


                                                          я не лично кому-то, просто в голове мысль родилась

                                                          • –1
                                                            сами подумали что написали? :-)
                                                            • +1
                                                              Если вы пишете хороший код только короткие промежутки времени (при озарениях), значит в остальное время программируете вы не очень хорошо

                                                              по-моему, все вполне разумно

                                                          • 0

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


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


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

                                                      • +3

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

                                                        • +3
                                                          Это конечно так, но в коллективе всегда находится трудоголик, фан, он всегда задерживается, всегда во внеурочное время решает какие-то важные задачи. Руководство начинает ориентироваться на него, постепенно и сотрудники считают невозможным халявить по сравнению с передовиком. И так по спирали.
                                                        • +2

                                                          Вина есть однозначно! Человек не хочет делегировать задачи другим, под предлогом что они не сделают её так хорошо как он. Неужели в проекте все задачи были мегасложными? Нет, но способ работы через костыли делал делегирование почти невозможным. Плюс самомнение, что если не сделаю всё сам, то будет плохой код. К тому же насколько я понял, изначально Рику предложили продолжить работать в команде по созданию проекта с нуля — но по правилам, но его вариант быть не звездой, а винтиком — не устроил и он взорвался. Однозначно проблема в Рике и менеджерах которые допустили развитие такого сценария.

                                                          • +5

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

                                                            • 0
                                                              Плохо то, что Рику не предложили компенсировать его переработки и самоотдачи, более того, даже не заметили их.
                                                              • 0

                                                                Почему Вы решили, что не заметили? Из комментариев к оригинальной статье, похоже, что не только заметили, но и пытались охладить пыл Рика, отправить его в отпуск отдохнуть. Он не соглашался.

                                                          • +1
                                                            Что ж вы вечно виноватых то ищите?

                                                            У Рика и фирмы — разные интересы.

                                                            У Рика — реализовать идею, добиться чтобы работала невероятно сложная альфа-версия.

                                                            У фирмы — получить и альфу и бету и релиз. И релиз — да, да.

                                                            У меня есть подобный знакомый — мешает в коде 100500 библиотек и парадигм. Оно работает, он удовлетворен, но поддерживать это говно не реально. Сам он уже не хочет, не интересно. Ну а другим проще с нуля переделать
                                                            • 0
                                                              Когда есть что с нуля переделывать — делать в разы проще, чем когда этого нет.
                                                              • 0
                                                                В нашем конкретном случае единственным облегчающим работу было то, что заказчик уже заплатил деньги за решенную хоть как то проблему.

                                                                С технической же точки зрения — ничуть не проще было.
                                                              • 0
                                                                Мне кажется что сейчас такое быстрое развитие технологий что как не старайся, все равно рано или поздно придется переписывать с нуля.
                                                                • 0
                                                                  Когда нибудь через года 4 — это рационально.

                                                                  Но практически сразу, как наш «Рик» закончил проект и потерял к нему интерес, через 3-4 месяца — это перебор.

                                                                  И, кстати, развитие технологий тут не при чем.

                                                                  Вы что же предлагаете переписывать вообще весь софт с нуля при выходе очередного фреймворка или очередного языка? Начав с Биос и Ос? Накуа?

                                                                  Имеет значение не технология — а только одно: интересы бизнеса.

                                                                  Бизнесу совсем не нужно переписывать с нуля если система работает и приносит деньги.

                                                                  А программисты слишком много хотят бабла, что бизнесу было выгодно переписывать с нуля слишком часто.
                                                                  • 0
                                                                    Приходится переписывать потому что старые системы перестают поддерживаться и разработка для них становится дорогой.
                                                                    Вы что же предлагаете переписывать вообще весь софт с нуля при выходе очередного фреймворка или очередного языка?

                                                                    Пользователи magento 1 так и должны сделать, например.
                                                                    November 18, 2018 was marked as “End of Life” of Magento 1

                                                                    Так что да, 4-5 лет и выходит.
                                                            • +7
                                                              Нормальный менеджмент должны переживать о своих ресурсах. Должен, по крайне мере, просить сотрудников соблюдать баланс между работой и обычной жизнью. А если руководство видит, что человек загоняется — даже принудительно выгонять его на отдых(это, кстати, дополнительная проверка, что компания сможет существовать, в случае если с ведущим специалистом что-то случится).

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

                                                              Проблема возникает тогда, когда в менеджмент IT персонала приходят люди которые совершенно далекие от IT. У них мысли так — «ну чего — они там за своими маками сидят и расслабленно по клавиатуре стучат. Что там сложного?» Я наблюдал ситуацию, когда человек до 3х ночи занимался (с требования руководства) срочным запросом клиента(который до утра не ждал), а когда на следующий пришел в 12 часов дня, его спросили, почему он не пришел к 10 как обычно. При этом в другом случае, когда в руководстве были людей с практическим опытом в IT, сотрудник в аналогичной ситуации получал минимум полдня отгула.

                                                              • 0
                                                                Поэтому менеджером в ИТ может быть только тот кто на своей шкуре это все прошел. А назначенный сбоку управленец развалит команду и не сможет управлять.
                                                                • 0

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

                                                                  • 0
                                                                    Вот не надо ставить над проектом тех кто сам на своей шкуре не пробовал. Я в такой помойке работал, там нежный мальчик в костюме довел 80% людей до тупо бегства в другие компании.
                                                                • +1
                                                                  Да что значит полдня отгула если чувак до 3 ночи кодил?! Это ж де факто 2 смены. Даже сторож имеет сутки через трое без умственной нагрузки, лежа на диване.
                                                                  • 0
                                                                    Если бы в ИТ все соблюдали трудовое законодательство то разработчики работали бы дня три в неделю. Как кстати один чувак в Гугле и делает — три дня работает остальное время путешествует.
                                                                • +5
                                                                  Там все виноваты, но Рик может отвечать только за себя. Этот процесс был не случаен, и, наверняка, под давлением руководства. Да, какой-нибудь супергерой смог бы разрулить ситуацию как офигенный менеджер, но этого нельзя требовать от Рика, он на это не подписывался, и, строго говоря, не имел достаточного умения и влияния.
                                                                  • +1
                                                                    Очень часто хорошие и ответственные специалисты не могут себя защитить в этом плане. Впахивают пока не сломаются.
                                                                • +6
                                                                  Полностью согласен с выводами автора статьи.
                                                                  На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
                                                                  Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
                                                                  Что мешали им раньше увеличить расходы и разгрузить чувака?
                                                                  Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
                                                                  • +8
                                                                    Но подождите, ведь в первую очередь менеджмент виноват в том, что не было код-ревью и документации. А может и Рик изначально не хотел давать свой код на ревью, считал это унизительным. Многое осталось за кадром…
                                                                    • –4
                                                                      По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.
                                                                      Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
                                                                      Тогда выское дерево будет непременно срублено. Так и получилось.
                                                                      • +22

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

                                                                        • –4
                                                                          Или над уровнем джуниоров :-).
                                                                          Если бы я решал, кого присылает наш HR отдел нам в работнички…
                                                                          На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
                                                                          • +2

                                                                            С таким отношением слона не продашь) Надо искать сильные стороны в людях и давать им соответствующую работу. Кто-то любит сложные задачи, а кого-то не напрягает в режиме 8/5 рисовать DAO. Или писать документацию. Или тесты. Или скрипты для деплоймента.

                                                                            • +5
                                                                              иногда проще «в морг» — на всех отдельных задач не напасешься… Ну или будешь потом как вон тот Рик — закрывать то, что присланные люди должны делать, но в силу своих «слабых сторон» не могут.
                                                                              • +2
                                                                                Мой опыт говорит о другом. Когда есть деньги — можно собрать команду звезд по всему миру и выдать на гора за пол года, что до этого не могли запустить за 5 лет потратив астрономические суммы.
                                                                                То, что вы описывается годится для рутины в каком нибудь отделении банка где последние 20 лет правят какой нибудь их внутренний опердень и звезд с неба не хватают.
                                                                            • +3
                                                                              Конечно, но тогда это уже не код ревью — если джун смотрит код и учится. Код ревью — оно же вроде для того что б проверить качество кода, выявить недостатки и убрать их?

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

                                                                              Как по мне — пусть код смотрят в команде все кто хотят и обсуждают как хотят, это хорошо — кто-то чему-то научится, кто-то даст качественный отклик и ты сам научишься. Но ревью должен делать кто-то по уровню сопоставимый с тем, кто код писал. Потому что если человек будет заметно слабее, он некоторых моментов может не понять и общее отношение будет «как-то все мудрено и можно сделать проще», но пройдет несколько лет и человек сам будет писать так же — потому что так будет эффективнее и качественнее.
                                                                              • 0
                                                                                Хорошо написаный код должен быть доступен даже джуниору. Если замудрено, повод переписать проще и лучше покрыть тестами, которые смогут пояснить все аспекты и обоснованность сложности.
                                                                                • 0
                                                                                  Быть доступным и оценивать качество — это несколько разные вещи. Я согласен, что код должен быть доступен джуну, но не согласен, что джун сможет оценить качество.
                                                                                  • 0
                                                                                    Хорошо написаный код должен быть доступен даже джуниору

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

                                                                                      Если, скажем, джун не знает какую-то фичу языка, ей теперь не пользоваться, что ли?


                                                                                      Вот, я уверен, куча людей не знает, что в python есть оператор для перемножения матриц. Можно ли его использовать?

                                                                                      • 0
                                                                                        Хорошо сказано «покрыть тестами». Особенно если на задачу отведено 4 часа, и пожелание «и ещё чтоб было покрыто тестами всплывает в самом конце.»
                                                                                      • +1
                                                                                        Потому что если человек будет заметно слабее, он некоторых моментов может не понять и общее отношение будет «как-то все мудрено и можно сделать проще», но пройдет несколько лет и человек сам будет писать так же — потому что так будет эффективнее и качественнее.

                                                                                        По моему опыту, как раз наоборот — чем опытнее программист, тем проще его код.
                                                                                    • +16
                                                                                      По моему личному опыту меня напрягает, когда кого-то напрягает отдавать свой код на ревью.
                                                                                      • +2
                                                                                        Да какие проблемы — код во всеобщем доступе, история коммитов и комментарии тоже. Мердж происходит только после ревью. Вы так говорите, будто кто-то не хочет вам показывать свой код… Вопрос на самом деле, как происходит мердж. И зависит ли он от подтверждения от ревьювера — джуниора. Вот это напрягает — необходимость разжевать и объяснять банальности, иногда и просто тратить время на спор с дебилом, просто чтобы твой код ушел в девелоп. Никакой отдачи мне лично такой процесс не дает. Начальство время и нервы потраченные на такие объяснения не оценит — наоборот, задержка твоего коммита на ревью идет тебе в минус. Вообщем, одна головная боль.
                                                                                        Я поддерживаю вариант, когда ревьювит человек с опытом и в теме. И он же подтверждает мердж. Тогда все уходит в 90% без сучка без задоринки, а если возникают вопросы — то по делу и действительно можно чему-то научиться самому.
                                                                                      • +1
                                                                                        На самом деле в случае, когда ревьювер ниже уровнем — это скорее полезно для него. Это еще один способ учиться.
                                                                                        • 0
                                                                                          Зависит от того, как сам ревьюер относится к процессу. Если он спрашивает почему написано
                                                                                            SelectorInfo* x = new SelectorInfo[size]();
                                                                                          

                                                                                          а не
                                                                                            SelectorInfo* x = new SelectorInfo[size];
                                                                                          

                                                                                          то это нормально.

                                                                                          Ненормально — когда он после этого начинает требовать добавлять в код комментарии и пояснения.
                                                                                          • –1
                                                                                            За код в обоих случаях надо пнуть даже джуниора, не то что сеньора, он должен быть уволен сразу
                                                                                            • –1
                                                                                              А почему, кстати?
                                                                                              • 0
                                                                                                Value initialization vs default initialization.

                                                                                                P.S. А FoxCanFly, скорее всего, имеет в виду, что использовать «голый» new сегодня — не комильфо. Нужно использовать всякие unique_ptr и фабрики аллокаторов. Что, в принципе, верно. Но тут есть ньюанс: C++ — это не Java, тут всякие варианты возможны. В конце-концов у вас может FFI подобного требовать… Однако же инициализацию из-за этого опускать не стоит…
                                                                                          • +17
                                                                                            По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.

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

                                                                                            • +1
                                                                                              Так в том то и дело, что это не ревью. В том то и дело, что опечатку то может такое процесс и найдет, а вот реальную проблему пропустит. Просто по незнанию.
                                                                                              Получается, ни ревью полноценного, ни обучения, на которое требуется время.
                                                                                              Или вы путаете ревью с изучением кода?
                                                                                              • 0

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

                                                                                                • +1
                                                                                                  Ну, если каждый коммит ревьювит вся комманда (почему один джуниор, пусть уж все джуниоры учатся) — это замечательно. Но как-то малореалистично. Хотя, в банке может быть и не такое. А когда времени в обрез и все заняты своим, то реально ревьювить может один. Остальные максимум тихо учиться ну и как тут сказали указывать на синтаксические ошибки.
                                                                                                  • 0

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


                                                                                                    А когда времени в обрез то в следующем порядке забивается на:


                                                                                                    1. Юнит тесты
                                                                                                    2. Ревью
                                                                                                    3. Дизайн
                                                                                                    4. Составление требований
                                                                                                    5. Тестирование в общем

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

                                                                                                    • +3
                                                                                                      Теоретически все замечательно. А практически выглядит так, что тебя начинают нещадно эксплуатировать. Ты не только разработчик но еще и параллельно должен обучать. К чему это приводит на практике? А к тому, что я может потратил пол часа на таск плюс еще столько же на бодания и объяснение недалекому ревьюверу. В результате он все в конце концов понял и радостный пошел домой, а я должен оставаться овертайм чтобы доделать то, что должен был бы делать в то время, которое потрачено на выяснения — объяснения — обучение. Начальство хочет началось обучать джуниора — пожалуйста. Давайте учитывать как-то по-другому это дополнительное время, а не пытаться схитрить типа и типа сэкономить. Вот потому я Рика очень понимаю. Откуда у него взялась эта доска и откуда дикие переработки.
                                                                                                      У владельцев компании задача вырастить из джуниоров специалистов — так за это надо дополнительно платить. У меня задача сделать в срок и качественно свои таски (за что мне платят деньги) и пойти домой вовремя.
                                                                                                      • +2

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

                                                                                                        • +1
                                                                                                          Так время на ревью отличается принципиально, когда его делает подготовленный человек и недостаточно квалифицированный, которому надо разжевывать, объяснять и доказывать.
                                                                                                          Это уже не ревью. Это — обучение. А его пытаются втиснуть в ревью и таким образом не доплачивать. Одна из многих уловок хитрого менеджмента по высасыванию соков из людей. Нафик-нафик. Забивайте отдельно время на обучение и отдельно на ревью. Это будет честно.
                                                                                                          • +1
                                                                                                            Так время на ревью отличается принципиально

                                                                                                            Так время на ревью разве не вы закладываете? Аджайл как бы и сделан для этого. Ну ошиблись в одном спринте, ну теперь знаете что у вас в команде не все такие опытные, заложите на ревью в три раза больше времени. Либо поднимите на ретро вопрос о том, что отсутсвие аппрува от джуна не должно блокировать мердж.
                                                                                                            • 0
                                                                                                              Так время на ревью отличается принципиально, когда его делает подготовленный человек и недостаточно квалифицированный, которому надо разжевывать, объяснять и доказывать.

                                                                                                              Представьте, что ваш код через десять лет будет дебажить кто-то, кто с вами даже не знаком, а вы уже давно в другой компании.
                                                                                                              Код, который будет непонятен «человеку с улицы» без получаса разжёвывания, объяснения и доказывания тем, кого больше нет — это жёсткая подлянка для компании. Совершенно нормально, если тимлид запретит мержить такой код.
                                                                                                          • +4
                                                                                                            сделать в срок и качественно свои таски (за что мне платят деньги)

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


                                                                                                            Обязанность простого программиста — добросовестно 8 часов в день делать то, что ему скажет лид
                                                                                                            Обязанность лида — добросовестно 8 часов в день исполнять свои обязанности и коммуницировать результаты и проблемы наверх.


                                                                                                            Если вам не оплачивают переработки под любым предлогом (ты сам виноват, компании надо) — меняйте работу
                                                                                                            Если оплачиваемые переработки случаются регулярно — нужно ставить вопрос о качестве менеджмента или менять работу


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

                                                                                                            • 0
                                                                                                              Ну, вам платят за время, а мне — за решение проблем. У всех контракты разные. В моем например обучение обычно не присутствует.
                                                                                                              • 0
                                                                                                                В целом это конечно зависит от культуры компании, где то платят за результат, где то за время добросовестного нахождения на рабочем месте.
                                                                                                                • 0

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

                                                                                                      • +1

                                                                                                        Вполне себе ревью. Я не даром третий пункт написал. Джун непонятное должен спрашивать. А ты пока объясняешь сам себя и перепроверишь. Т.е. этакий IoC только для мозгов разработчика, а не среды выполнения.
                                                                                                        Нет, если после этого ещё опытный товарищ посмотреть — будет только лучше, но и считать это бесполезной времязатратой — глупость полная.

                                                                                                    • +6
                                                                                                      Почему это должно напрягать? В нормальной команде даже джуны ревьюят пулреквесты тимлида. Во первых они таким образом учатся. Во вторых, это как раз таки избавляет от суперзвезд в команде.
                                                                                                      • +1
                                                                                                        Потому что я вижу для себя в этом только головную боль и трату времени безо всякой благодарности.
                                                                                                        Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
                                                                                                        Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
                                                                                                        • –3

                                                                                                          А почему ты считаешь, что твоя "головная боль" и твоё мнение о расходе собственного рабочего времени должны идти вразрез мнению твоего руководителя? Может быть, ты рок-звезда? По-моему, если босс решил, что для всей команды выгоднее, чтобы джуны смотрели твои пулл-реквесты, а ты бы им разъяснял, то будь добр — показывай и разъясняй. Или ищи другую команду.

                                                                                                          • +5
                                                                                                            А мы давно на ТЫ с вами?
                                                                                                            Дружище, с таким подходом, мол я начальник — ты дурак, команда не работает.
                                                                                                            И если я пишу код, то задача босса как раз создать мне комфортные условия. А если мне не комфортно — конечно, надо расставаться. «Сейчас везде нужны хорошие счетоводы». А вот боссы из серии «я начальник — ты дурак» востребованы разве в гос структурах и то там все занятно плотно.
                                                                                                            • 0
                                                                                                              Дружище, с таким подходом, мол я начальник — ты дурак, команда не работает.

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

                                                                                                          • +1
                                                                                                            Да это и есть обучение. Почему вы отрицаете возможность для джуна спросить «а почему сделано именно так»? Для этого обязательно надо воркшоп собирать, просто так спросить он не может? Ревью идеально и сделано для этого — вас не отвлекают, не подходят, не срывают с контекста. Задал вопрос — вы ответили когда вам удобно.

                                                                                                            А вот если для человека ответить на подобный вопрос джуна — проблема, это повод задуматься о качестве своего кода.
                                                                                                        • +1
                                                                                                          Один случай в самом начале карьеры вылечил меня от такой фигни. Трассировал плату, сложное место, ну и подходит слесать и говорит — обведи там, лучше будет. Ну кто он такой — я инженер, три года опыта, говорю спорим на ящик коньяка — не получится. Он — я спорить не буду, попробуй. В общем получилось, а я навсегда этот урок запомнил.
                                                                                                          • +1
                                                                                                            Ревью — не столько оценка кода, сколько попытка незамыленным глазом отловить очевидные косяки.
                                                                                                      • +13

                                                                                                        Неправильное название статьи — правильное название "Как менеджмент от своей лени и тупости проср*л все полимеры"!
                                                                                                        Нормальный менеджер ( даже не гениальный — тупо нормальный) дал бы этому Рику возможность построить нормальную архитектуру с самодокументируемым кодом — и компания бы уже давным давно "сделала" всех конкурентов, а у Рика была бы своя школа "кодеров", признание и вообще профессиональное счастье ( а за этим достаток и личное счастье недалеко).
                                                                                                        А тут получилось что и Рика как лимон попытались выжать — но он оказался крепче и смог выжить, а далее получилось так что только он знает как вся эта хрень работает. А так как нормальный код писать было некогда — то получилось то что получилось !!!

                                                                                                        • +11
                                                                                                          Я бы добавил, что я сильно сомневаюсь, что его код был так уж плох.
                                                                                                          Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
                                                                                                          • +2

                                                                                                            Да однозначно — просто если где и были косяки — то я уверен они были архитектурные, а не в самом коде. Но если времени в обрез то ты просто не можешь это исправлять — тупо нет времени… Код то работает !

                                                                                                            • +1
                                                                                                              Ребята там речь о ГОДАХ!
                                                                                                              • +5
                                                                                                                Да, бывает что несмотря на все увещевания программистов — продолжают наваливать новое, что только костылями прилепить удается и баги которые возникают из за непродуманной архитектуры «быстрей-быстрей», вместо того чтобы остановиться и переделать по нормальному. И так до тех пор пока либо это нагромождение костылей не развалится, либо до момента когда уже любое изменение обходится в недели вместо часов, либо до момента когда любое изменение добавляет багов больше чем исправляет, либо… Ну вы поняли.
                                                                                                            • +3
                                                                                                              Можно найти ответ автора в дискуссии, что качество кода начало ухудшаться с определенного времени. То есть, когда он перестал справляться, начались хаки и копипаста.
                                                                                                              • 0
                                                                                                                Я все же позволю себе усомниться что качество когда было низкое. Потому что автор как раз как бы саркастически пишет: «Of course, these bugs were happening because the users had misstated their assumptions. Of course there wasn’t any problem in his work. Of course.»
                                                                                                                О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
                                                                                                                Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
                                                                                                                • 0
                                                                                                                  Сомневаться можно в чем угодно, особенно без доступа к исходникам, но рост числа багов и увеличение времени на их исправление косвенно указывают на проблемы с кодовой базой. Кроме того, я очень сильно сомневаюсь, что можно писать качественный код 12 часов в день каждый день.
                                                                                                                  Ну и если бы он был качественный, его бы не пришлось переписывать из-за отсутствия документации.
                                                                                                                  • +3

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

                                                                                                                    • 0
                                                                                                                      Я отвечал на
                                                                                                                      Я все же позволю себе усомниться что качество когда было низкое.
                                                                                                                      Вы вдруг выворачиваете так, будто я его в этом обвиняю.
                                                                                                                      • 0
                                                                                                                        Более того, проблемы с кодовой базой есть в любых больших проектах (несколько лет разработки, десятки разработчиков). Невозможно всё предусмотреть на начальном этапе, рано или поздно настанет момент, когда нужно всё переписать, вооружившись накопленным опытом и учитывая новые потребности, новые инструменты, новые подходы.
                                                                                                                • +1
                                                                                                                  Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.

                                                                                                                  А я как раз работал с такими синьорами. Они (и их начальство) считают, что если код решает проблемы пользователей, то вообще без разницы, как он написан, лишь бы поскорее в продакшн. А рефакторят пусть джуны, которые всё равно пока не способны решать проблемы пользователей; так пусть хотя бы с кодом познакомятся таким образом.
                                                                                                                  (Что получается, когда джуны рефакторят код, который непонятно что делает и непонятно как работает, без тестов и без документации — деликатно умолчу.)
                                                                                                                • +6
                                                                                                                  Особенно если учесть, с каким удовольствием он делился знаниями в начале. Он реально мог поднять уровень остальных участников команды, если бы ему дали такую возможность, а не тупо использовали его…
                                                                                                                  Реально сами себе ноги расстреляли, потом радостно их отрезали и сказали, что теперь гораздо лучше: и ходить никуда не надо и на ботинки деньги не уходят
                                                                                                                • +4
                                                                                                                  К сожалению, это большая проблема в компаниях, особенно сейчас, когда начали нанимать во множество компаний «так себе» Менеджеров. Но этого мало, основная цель этих менеджеров сделать продукт, а не управлять командой. В итоге уволить теперь можно любого, кто хочет заниматься своей работой, не хочет работать сверхурочно за так и подводит команду тем, что уходит домой по окончанию рабочего времени. И соответственно начинается свистопляска с минимальным временем исполнения задачи которая использует кривые 3rd party компоненты. Просраные сроки. Уставшие сотрудники. «А давайте в субботу еще поработаем, протестим перед релизом». Боязнь увольнения (конечно же по собственному). Выгорание. Аппатия. И… В итоге сотрудник сам кладет заявление.

                                                                                                                  Сам был зрителем того, как уволили именно так минимум 3-х сотрудников. Не самых плохих.
                                                                                                                  • +1
                                                                                                                    в защиту менеджеров могу только вот что сказать «давай работу тому, кто тащит, если дал больше и сотрудник тащит — давай еще»
                                                                                                                    • 0

                                                                                                                      вот и "додавались" — вечно так не получится с кодерами...

                                                                                                                      • +2
                                                                                                                        Обычно, но не всегда, продукт таки выходит и даже работает. Выработавшего ресурс программера заменяют парой-тройкой низкооплачиваемых мурзилок. Суммарная з.п. которых близка к з.п. уволенного программера
                                                                                                                  • 0
                                                                                                                    Документациями /мануалами/wiki данную проблему РокСтаров (Риков) — не решить, это только часть инструментария по налаживанию командной работы. И часто доки служат лишь средством манипулирования.
                                                                                                                    • +3
                                                                                                                      Проблема звездности по большой части бывает как раз у менеджеров, руководства как мне кажется. вот сколько замечаю по работе — что часто штат руководства избыточен, и для того чтобы оправдать свою з/п внезапно принимают решение на применении каких новых методов управления проектами, перераспределение ресурсов внутри компании, или сокращении штата — считая что меньше народа будут выполнять столько же работы. По факту поднимаю шумиху, все также как и политике, они привлекают к себе внимание, тем самым зарабатывая себе звезды. А что будет дальше по факту не особо важно, придумают что то еще, организация же им не принадлежит — главное побольше отпилить для себя.
                                                                                                                      Конкретно данной ситуации — думаю что вся вина на менеджерах, они этого программиста возвысили, в общем то возложили всю ответственность на него — и он просто работал в том режиме который задало ему его начальства. Все большие ожидания от него порождали все больший напряг для сотрудника. Ну и понятное дело что в таком режиме долго не протянешь и рано или поздно просто сорвешься.