Pull to refresh

Comments 439

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

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

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

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

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

Они жаждут лишь того, чтобы ты работал побольше и требовал поменьше)))


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

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

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

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

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

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

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

И у тех и и других есть к этому мотив, и совершенно логично что оба будут стремиться именно к этому.
Не надо говорить за всех. Я тоже как-то полгода сидел без работы, но эту дебильную тактику применять не собираюсь. всё равно это произойдёт само.
А я на работе и не скрываю, что хочу стать незаменимым. И знаете, очень легко получается! Сейчас я незаменимый в ведении документации и выкладывания исходников. И на моей работе нет ни одного сотрудника, у кого есть столько документации и репозиториев.
Неужели бывают настоящие специалисты, которые полгода не могут найти работу? Стоит задуматься, а специалист ли…
Бывают, если за свою работу хотят существенно выше рыночной цены. Хотя тут наверное не «не могут», а «ищут».
Второй вариант — очень узкая специализация в небольшом городке…
Любого незаменимого рано или поздно выкинут (в крайнем случае, из-за разорения или перепокупки фирмы, неспособной наладить нормальное управление). Чем незаменимее, тем позднее. Чем позднее, тем труднее потом ему будет искать новую работу и адаптироваться к ней (технологии уйдут вперёд, а он останется незаменим в старых, плюс навыки нормальной командной работы не выработаются). Так что незаменимость — это палка о двух концах, и эффективна только в краткосрочном плане.
Хорошая статья! В точку проблем не только IT компаний!
UFO just landed and posted this here
В какой-то момент менеджментом был потерян контроль над ситуацией. Стратегия управления разработкой свелась к старому доброму «авось». Ведущий разработчик без внешнего контроля и отсутствия времени на банальный рефакторинг под грузом задач в итоге родил мертворожденную химеру, которую, как оказалось проще пристрелить, чем перестраивать.
Я увидел именно такую историю. Причём не только в статье, но и в реальной жизни.
Заставляет вспомнить все эти:
Если ты хочешь прибавку к ЗП, приди к начальнику и скажи «что я должен ещё сделать для того, чтобы получить прибавку?»

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

Но не в лоб и не у начальства.
Вот только тут встаёт новая проблема. Один человек решал кучу вопросов — основные обязанности и много дополнительных, потому что большая часть из них была настолько отлажена, что не требовало от него значительных усилий.
Но человек увольняется (или его увольняют) и на его место берут другого, от которого ждут выполнения не только его основных обязанностей, но и дополнительных. А он и в основные еще какое то время будет вникать.
Вот и получается, что с человеком расстаются, а потом руководств говорит, что человек зажрался и ничего не успевал, а простой народ говорит, как при нем всё было хорошо — он всё успевал и всё знал.
Уйти единственный вариант для работника? Думаю, сначала стоит попытаться донести руководству идею, что ты крут, но не всемогущ.
Ага, при прочтении оригинальной статьи возникали похожие мысли. Единственное я бы не стал так уверенно перекладывать всю вину на руководство. В первую очередь, на мой взгляд, виноват Рик — это его здоровье и его карьера, раз он наплевательски относится к себе, почему посторонние люди должны переживать? Вообще сам на первой работе аналогично выгорал, потом получил граблями по лбу и понял, что сам виноват — нужно уметь рассчитывать силы.
UFO just landed and posted this here
Так не переросло количество в качество — все обросло костылями и загнулось, потому что он взял на себя слишком много и не вытянул. Лучший код и качественный законченый продукт — разные вещи. Причем реальные деньги, радость, почет и профессиональный рост приносит второе. Когда-то давно меня тоже глубоко возмутило высказывание Макконела типа «Если пишите код по ночам — будьте готовы потратить следующую неделю на его исправление, а то и просто выбросить», сейчас я все еще верю в важность вспышек энтузиазма, но возмущен гораздо меньше)
UFO just landed and posted this here
У проблемы много корней, и один из главных — Рик позволял годами себя меньше кормить и больше доить. Вообще не факт, что с коровой бы такое прокатывало так долго. Глупые менеджеры — не повод вести себя глупо самому.
Согласен — это основа.
Равносильно запросам кучи совершенно постороннего народа — тыжпрограммист, сделай!!!
Отнюдь.
Зарплата Рика тут вообще не при делах.

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

Вот согласен, задача Рика очевидна.

Умный человек ДОЛЖЕН понимать, что его могут попытаться заменить, и иметь вариант на этот случай.

Мне шеф сделал наезд, мол, бездельничаешь, когда работать по настоящему начнёшь? Ответил, мол, давайте обсудим условия.. Мой ответ не понравился, явно ожидались оправдания. Тут же предложил мне уволится. Тут же ответил согласием.

До сих пор (два года после) выслушиваю предложения вернутся. Где-то даже греет востребованность ))

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

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


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

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

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

+1.

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

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


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


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

Это не тупо.

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

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

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

Само собой, это не "гениальность" реципиента, хотя для непосвященного и может так выглядеть. Типа,утром МЕНЯ озарило.. Обычный хуман-интерфейс..

Технология. В фольклере получившая наименование "утро вечера мудренее" .

UFO just landed and posted this here

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

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

Я молодым мог сидеть и до часу ночи, интересно было.

Шеф,видел это, и поднимал ЗП и тп.

Через 15 лет я уже уходил с работы ровно в 18.00, потому что семья, дети.

Наверное, не очень нравилось )))

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

UFO just landed and posted this here
Плохо то, что Рику не предложили компенсировать его переработки и самоотдачи, более того, даже не заметили их.

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

Если тебя не заставляют ОТВЕЧАТЬ ща чужой код, да пусть пишут,что хотят..

Но обычно эти манагеры же говорят "вот ты технически грамотный, проверь за ними, а если чо, ты же проверял, и отвечать будешь". А ЛЮБОМУ технарю проще сделать или переделать самому, чем проверять за другим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот не надо ставить над проектом тех кто сам на своей шкуре не пробовал. Я в такой помойке работал, там нежный мальчик в костюме довел 80% людей до тупо бегства в другие компании.
Да что значит полдня отгула если чувак до 3 ночи кодил?! Это ж де факто 2 смены. Даже сторож имеет сутки через трое без умственной нагрузки, лежа на диване.
Если бы в ИТ все соблюдали трудовое законодательство то разработчики работали бы дня три в неделю. Как кстати один чувак в Гугле и делает — три дня работает остальное время путешествует.
UFO just landed and posted this here
Очень часто хорошие и ответственные специалисты не могут себя защитить в этом плане. Впахивают пока не сломаются.
Полностью согласен с выводами автора статьи.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
Но подождите, ведь в первую очередь менеджмент виноват в том, что не было код-ревью и документации. А может и Рик изначально не хотел давать свой код на ревью, считал это унизительным. Многое осталось за кадром…
По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.

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

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

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

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

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

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

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

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


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

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

По моему опыту, как раз наоборот — чем опытнее программист, тем проще его код.

Не во всех.

Иногда набирают ТАКИХ идиотов, что им обясняй,нет, толку нет.

Был чувак,присылает довольно примитивный расчёт в экселе. Проверил, указал ошибки. Присилает ревью, указанные ошибки исправленны, НО,сделаны новые там, где И ДО ЭТОГО ВСЁ ОК БЫЛО.

Т.е.мало отфиксить ошибки, надо ЗАНОВО весь проект проверить,потому что ошибка может вылезти там, где раньше всё было ок.

В итоге перевёл его в режим "принеси, подай, никому не мешай", раз уж уволить не мог. И тут ПРАЗДНИК: пишет заявление сам. Я потираю руки, наконец, на эту ставку нормального кого возьмём..

Через месяц просится назад, шеф его принимает, мол, он со спецификой знаком...

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

Так время на ревью отличается принципиально, когда его делает подготовленный человек и недостаточно квалифицированный, которому надо разжевывать, объяснять и доказывать.
Это уже не ревью. Это — обучение. А его пытаются втиснуть в ревью и таким образом не доплачивать. Одна из многих уловок хитрого менеджмента по высасыванию соков из людей. Нафик-нафик. Забивайте отдельно время на обучение и отдельно на ревью. Это будет честно.
UFO just landed and posted this here
Так время на ревью отличается принципиально, когда его делает подготовленный человек и недостаточно квалифицированный, которому надо разжевывать, объяснять и доказывать.

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

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


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


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


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

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

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

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

UFO just landed and posted this here
Потому что я вижу для себя в этом только головную боль и трату времени безо всякой благодарности.
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.

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

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

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

UFO just landed and posted this here
Один случай в самом начале карьеры вылечил меня от такой фигни. Трассировал плату, сложное место, ну и подходит слесать и говорит — обведи там, лучше будет. Ну кто он такой — я инженер, три года опыта, говорю спорим на ящик коньяка — не получится. Он — я спорить не буду, попробуй. В общем получилось, а я навсегда этот урок запомнил.
Ревью — не столько оценка кода, сколько попытка незамыленным глазом отловить очевидные косяки.

Чёт заминусили. а реально не могут даже оценить работу.

Далёк от программирования, но встала задача сделать инвентаризацию на складе.

Для этого проще простого всё разложить по полочкам, а потом втупую пересчитать.

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

Был бардак на складе, взялся за инвентаризацию, спрашивают, когда закончишь? Ну недели две надо ещё..

Не пойдёт, иди на фиг, так пересчитаем..

Прошло 3 года, ничего не пересчитано. Говорят, шеф приходил на склад месяца через три, посмотрел, что я успел сделать, и хотел предложить заняться складом. Правда, уже "уволил" меня )))

UFO just landed and posted this here
Я бы добавил, что я сильно сомневаюсь, что его код был так уж плох.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
UFO just landed and posted this here
Ребята там речь о ГОДАХ!
Да, бывает что несмотря на все увещевания программистов — продолжают наваливать новое, что только костылями прилепить удается и баги которые возникают из за непродуманной архитектуры «быстрей-быстрей», вместо того чтобы остановиться и переделать по нормальному. И так до тех пор пока либо это нагромождение костылей не развалится, либо до момента когда уже любое изменение обходится в недели вместо часов, либо до момента когда любое изменение добавляет багов больше чем исправляет, либо… Ну вы поняли.
Можно найти ответ автора в дискуссии, что качество кода начало ухудшаться с определенного времени. То есть, когда он перестал справляться, начались хаки и копипаста.
Я все же позволю себе усомниться что качество когда было низкое. Потому что автор как раз как бы саркастически пишет: «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.»
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
Сомневаться можно в чем угодно, особенно без доступа к исходникам, но рост числа багов и увеличение времени на их исправление косвенно указывают на проблемы с кодовой базой. Кроме того, я очень сильно сомневаюсь, что можно писать качественный код 12 часов в день каждый день.
Ну и если бы он был качественный, его бы не пришлось переписывать из-за отсутствия документации.
UFO just landed and posted this here
Я отвечал на
Я все же позволю себе усомниться что качество когда было низкое.
Вы вдруг выворачиваете так, будто я его в этом обвиняю.
Более того, проблемы с кодовой базой есть в любых больших проектах (несколько лет разработки, десятки разработчиков). Невозможно всё предусмотреть на начальном этапе, рано или поздно настанет момент, когда нужно всё переписать, вооружившись накопленным опытом и учитывая новые потребности, новые инструменты, новые подходы.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.

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

Сам был зрителем того, как уволили именно так минимум 3-х сотрудников. Не самых плохих.
в защиту менеджеров могу только вот что сказать «давай работу тому, кто тащит, если дал больше и сотрудник тащит — давай еще»
UFO just landed and posted this here
Обычно, но не всегда, продукт таки выходит и даже работает. Выработавшего ресурс программера заменяют парой-тройкой низкооплачиваемых мурзилок. Суммарная з.п. которых близка к з.п. уволенного программера
Документациями /мануалами/wiki данную проблему РокСтаров (Риков) — не решить, это только часть инструментария по налаживанию командной работы. И часто доки служат лишь средством манипулирования.
Проблема звездности по большой части бывает как раз у менеджеров, руководства как мне кажется. вот сколько замечаю по работе — что часто штат руководства избыточен, и для того чтобы оправдать свою з/п внезапно принимают решение на применении каких новых методов управления проектами, перераспределение ресурсов внутри компании, или сокращении штата — считая что меньше народа будут выполнять столько же работы. По факту поднимаю шумиху, все также как и политике, они привлекают к себе внимание, тем самым зарабатывая себе звезды. А что будет дальше по факту не особо важно, придумают что то еще, организация же им не принадлежит — главное побольше отпилить для себя.
Конкретно данной ситуации — думаю что вся вина на менеджерах, они этого программиста возвысили, в общем то возложили всю ответственность на него — и он просто работал в том режиме который задало ему его начальства. Все большие ожидания от него порождали все больший напряг для сотрудника. Ну и понятное дело что в таком режиме долго не протянешь и рано или поздно просто сорвешься.
Для наемного работника самое основное, кмк, вовремя осознать простую истину — любая работа заключается в обмене собственного здоровья на чужие деньги. И соответственно строить свои отношения с коллективом вообще и работодателем в частности. Не дожидаясь, пока он за инструментом по выколачиванию денег вдруг, совершенно неожиданно, увидит в вас человека. Например — не пытаться трудовым подвигом заработать себе посмертный памятник в масштабе 1:20 в кабинете генерального директора и начать таки перекладывать часть задач на людей, которым их положено решать в соответствии со штатным расписанием.
UFO just landed and posted this here
Почему? Работает. Человек же отличается от животного, которое не способно сознательно ограничить процесс, приносящий сиюминутное удовольствие в ущерб долгосрочным интересам.
нуу, животные без чувства насыщения вполне себе существуют.
и вовремя отрефлексировать сиюминутность тоже уметь надо — те же пьянки например, сначала всё хорошо, а утром думаешь «кажется тот ящик был лишним...» кто-то быстро учится себя ловить, кто-то так всю жизнь и будет лбами стены собирать…
Статью написал, похоже, сам Рик?

Ничего из описанного не может оправдать фразы на совещаниях вроде «You will never be able to understand any of what I’ve created. I am Albert F***ing Einstein and you are all monkeys scrabbling in the dirt.» Когда разработчик, нанятый для работы в команде, позволяет сказать себе такое, он должен быть уволен безо всяких сожалений. Пусть работает себе дальше как свободный художник, можно например консультантом его нанять, но для работы над проектом он непригоден. Вина менеджмента только в том, что они не сделали этого раньше и тормозили до последнего.
Наверное, если бы он писал статью, она бы и формулировалась аналогичным образом, не находите? И в дискуссии к оригинальной статье предостаточно ответов, критикующих менеджмент.
Это был сарказм. Вероятно, статью писал такой «рик» с маленькой буквы как имя нарицательное, таких везде хватает, и у них, конечно, хватает собственных причин оправдать своё неумение работать в команде и перенести вину на кого-угодно еще (других разработчиков, менеджмент, тимлидов, усталость, выгорание, характер, знак Зодиака). Это видно и из комментариев к оригинальной статье, и из комментариев здесь.

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


Если программисты будут решать еще задачи менеджеров, то нафига они тогда вообще нужны?

золотое правило хорошего менеджмента — «Все успехи команды — это успехи команды. Все провалы команды — это провалы менеджмента».
Я чуть другое слышал: «Если команда выиграла 1 раз — это победа команды, если команда выиграла 100 раз, это победа тренера (менеджера)».
О том и речь — менеджер должен был воспользоваться своими рычагами и уволить нафиг этого гения гораздо раньше, а не позволять ему создавать проблемы для проекта.

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

Как там в «Волоколамское шоссе» было? «Погибнуть с батальоном просто, а ты попробуй пройди с ним 10, 100 боев».

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

И тебе не нужна вина, с ней некомфортно.
Ты всегда белый работящий честно вкалывающий и высокопрофессиональный.
А баги вносишь не ты а менеджеры ночью в Гит лазают все портят
Очепятка. «Белый» — читать как «белый и пушистый»

Ну вот сидит тут 5 человек в команде, каждый занят своей частью, и менеджер.
Если на проекте случается какая-то фигня, кто первым узнает? — менеджер
У кого есть рычаги воздействия на проект? — менеджер
Кто может эскалировать грамотно проблему наверх? — менеджер


Я только могу вовремя донести менеджеру проблему, но и то, только в случае, если я ее вижу. Все остальное должен делать менеджер. Иначе он вообще не нужен.

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

My first meeting on the project was the aforementioned “Albert Einstein” meeting.

И сказана она была на совещании в присутствии всех, даже клиентов компании:

He declared this in front of the product design team, developers, management, and pre-launch customers.

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

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

Почему, если он прав? Он работал 12х7 несколько месяцев или даже год, в то время как остальные разработчики занимались какой-то херней, менеджеры занимались какой-то херней, да походу все там кроме него занимались какой-то херней.

Рик, перелогиньтесь!

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


Ну и про "ежедневное поведение", судя по вот этому куску текста "And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde.", все-таки это был одноразовый взрыв.

К сожалению, в реальной жизни это нормально. В том смысле, что именно так очень часто и бывает.
Да это не правильно, не справедливо, так не должно быть, но с фактами не поспоришь.

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


Тем не менее — это не нормальные ситуации. Почему вдруг такая ситуация стала нормальной?

Нормальная — не в смысле правильная, а в смысле — что это современная норма жизни. Синонимы: типовая, стандартная, обычная.
Да вроде бы там все, включая него, занимались какой-то херней, раз баги в коде только умножались.
а за два года до этого к нему все ходили за советами, и он явно не отвечал «You will never be able to understand», а брал доску и объяснял.
потом перестал, да. вопрос «почему?» исходная статья не особо проясняет. Так-то если одно и то же раз за разом объяснять, тратя по полдня — можно и устать. Или как в том анекдоте про байкеров что «чего с вами знакомиться, вы же каждый год новые»

Фраза из контекста вырвана, если бы я полгода пахал в режиме 24/7 по 10 часов я бы и более резкие высказывания мог себе позволить.

24/7 по 10 часов
Я не очень люблю придираться к словам, но…
10 часов в офисе, остальное время — удаленно.

Проблема ещё и в том, что человек при режиме 24/7 по 10 часов
— из-за хронической усталости становится раздражительным теряя адекватность,
=> и как следствие остальная команда может его из-за это начать воспринимать как "злобного неадекватного мудака", хотя он не мудак, а ему просто нужно отдохнуть.

Я недавно такое сказал на собеседовании. Если я прихожу в компанию и вижу, что там толпа студентов, то это их проблемы. Я им честно сказал, что мне нужно пол года — год на проект и потом им нужно будет полтора года, чтобы разобраться, как это работает. Ничего не могу поделать, если это именно так. Я их честно предупредил.
Даже если мне дадут команду их лучших программистов и дадут время и ресурсы, чтобы их учить, то они только начнут меня понимать хорошо если через года.
Соверешнно нормальная ситуация. Много раз такое видел. Более-менее успешная компания. Но все сотрудники какие-то самородки-самоучки. Которые никогда нигде больше не работали, ничего другого не делали и живут в своём мирке. Кое-как с работой справляются. Ну и как там будет смотреться специалист с двое бОльшим стажем реальной работы, кучей проектов и опыта?
Скажите о чел с завышенным самомнением — а зачем вы им вообще нужны? Разумеется вас нанимают для того чтобы благодаря вам (или равнозрачного вам коллеги — так что не заноситесь) сделать то чего не могут сделать без вас.

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

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

И это есть то за что тебе платят.

А если бы «они» разбирались бы в контроле версий, а не ты — то не они бы тебе за это платили, а ты им.

Они — офигенно «перспективная» и прибыльная компания, которая занимается разарботкой чего=нибудь для кого-нибудь.
Если я им сделаю как положено — с итерациями разработки, сквозной интеграцией, тестированием, автоматизацией сборки, контролем версий и т.п. — то они это не поймут и не смогут использовать.
А если я буду работать, как «они», то и результат и качество моей работы будет как у них — бардак, ошибки, говнокод.
Что с этим делать я до конца ещё не определился. Требовать отдельный независмый отдел, учить людей и выстраивать правильную организацию работы? Но это дополнительная трудоёмкость и может вызвать проблемы в организации — одно подразделение будет работать не так, как другие. При этом «другим» будет казастья, что это подразделение работает меньше, т.к. они делает меньше дурной работы и меньше переделывает. Это даже в случае отдельного человека вызывает проблемы — все носятся, как угорелые, правят свои ошибки по пять раз, а один рабоет по графику и не сидит ночами. Ну и просить отдельные независимый отдел… Это часто воспринимается, как наглость и не находит понимания «зачем?» — Зачем новый отдел? У нас же есть — будешь с ними работать и постепенно учить.
Фраза про Эйнштейна… Разумеется, ничего этого просто не было, иначе бы к нему очередь не выстраивалась и его уход в штопор не парализовал бы всю работу.
Да, в источнике эта фраза есть.
Удручает неумение уважаемых хабровцев в критику источников — даже при наличии сходного или аналогичного опыта, подкреплённого релевантными исследованиями. Но это можно понять и простить: специфика профессии. Когда у тебя в отладчике вместо «от нуля до 100 м» переменная «высота» падает в центр Земли (минус сколько-то км) — то если ты грешишь первым делом на баги в отладчике, ты так себе программист.
А вот откуда берутся такие цветастые цитаты — надо знать, хотя можно, наверное, было бы и догадаться, не имея в анамнезе экстравагантный/социопатический опыт. Берутся они в нашем Вонючем Взрослом Мире — из третьих уст, соединением нескольких фраз в одну. Напр., «Рик говорил: хочу быть как грёбаный Эйнштейн, Рик говорил: все другие учёные времён Эйнштейна — как мартышки. Потом — Рик привёл в пример коллеге решение Эйнштейна, которое то ли действительно позволяло такую аналогию, то ли Рик просто хотел покрасоваться»… В результате — «мама, он меня сукой назвал».
И это, блин, не конспирология. Я не говорю, что вот такой портрет составлялся в организованной кампании против Рика (хотя и не исключаю этого; как-то биография project team и смысл их проекта тоже противоречивы). Просто в Вонючем Взрослом Мире не принято переспрашивать, переубеждать… эволюция же; Рики отомрут.
Чуть позже, после окончания рабочего дня, постараюсь найти время, чтобы предложить комментатору ниже вместе поискать конструктифф и в исходной статье, и в отклике. Он там есть, но не (не тот, что) на поверхности.
только одно подчеркну: по себе знаю, про то, что у чувака завышенная самооценка — не стоит безоглядно верить даже самому себе, особенно, если это тот чувак, который решал твою проблему. Анализ самооценок — самый очевидный, самый идиотский и людоедский способ локализовать проблему.
Разумеется, ничего этого просто не было, иначе бы к нему очередь не выстраивалась

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


и его уход в штопор не парализовал бы всю работу

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


из третьих уст, соединением нескольких фраз в одну

В оригинале ясно сказано, что автор сам слышал эту фразу, и сказана она была в присутствии многих коллег и заказчиков.

Автор не сам слышал. Из третьих уст.
Ещё, это могла быть вообще не формулировка Рика. Взрослые любят задавать «простые вопросы на да или нет». В любом контексте, хоть в присутствии pre-launch customers. «Так ты что, возомнил, что ты...?»
Это может быть нужно только затем, чтобы выявить более выпукло: они правы уже потому, что довели кого-то, кто ответит «да, чорт возьми», до истерики. И эти противоречия по земельному вопросу назрели ещё до активного вмешательства Солорзано, ведь он говорит, что в первую свою встречу с «Риком» — we sidestepped his self-comparison to Albert Einstein.
Это никак не связано с тем, как он себя назвал. Это связано с тем, как он пишет код и как это контролируют менеджеры.

Это связано с доверием всей команды и готовностью с ним общаться. Он всем этим коллегам не начальник.
He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed.
My first meeting on the project was the aforementioned “Albert Einstein” meeting.

Где тут сказано, что он слышал это из третьих уст? Он присутствовал на митинге и слышал это сам.


Это связано с доверием всей команды и готовностью с ним общаться.

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


Это связано с доверием всей команды и готовностью с ним общаться. Он всем этим коллегам не начальник.

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

Он присутствовал на митинге и слышал это сам.

блин, вот хотел же прописать особо, что выражение aforementioned Albert Einstein meeting — скорее, нужно перевести, как «встреча с ранее упомянутым Эйнштейном», нежели «ранее упомянутая встреча про Альберта Эйнштейна».
Вот что мне помешало?
Вы говорите «его уход парализовал всю работу, поэтому он не мог сказать такую фразу».

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

Следовательно, он вообще не виноват.

Другое дело, что мне не понятно, что это вообще за проект такой, в чём была added value вообще, кроме вклада Рика, которого не случилось из-за истерики Рика.

"Meeting" здесь именно "митинг", встреча всех участников команды, на которой что-то обсуждается. "aforementioned 'Albert Einstein' meeting" это "вышеупомянутый 'Альберт-Эйнштейновский' митинг". Самого Рика никто кроме него Эйнштейном не называл.


поэтому ему должны были приписать эту фразу, даже если бы он её не сказал

Зачем? Ну вот как по-вашему это было? Рик ничего такого не сказал, успевал в срок делать всю работу, а менеджеры решили, давайте уволим его и заморозим проект на полгода? А если не успевал и сделал так, что часть работы не могли взять другие, то и так есть повод снять его с проекта. Зачем кому-то дополнительно придумывать, что он якобы вел себя высокомерно, на что это должно повлиять?


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

Разве кто-то сказал, что он поначалу был виноват? Поначалу к нему и претензий не было. Как из этого следует, что он не мог сказать такую фразу потом? Никак не следует.

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

А я отмечаю, что если это правда начало некропостинга, то особо забавное: Ваш вопрос, по сути, звучит как: «о чём вообще такая длинная исходная статья, в чём смысл, какие здесь затруднения — уволить Рика?»
И тем более, обессмысливается обсуждаемый отклик на неё.
другими словами, очевидно, что мотив к самооправданию и к приписыванию Рику невесть какой стивенсовщины — у Солорзано был. Третий. После банальной зависти и не мене банального
Ваш вопрос, по сути, звучит как: о чём вообще такая длинная исходная статья

Нет. В статье мне все понятно. Я спрашивал про вашу логику, почему вы решили, что кто-то фразу выдумал.


другими словами, очевидно

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

Вы спросили именно «зачем бы». И это логично. «Почему я решил, что всё так и было»- ну, потому, что я Рик (точнее, не-Рик) и у меня подгорело, и чо?
Логическую цепочку, доказывающую, что иначе быть не могло, — я не только не могу Вам привести на основе бравого отчёта кризис-менеджера (не совсем же он дебил!), но даже вижу некоторого рода мудрость читателя в том, чтобы такие цепочки не искать. Я просто предлагаю более правдоподобную версию.
На хабре запрещена политота, но про креосрачи в правилах ничего нет? Отлично!!! Вот что считается наукой: на некоем острове были бабочки с длинными крылышками и с коротенькими. Те, которые были с длинными, — вроде как, шустрее, сильнее и должны были всех нагнуть, а раз речь о бабочках, то — согнуть. Однако фактически остались на острове только короткокрылые, а у нас теория, что смерть «отбраковывает» худших, поэтому смертность желанна и полезна, и отбор можно звать «естественным». И как тут быть? Гррх, ну, мог же быть ураган, который снёс всех длиннокрылых бабочек в океан, а короткокрылых пощадил?!!! Мог! Значит, именно так всё и было! Оппоненты посрамлены! Хотели нас ткнуть в «белое пятно» теории, а мы уже и здесь умеем объяснить!
Отчего вот для ангельского дела — оправдания человека — подобных сокрушительных аргументов никак не находится?
Вот если, как я предположил выше, Рику на совещании было сказано: что ты возомнил, что ты Эйнштейн, а мы — обезьяны? — и тот ответил: «да, чорт возьми» — то кто из нас прав, Вы или я? Была фраза или не было? Я не знаю и не хочу задумываться-математизировать!
Но обращу Ваше внимание: мартышки, копошащиеся что-то там в грязи, на совершенно разной высоте с Риком, — таки-копошатся в своей грязи, а не внимают гласу с высот, не выстраиваются в очередь по склону великой горы. Они выпускают свои тупые обезьяньи импакты, аппрувы и релизы, а к Буке-на-горе обращаться — ну его нафиг. ПРОБОВАЛИ, ДА. ОТУЧИЛ.
В статье мне все понятно.

Не смел сомневаться! :-Р
«Не настолько же он… хоть и мой оппонент!»
Мне непонятно, что тогда, по-Вашему, в статье удивительного и несамоочевидного, ради чего её стоило писать, откликаться и комментировать отклики…
Пардон за буффонаду.
Вы спросили: зачем искать ещё поводы уволить человека, если он срывает сроки?
По-моему, уволить Рика было непростым решением — оттого, что его бешеный авторитет держался не на чистой хуцпе, а на очереди в его кабинет и способности решать инженерные задачки.
и ещё оттого, что есть определённый стереотип «разработчика рок-звезды».
и ещё, у него была нерядовая должность, так что порядок «не закрыл- на вылет» к нему не применялся, хотя бы потому, что это только часть его работы как «ВЕДУЩЕГО».
Исходные тексты все об этом.
Логическую цепочку, доказывающую, что иначе быть не могло

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


Я просто предлагаю более правдоподобную версию.

Поскольку вы сделали вид, что не поняли, я поясню. Я спрашивал про логическую цепочку выводов, которые подтверждают, что эта версия более правдоподобная.


то кто из нас прав, Вы или я? Была фраза или не было? Я не знаю и не хочу задумываться-математизировать!

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


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


И да, даже в этом случае это все равно высокомерие. Не говоря уже о том, что для вопроса "Ты что, Эйнштейн, а мы мартышки?" нужно соответствующее предшествующее поведение.


Мне непонятно, что тогда, по-Вашему, в статье удивительного и несамоочевидного, ради чего её стоило писать

Не знаю, ради чего автор ее написал, мой вопрос был не о статье, а о вашем альтернативном объяснении.


Ваши рассуждения про эволюцию это оффтоп, извините, я не буду его комментировать.

В этом случае фраза «Да, чорт возьми» была, а фразы «Я Эйнштейн» не было

Хорошо. Но разница с вариантом, когда после «да, чорт возьми» последует повтор заданного вопроса — «я грёбаный Эйнштейн, а вы мартышки...» — исчезающе мала. А если он повторил вопрос — то его бы точно так и процитировали, вне контекста, понимаете?
для вопроса «Ты что, Эйнштейн, а мы мартышки?» нужно соответствующее предшествующее поведение.

Нет.
Не знаю, ради чего автор ее написал, мой вопрос был не о статье, а о вашем альтернативном объяснении.

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

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

Но процитировали-то его в контексте — а именно, это была часть ответа на вопрос "when the problem crippling our product would be fixed".


Нет.

Почему это? Часто ли вам люди задают вопросы, сравнивая себя с мартышками?


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

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


Повторяю своё предложение: спросим Солорзано-Гамильтона напрямую, слышал ли он своими ушами выведенную в начало статьи фразу.

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

Часто ли вам люди задают вопросы, сравнивая себя с мартышками?

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

Да, перечитав, должен признать, что aforementioned Albert Einstein meeting — скорее, переводится как «ранее упоминавшийся митинг с провозглашением себя Эйнштейном», потому, что «Hmm,… I dove into source code» — всё-таки мало похоже на ретроспекцию «этой встрече предшествовало», да и Past perfect tense не употребляется. (Мало похоже не значит исключено, впрочем). Что не мешает мне продолжать думать, что такого не говорилось либо по-сути-не-говорилось, и продолжать настаивать на подтверждении от автора статьи. Как сформулирую вопрос — так сразу. Мне же надо.
«Зачем вообще рождаются сплетни?»
Давайте автору исходной статьи напрямую зададим вопрос, слышал ли он своими ушами. Хотя получается нечестно с моей стороны, потому что я на свой вариант ничего не готов ставить. Потому, что даже если именно так и говорил…
Есть ли у него семья?
Есть ли друзья за пределами работы?
Возлюбленная?
Дети?

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

У меня был в жизни другой опыт (в самом начале моей карьеры).
Фирме нужно было быстрое решение проблем производительности и в поисках чуда нанимали и увольняли людей, которые должны были их решить (доходило до смешного, что увольняли человека после 4х полных дней работы). Я был частью команды ответственной за производительность (2 человека со скудным опытом в программировании).
И тут наняли сотрудника с замашками рок звезды. Первое что он сказал на первом митинге звучало примерно: "до меня у вас вообще не было ничего, и я это решу". Он даже не вникал в то, что нашими руками производительность кода была увеличена вдвое.
Я должен признать, что ему удалось поднять производительность еще вдвое, но это был абсолютно непонятный и неподдерживаемый код, едва ли не подобранный брутфорсом в некоторых частях.
На почве высказываний в наш адрес и методов написания кода, у нас вырос конфликт и я был вскоре уволен (что принесло мне огромное моральное облегчение).
Спустя пару месяцев звезда ушла в другую фирму, а меня просили вернуться, но я отказался.

Ну так это другой случай. Вы часто ходили к этому вашему звездному чуваку за техническими советами? А вот к тому Рику ходила вся команда по всем сложным вопросам. И он брался помогать и разъяснять каждому. Даже доску специально поставил.
Заметьте, не он принуждал кого-то делать так и так — к нему все сами шли.
Мне кажется программист «со скудным опытом» априори не может оценивать «непонятность и неподдерживаемость кода» специалиста, который успешно решил задачу.

«ускорить в 2 раза» и «ускорить в 2 раза, чтобы было понятно всем со скудным опытом» — это две разные задачи.

Без обид, «скудный опыт» — ведь не мои слова. Ok? :)

Ну, человек, который писал что-то больше курсовой догадается, что


int a[16] = {};
int d = 0;
int dd = 0;
int ddd = 0;

не является эталоном читабельности.


Под "скудным опытом" я подразумеваю 2 года починки багов в большом проекте большой компании.

UFO just landed and posted this here
Это ваше мнение? Может быть он просто заменил какой-то «влобный» алгоритм чуть более продвинутой оптимизацией? Я согласен с предыдущим комментатором, что ускорить в два раза, чтобы было понятно всем — это совершенно другая задача.

Я видел лично этот процесс т.к хотел научиться лучшему. Сидел рядом и смотрел как смещения в массиве подбираются путем перебора.
А насчет того, что было стелано — решены проблемы CPU кэшинга, что реально очень важно там, где миллисекунды идут на счет.


Что делали мы: замена всего что можно на SIMD и переписывание кривого С++ интерфейса сторонней библиотеки, т.к. С++ интерфейс допускал лишние вызовы тяжелых С функций.

UFO just landed and posted this here
Но опять же, возможно вы и правы, и это был действительно криворукий ламер.

Толсто.


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

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

UFO just landed and posted this here

Пофиг кто виноват, число грузовика = 1 — абсолютно ненормальная ситуация, давящая на всех. Кто-то должен был это прекратить — или Рик, или компания. Остальное — эмоции и поиск козла отпущения.

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

О каком менеджменте вы говорите? Его не было как такового, одна большая ошибка с неизбежным плохим концом. Не возникло бы конфликта — случилось бы что-нибудь ещё. Начиная с того самого пресловутого грузовика и заканчивая тем, что разработчика могли сманить в другую фирму. Ну или Рик женился бы на ежихе и уехал жить в дурдом (весьма вероятно при таком ритме работы).


Понятно, что проблема была не в Рике. Не он создал эту ситуацию. Но решать её так или иначе надо. Не смогли по хорошему (договориться с Риком и ввести людей в проект так, чтобы любой кусок понимало хотя бы 2-3 человека) — значит, проиграли, надо бросать полотенце и начинать всё с начала.

Так все понятно. Кроме одного. Почему уволили Рика, а не менеджмент?
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
на сколько я понимаю по статье — его непосредственного менеджера уволили первым. Но не пошли дальше и не попытались выровнять ситуацию с Риком.
Я бы пожалуй уволил весь менеджмент и побеседовал бы с Риком на тему, кого оставить в команде, а с кем попрощаться. Далее, я бы попросил Рика провести интервью и набрать команду из людей, которые были бы его уровня «Энштейн» и с которыми ему комфортно и удобно было бы работать и код которых он мог бы спокойно положиться.
UFO just landed and posted this here

Вовсе не обязательно, хотя споров будет много, конечно. Эйнштейнов лучше сразу сажать в отдельной переговорке :-)

Накалом страстей в комнате, в которой поселят нескольких «Эйнштейнов» можно будет запитать электросеть средних размеров города.
Почему уволили Рика, а не менеджмент?

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

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


Но в любом случае ситуацию уже довели до момента, когда Рика им было не сохранить. А манагеров ещё можно обучить и использовать.

Там что-то было написано про инвесторов…
Ключевой особенностью всех современных концепций управления, таких как Agile, бережливое производство и т.п., является ПЕРСОНАЛЬНАЯ ответственность КАЖДОГО сотрудника за эффективность своего труда, которая включает в себя как эффективность свой собственной работы, так и эффективность своего взаимодействия с другими сотрудниками в рамках команды, необходимая для обеспечения качественной обратной связи.
В статье же просматривается только личная эффективность Рика при отсутствии эффективности командного взаимодействия всех сотрудников, включая самого Рика.
Поэтому статья про Рика является ярким примером истории компании-банкрота, в которой роль Рика сильно преувеличена.

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

Есть книжка Phoenix Project, в которое есть такой Рик. Там очень грамотно описано как они решили проблему с ним, исключили его и все документировали через хелпдеск, подробнее не помню. Но и он остался и разгрузился и другие сотрудники получили возможность заниматься сложными вопросами. Книжка придумана, но идея верна.
Авторы «Проекта Феникс» слишком увлеклись рекламой методологии и в результате получилась гипертрофированная пародия.
Вначале лучше прочесть «Цели» и «Критическую цепь» Голдрата, где теория ограничений (TOC) раскрыта более подробно и без скатывания в идиотизм.

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


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

UFO just landed and posted this here

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

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

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

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

В итоге решил уйти. Грустно это все, конечно.

Хех. Мне одно время приходилось быть таким rock star — в своём же проекте это было несложно. К тому моменту звёздной болезнью я уже не страдал, поэтому более слабых коллег не задирал. Ну… разве что когда они наглели. Тоже жаловались на то, что мой код слишком сложный, но с моей стороны ситуация выглядела как нытьё слабых программистов, что этот и-те-ра-тор это слишком сложная штука и им проще написать в 10 раз больше кода, зато простого. Были тёрки с одним сеньором и его начальником по поводу того как надо работать работу. Попытались даже меня уволить, но в итоге уволили их самих. Потом было другое начальство, там тоже была своя санта-барбара. В конце концов я на всё забил, сменил проект, работаю в пол силы и занимаюсь своими делами в свободное время. Сейчас вспоминаю то время и думаю, что зря всё это было: излишняя привязанность к проекту привела к ненужным конфликтам и практически к выгоранию.

Вообще при прочтении возникали те же мысли.
Но вообще вина «Рика» тоже может наличествовать.
Собственно есть такой стандартный бюрократический метод. Он может даже неосознанно работать — человек (или отдел) стягивает на себя полномочия и функции, потому что может и потому что справляется. Особенно хорошо это заметно, когда полномочия размыты.
С программистами тоже может быть похоже — один человек становится незаменимым контрибьютором и диктует условия. Так как он писал проект долго — он в нем хорошо разбирается, разработка архитектуры только под себя, документации — нет.
Новые разработчики приходят, видят тонны говнокода и человека, который яростно его защищает. И уходят. Со стороны начальства выглядит как будто новые специалисты просто не могут соответствовать требованиям от Гуру.
Самое занятное, что человек уже ближе к концу самым талантливым не остался. Как в 1984: «они не смогут влезть в тебя, говорила Джулия. Но они смогли».

«Порадовал» коммент от Brenna Harris: Рик просто не повзрослел, как и большинство комментаторов. А главное в истории — решить, чья это проблема и не спихивать Ответственность на Взрослых. Потому «Рик» и под вымышленным именем: если назвать или вычислить его подлинное имя, он может подать в суд и обоснованно утверждать, что вот такая история — крест на любых карьерных перспективах в Вонючем Взрослом Мире.
Сами человека загнали в медные трубы и потом уволили. И теперь они Д'Артаньяны?
Он просто не понимал, чем ему это грозит как специалисту и ничего не предпринял. А выход тут простой — надо уходить из такой фирмы самому и как можно быстрей.
Просто нужно осознать, что если все коллеги на голову ниже, начальник боится тебе — то вероятность накрутить себя и вырастить в себе Наполеона стремится к бесконечности. Изифолд.
Гм, возникает вопрос, чем занималась остальная команда, если большинство тасков уперлось в Рика. Когда у него не осталось времени разбираться еще и в проблемах других разработчиков.
да вполне возможно, что остальная команда так же была загружена в силу своих возможностей и нужно было нанимать больше людей. Но для менеджменты это же смерти подобно. Каждый разработчик это же минус пару сотни k долларов, который менеджмент может потратить на свои бонусы. Или это ухудшит показатели компании перед стейкхолдерами. А это опять же может повлиять на финансовое благополучие менеджмента. Вообще, как показывает мои опыт, менеджмент очень любит экспериментировать с IT отделами когда речь заходит о сокращение издержек.
Я сейчас такой Рик. Только админ. И уйти не могу.

Подчиненные/соседние админы есть?

подчиненные есть, но увы они к IT не относятся (водитель и деловод)

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

из армии просто так не уходят…
Ну, если служба срочная, то вам в любом случае недолго осталось. 1 год можно пережить. Если служба не срочная, то, спрашивается, а какого фига?)
Ммммммм… Очень спорное утверждение. В смысле требовать себе помощника. Если есть работа и на неё отведена штатная единица — значит она должна эту работу выполнять в отведённые сроки. Если не успевает, то стоит в первую очередь задаться вопросом — почему. В большинстве случаев проблема не в том, что работа тяжёлая, аа в том, что не умеют работать. И вынуждены браться сверхурочно. Вот, скажем, вы двое, да-да, именно вы. Вы не справляетесь? А я вижу, что у вас больно много времени торчать на хабре в среду в рабочее время. Вы бы делали то, за что вам платят…

Такой подход открывает очень большой простор для злоупотреблений со стороны работодателя.
Сначала "не успеваешь — плохо работаешь значит, работай сверхурочно". Потом "не успел — подставил компанию, изволь заплатить штраф". Потом сговор относительно условий труда и уровня зарплат. А потом опять 1917й.


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

Вы бы делали то, за что вам платят…

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


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

UFO just landed and posted this here
смысл ясен.
1)штаты разрабатывается либо пузатый дядя времен хрущева либо его женская версия, для которых слово «связь» — это телефонная трубка, и о том чем я по факту занимаюсь они вообще не имеют ни малейшего представления. а потому даже моя должность звучит не совсем с оттенком хоть какого то налета IT.
2)добавь к штатным обязанностям еще общевойсковую головомойку, как то — наряды, кучи построений, выезды, тревоги etc.
и получается что на выполнение прямых обязанностей за которые мне платит деньги моя страна, у меня остается не так много времени. и хрен бы с тем временем — сил почти не остается. а у меня парк серверов, куча VoIP оборудования, транкинг…
3) на хабре я сижу во время обеда.
Да всё понятно, не буяньте. Что касается армейского админа — так надо применять армейский метод. Тут нужен не помощник абстрактный, а конкретный связист с конкретными требованиями. В смысле для начальства так понятнее будет. А сам бы ковырялся уже без того же голоса и чисто сетевых фич, обслуживая уже сервера файлов, БД и прочее ТД. Просить тоже надо уметь.
Я вот как начальство, вижу только
кагбэ обед
Alphary 23.10.17 в 11:53
Alphary 18.10.17 в 15:16
Alphary 18.10.17 в 13:42
Alphary 18.10.17 в 17:22

Мне б такой…
велком, можем организовать))
Тут целую неделю нет фразы «не надо оправдываться, я пока ещё не ваш начальник» — потому ли, что Вам знаком этот хрестоматийный эндшпиль («я Вам не скажу, почему, но моим начальником Вы не будете никогда»), или потому, что Ваш оппонент — армейский, или ещё по какой-то причине?
Смешит убеждённость некоторых, что хронометраж дня, всякие там ЛУРВы — не просто «самый верный показатель» целеустремлённости и качества работы, но могут искренне удивить, потрясти, обескуражить владельца замеренного времени (я про человека, а не про его работодателя).
Это иллюзия о том, что уйти нет возможности. Я тоже ей жил, пока в один момент не принял для себя решение. И самое интересное — компания где я работал спустя 2 года до сих пор жива-здорова.
UFO just landed and posted this here
Незаменимых людей не бывает. У меня тоже была иллюзия, что «на дедах вся армия держится»
тут законных оснований нет, что бы уйти)) срок контракта еще не вышел)
а проблемы уже начинаются

Два дисциплинарных взыскания — и на мороз. У меня многие знакомые так поуходили. На гражданке потом всем наплевать на причины разрыва контракта.

в кратце — не прокатывает у нас
Я глубоко убежден в том, что таких «рок звезд» выращивает сама корпоративная культура. Особенно ярко такие звезды сияют в таком классическом энтерпрайзе, в таких коллективах большинство людей держатся за свои обжитые позиции и пытаются снять с себя побольше ответственности при этом скрывая подальше от окружающих свои компетенции или таланты.
Машина построена таким образом, что каждый отвечает исключительно за свой небольшой кусочек и если в какой-то из частей системы (имею в виду предприятие в глобальном смысле) произошел сбой узнать где именно и почему это произошло порой очень не просто.
Некоторые люди же совершенно не могут работать в таком стиле и они рано или поздно либо увольняются либо пытаются возглавить этот бардак. Обычно такие люди появляются в больших проектах по оптимизации/автоматизации/внедрению новых бинзнес процессов и начинают постепенно скапливать знания, которые по хорошему доступны любому из участников процесса — просто никто не хочет заглянуть дальше своего носа. Да, знания оседают в их головах и копятся годами и да — они не переносятся на бумагу в виде документации по двум причинам:
1. Банальная нехватка времени — к рок звездам постоянно кто-то заходит с вопросами, причем с разных сторон — тикеты/телефон/скайп/почта/личная встреча. К стати, в ходе таких консультаций тоже копятся новые знания (вот такой вот снежный ком)
2. Полнейшее отсутствие мотивации — 90% документов все равно никто тупо не будет читать
И такой расклад в первую очередь бьет по «рок звезде» т.к снежный ком знаний растет а времени меньше и меньше. И тут опять возможно 2 варианта развития событий:
а. Рок звезда увольняется, оставив все накопленные знания при себе. При этом в компании ничего не изменилось и процессы стают на тот же уровень коммуникаций как и до появления рок звезды
б. Рок звезда вежливо общается с руководством (т.к это прежде всего в его интересах) и руководство составляет конкретный план действий по изменению корпоративной культуры к лучшему.

У нас в компании есть похожий человек, его зовут Фрэнк. Уже полгода минимум одна из историй в каждом спринте посвящена эпику под названием "defrankifying" ;-)

пожму руку тому адекватному CIO, который успеет найти безработного Рика, захантить Рика, в договоре прописать, что после 1го месяца работы компания предоставит Рику оплачиваемый ретрит\спа в теплой стране сроком в 1 месяц, чтобы сгоревший Рик восстановился физически, ментально и душевно.
Ну вы как будто не при капитализме живёте, право слово. Для менеджмента специалисты — ресурс. Выработать и выбросить.
Никто вам не поможет, кроме вас самих (как, например, коментататор ниже). Увы.
Искренне сочувствую всем минусанувшим. Ибо розовые очки имеют обыкновение разбиваться стёклами внутрь.
Причём тут «розовые очки»? Тот факт, что мы живём при капитализме не мешает нормальным компниям иметь игровые комнаты и всячески помогать работникам. Просто потому что это, на самом деле, выгодно.

Менеджеры, плохо эксплуатирующие станки, которые могут работать по 20-30-50 лет точно так же подлежат увольнению, как менеджеры, «ухайдакивающие» разработчиков за 2-3 года.

Точно так же, как лучше у станка сменить прокладки до того, как у него там закоротит всё нафиг наглухо, так же и сотрудника дешевле отправить на хороший курорт, чем искать нового и ждать, пока он «притрётся».

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

Мой код слишком сложен — слышал я (пишу на Java). Слишком сложно — это использовать Stream api для трансформации/фильтрации. Другой «сениор» это не осилил. Переписал на итератор. Слишком сложно пишу видимо(или просто квалификация разработчиков остается на каком-то уровне выше которого им подниматься лень).

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

Да и руководство тоже молодцы. Сделали все для того что бы Рик выгорел. А потом нашли крайнего вместо того, что бы разобраться в ситуации на самом деле. Не снимаю вину с Рика, но менеджер должен уметь менеджить(простите меня за тавтологию). И уволить нужно было еще парочку менеджеров вместе с Риком(хотя может быть Рика нужно было просто отправить в принудительный отпуск/кинуть на другой проект).
Ну так они там менеджеров и уволили первыми. Перечитайте первоисточник!
И всё же, согласитесь, исходная статья полезнее и информативнее для Риков и потенциальных Риков, чем даже отклик его «адвоката»! Только если все инсинуации насчёт самооценки и якобы фраз про Эйнштейна пропускать мимо ушей, ибо BS. Но как оно работает при смене руководства затянувшегося проекта и как талантливый разработчик может перестать быть талантливым — уэлкам!

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


С тех пор открыл для себя принцип YAGNI (you ain't gonna need it), который практикую сам и пропагандирую коллегам.


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


Уверен что Рик был незнаком с этим принципом.

Главное, что бизнес там, похоже, не знал, что хотел, или не существовал вовсе — судя по истории болезни.
В лучшем случае — дерзновенные «pre-sale customers», не путать с «заказчиками»!

Впервые услышал сейчас про YAGNI.Интересно, что об этом думает Paul Graham — человек не без бизнес-опыта, но приверженный панматематизму и культу мощности языка, а потому евангелист Лиспа.
Сейчас пишу с телефона, а завтра с полноценного ПК обязательно поищу, что он думает.
Надо разделять мух и котлет.
Если человек м*к и всех бесит — надо его убирать, независимо от его гениальности. Потому что из-за него кому-то другому просто неприятно находиться на рабочем месте. А 100 центурионов в боевом порядке, работающие слаженно круче 1000 берсерков, хотя 1 берсерк круче 10 центурионов. Разлад и дрязги в команде — предвестник конца.
А если человек просто специфический (но при этом не напрягает своих коллег там поведением, запахом, внешним видом итп) и не очень может работать в корпоративном духе (ну вот не может он раз в неделю писать отчеты о своей работе и документировать каждый шаг), но при этом весьма квалифицирован — то с таким ИМХО лучше научиться жить. Вероятно руководителю даже имеет смысл сделать исключение и взять процедурные обязанности этого сотрудника на себя. Все-таки квалифицированных кадров не так просто найти.
Конечно 100 центурионов круче 1000 берсерков, ведь каждый у каждого центуриона под командованием 100 легионеров.
Это историческая неточность =).
Я думаю смысл понятен.
Другая аналогия — рядовой армии ни в каком сравнении не стоит рядом с опытным боевиком-наемником, который с 16 лет бегает с автоматом.
Однако регулярная армия всегда эффективней.
Однако регулярная армия всегда эффективней.

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

Чеченские кампании Вас ничему не научили.

Научили тому, что когда в армии бардак — она воевать не может. Даже если велика числом и имеет артиллерию с авиацией.
Наша армия (по крайней мере того периода времени) — не самый лучший пример.
Хотя по этому конкретному вопросу у меня тоже есть отдельное мнение, но я не хотел бы углубляться в эту тематику.
А у сирийцев на начало войны какое было состояние ВС? Или у ливийцев? Вряд ли там был бардак… Однако бородатые мужики на Тойотах и там и там навели шуму.
Я ни разу не сомневаюсь что бардак и был, причем не то что в армии — а в стране. По крайней мере в Ливии. И бородатые мужики как бы не сами по себе там шорох наводили а при поддержке регулярных соединений армий стран НАТО.
Тем более что там не какие-то бородатые мужики были а куски собственной армии в том числе.
Должен быть порядок и мотивация. Как в Израиле например. А не борьба политической элиты за место у кормушки. Без этого армия — не армия.
Все три приведенных Вами примера — это по сути гражданская война. Гражданская война — это априоре ппц и анархия. Если Тель-Авив и его метрополия захотят отделиться от Израиля — израильская армия мгновенно перестанет быть самой боеспособной армией в мире.
Вообще в наше время довольно трудно найти подходящие примеры — потому что все войны это либо разборки внутри страны либо противостояние разных регулярных армий.
Дальше надо искать — как раз во временах легионеров/центурионов или крестоносцев.
Скиньте где почитать про бородатых мужиков на тойотах (ИГ) и регулярные соединения армий стран НАТО.
Нет, не скину. Потому что
а) к теме статьи это отношения не имеет
б) как я выше написал — этот околополитический дискус я развивать не хотел бы (ну то есть это вежливая форма фразы — не буду).
До этого вас это почему-то не останавливало.
Ну начал то я не с этого. =)
Но на один большой оффтопный комент меня развели. Больше не получится.
Просто если продолжать — начнется срач на тему хорошего/плохого Каддафи, хорошего/плохого Асада, Америки, Путина, Навального. Понабигут политически ангажированные тролли.
Нафик.
Вы считаете, что вы не ангажированы политически?
У меня безусловно есть собственное мнение на все происходящие в стране и за ее пределами процессы. Но я стараюсь его особенно не выражать (и тем более не пускаться в его обоснование). Особенно вне пределов моей профессиональной деятельности.
Ну то есть я могу порассуждать на тему состояния радиоэлектронной промышленности в нашей стране, но дальше этого я стараюсь не ходить.
Все политически ангажированы — но не все бегают и с пеной у рта доказывают свои взгляды.
Я скажу даже больше. Мои политические взгляды незыблимы, являются истиной последней инстанции и не подлежат оспариванию.
По этой причине мое участие в политических дискуссиях является бессмысленным.
За сим предлагаю эту тему не развивать.
В Apple считают несколько иначе:
I noticed that the dynamic range between what an average person could accomplish and what the best person could accomplish was 50 or 100 to 1. Given that, you’re well advised to go after the cream of the cream… A small team of A+ players can run circles around a giant team of B and C players.
Не Эпплом единым.
Я несколько раз был в Мелланоксе. Там работают самые обычные разработчики средней руки. Далеко не глупые ребята, но в общем-то не блещущие какими-то супер-способностями. Они просто неспеша, методично и слаженно делают свою компанию лидером в своей отрасли.
Ну да, там наверху есть человек мыслящий глобально и концептуально. Но не им единым живет данная компания.
Я много раз бывал в компании MSI по прошлой работе — абсолютно то же самое. Большое количество обычных разработчиков, гении у них там табунами не бегают. Однако материнские платы пекут как горячие пирожки.
Да там продукт, похоже, под Рика был изначально запланирован. Куда убирать?!
Продолжу (ибо не могу дописать).
По своему опыту.
Если от меня зависит брать или не брать человека на работу я ВСЕГДА в первую очередь представляю что мне с этим человеком потом взаимодействовать каждый день. И я всегда буду противником социальных экспериментов по приему фриков на работу. Человек должен быть аккуратен, опрятен и вменяем. А потом уже квалификация — это мое ИМХО.
А касательно формальных вопросов — мне например не западло завести за кого-то issue или написать какую-то бумажку, если я вижу что ответственный человек реально занят. Я воспринимаю это как часть своей работы. Просто так надо.

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

Да, именно так я и сделаю.
Мне не важно во сколько раз кто кого квалифицированнее. Мне важно:
1. Достаточно ли кандидат квалифицирован в принципе. То бишь естественно просто хороший парень, который ничего не знает — тоже не пройдет, если нет цели взять стажера.
2. Чтобы я не морозился потом, каждый раз когда мне нужно будет с этим человеком что-то обсудить. Если человек вызывает во мне негатив при первом знакомстве — скорее всего он меня будет бесить при ежедневном общении. Зачем это надо? Чтобы что?
Директора и хозяева обычно не проводят отбор кандидатов. Ну и на уровне топ-менеджмента другие правила игры — но фриков там уже нет по определению. Если мы конечно не говорим про лавку из 3х человек, единственная задача которой — продаться Google.
Вы просто поймите правильно. Я же говорю не о том, что человек должен ходить в костюме с галстуком и свеженькой прической каждую неделю.
Это крайность.
Но он не должен там… вонять. Его одежда, руки итп — должна быть чистой. Он не должен эпатировать окружающих своим поведением и внешним видом. Это же вполне нормальные требования. Если это не соблюдено — то мне абсолютно пофиг сколько там чего такой человек знает. Ни я ни моя команда с ним работать не сможет — а это сводит на нет всю пользу от его квалификации.
UFO just landed and posted this here
Скорее у него работают неплохие спецы, моющиеся каждый день

Именно так и есть. У нас достаточно эффективная команда, на которую в то же время приятно посмотреть и c которой не стремно находится в одном помещении торговцам и прочим ребятам, для которых лицо — это часть работы.
Но зачем в одно помещение с программистами сажать торговцев и прочих шумных ребят?
У нас не только программисты, но и схемотехники, топологи печатных плат, конструктора — все сидят в двух больших опенспейсах вместе с работниками других подразделений.
Ответа на вопрос «зачем» — у меня нет. Такой офис.
Это кстати еще большой вопрос кто более шумный :)

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

Ну т.е. работодатель, как всегда, экономит

Да я бы не сказал что офис очень экономичный… Просто вот такой вот он. Не кабинетный. Видимо сейчас так модно.
На самом деле в таких офисах ИМХО самое плохое не шум, а то что все ходят и смотрят в твой монитор.

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

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

Судя по тексту статьи, он довёл себя самостоятельно.


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


1) Беседа №1
2) Беседа №2 ("если не справишься, нам придется расстаться")
3) Чемодан-вокзал

Судя по тексту статьи, он довёл себя самостоятельно
это хорошая отговорка для менеджера этого сотрудника.

2) Беседа №2 («если не справишься, нам придется расстаться»)
Ну да, сотруднику который тащит на себе больше задач чем кто либо, подходить с такой фразой. 5 баллов для «эффективного менеджера».

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

Он в детском саду работает? Нет? Тогда должен самостоятельно оценивать объёмы работ, которые сможет выполнять, укладываясь в сроки.


Да вместо 2й беседы должна быть принудительное отправка такого сотрудника в отпуск недели на 2

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

Он в детском саду работает? Нет? Тогда должен самостоятельно оценивать объёмы работ, которые сможет выполнять, укладываясь в сроки.
Нет, он работал под менеджером который должны оценивать количество задач вообще и количество задач на сотруднике. Это его прямая задача — управлять. В том числе и нагрузкой. Задача сотрудника вроде Рика — выполнять задачи.

Опять детский сад. Ему никто не запрещал уйти в отпуск и не заставлял работать овертайм, насколько я понимаю.
Ну да… «Чувак, ты можешь в любой момент пойти в отпуск. (за кадром) Только помни — твои задачи сможешь сделать только ты. Так что после отпуска придется работать по 20 часов в сутки, что бы закрыть то, что накопилось за эти 2 недели + то что будет приходить в обычном режиме. И да — компьютер с корпоративным доступом не забудь. Т.к. руководство понаобещала клиентам множество новых функций и сделать их надо ASAP, а на дополнительных сотрудников у нас денег нет. Ты же не хочешь подвести команду???»

И опыт говорить «нет» в таких ситуациях приходят с годам и с количеством «граблей»!
за кадром

Я мысли читать не умею, так что завидую, что у вас есть такая способность


менеджером который должны оценивать количество задач вообще и количество задач на сотруднике

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

А зачем тогда менеджеры? Если он все должен сам делать?


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

Если на нем так много держалось, то вполне могли и запрещать.

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

Я не понимаю, о чём тут с вами спорить.
Может ему мама попу вытирает, пока он код пишет, поскольку он сам не в состоянии увидеть, что она грязная.


Ещё раз — мы говорим о взрослых дееспособных людях или о ком?

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


Задача программиста — это писать код. Да, он мог сделать много чего, но если он этого не сделал — это не его ошибка.

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

Может поделитесь ссылками на авторитетные источники с исследованиями данного вопроса?


если сеньор не способен адекватно раскидывать задачи и тикеты

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

Не соглашусь, "сеньорный" сеньор должен уметь работать в любой роли SDLC, от продукт овнера до тестировщика. И совмещать их при необходимости.


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

А можно подробней про связь между продукт овнером и SDLC? А то как то в быстром поиске нашел что такое SDLC но роли там не выделяются явно. Да и сам по себе SDLC хоть и испытывает влияние Agile-методологий, но существует и в том же RUP, Waterfall, etc.
Под SDLC подразумеваю Systems development life cycle. Возможно, вы подразумевали что то другое.

Да, software development lifecycle. Помимо собственно жизненного цикла приложения, он задает и роли людей, которые этот цикл обслуживают.


Все это подробно описано в SWEBOK

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

у меня вот есть один товарищ, он в рассуждениях похож на вас. Те же фразы про детсад и т.п… Все дело в том, что он в свои 38 лет, ни дня не проработал на кого-то. Все время работал на себя. И вот он считает, что все вот такими должны быть. Точнее считал. Все его ожидания начали сыпаться в пух и прах, когда он сам, после 15 лет фрилансерства, стал работодателем. Его подход был ровно такой же с сотрудникам и он очень удивлялся, а чего рабочий процесс не идет. Он упорно не понимал, что если у человека будут такие же качества как у него, такой человек не пойдет на ту работу, которую он предлагает и за те деньги которые он предлагал. По сути он хотел, что бы каждый сотрудник был сам-себе менеджер. А таких людей мало. Т.к. это очень редкий тип людей которые имеют к это предрасположенность либо это нужно воспитывать — то есть опять же работать с людьми для начала. Для всех остальных должна быть четкая система оставляющая минимальное пространство для решение, а что же делать в первую очередь. И все это должно постоянно мониториться.

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

:D Чистка зубов, на базов уровне, это habits, привычка которую нам привили(вдолбили разными методами — чаще всего постоянным контролем с объяснением пользы) родители/воспитатели в детстве. Редко какой ребенок чистит зубы каждый день самостоятельно(мне ребенка постоянно приходится контролировать). Да и не каждый взрослый(согласно российской статистике — 30% взрослых не чистят зубы).

А то, что мы обсуждаем — в детстве редко закладывается. Обычно это уже могут закрепить и развить работодатели и наставники в более взрослом периоде.
О, вот тут проходит граница, из-за которой расчеловечечкой знакомо потянуло…
Зубы… вонь, как от бомжа… в голове один мат… что ещё сопутствует либо подтянется само собой к фричеству+упрямству, м?
Зазвездившийся сотрудник сам по себе это не такая уж и большая проблема. Из этого можно извлечь плюсы — как минимум понятно как его мотивировать — просто поддерживать его звездность. Не надо его «опускать» — наоборот надо всячески холить и лелеять его самооценку, говорить ему о том какой он клевый и незаменимый. Пихать его во всякие конференции и семинары. Иногда в обмен на повышение оплаты труда.
Гораздо хуже когда непонятно — чем пронять человека, чтоб повысить его эффективность. Кому то денег надо, кому-то ответственности, а кому-то публичности. Это нормально.
наоборот надо всячески холить и лелеять его самооценку

Ага, от этого у них вырастает холка и лелейка

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

Господи, это работает? И правда детсад.


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

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

Видимо мне повезло, потому что на меня эти свистульки и погремушки никогда не влияли.

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

Так я не отнимаю право у человека иметь свои ценности.
Просто когда один человек демотивирует 20 других — с ним надо прощаться, потому что за 20 человек он работать не сможет.


Ну то есть пусть он имеет право на свои ценности где-нибудь ещё, где он не будет ими мешать остальным.

А это как раз то, о чем я написал в начале.
Если человек м*к — от него надо избавляться независимо от его скилов.
Причем «звездность» далеко не всегда сопряжено с вышеозначенным признаком, равно как и вышеозначенный признак далеко не всегда сопряжен с «звездностью».
Чаще наоборот — эти вещи вместе не ходят.
Мрачный и стремный гений — это скорее стереотип чем регулярное явление.
Я правильно понимаю, что прошлый работодатель — это гос. компания?

Нет, не гос. Но рядом там. Хотя у нас в стране почти все рядом там…
я свои выводы сделал на основании собеседований с сотрудниками этих компаний

Ну и кстати зря. Молодежь там весьма толковая бывает. Не опытная да (собственно поэтому она там и ошивается — надо же где-то начинать) — но опыт дело наживное. Вот с людьми постарше, которые там 15-20 лет просидели — да, надо быть аккуратнее. У них уже сложившиеся стереотипы и подходы к работе есть, не самые оптимальные часто.

Ну и добавлю еще по поводу «работает». Не смотря на свое текущее виденье той ситуации и некоторый цинизм по этому поводу — я все равно этим дипломчиком горжусь, и не преминую указывать его в своем CV. И на работодателя оно вполне себе тоже действует, хотя конечно не в виде определяющего фактора, а как дополнительный плюс при прочих равных.
Так что работает и еще как. Финансовая мотивация не есть панацея на все случаи.
Вот с людьми постарше, которые там 15-20 лет просидели

Я ровно про этих


не самые оптимальные часто

Очень мягко сказано

Согласен с автором на все 100%. Все нормальные люди проходят этот момент в свой жизни, если искренне отдаются работе.
Не смотря на ошибки менеджмента (что, кстати, компания понимала и о чем в оригинальной статье упомянуто), Рик им только потакал продолжая накапливать себе работу, не объясняя свои решения руководству и\или коллегам скипая планерки, резкими высказываниями отвращая других сотрудников от сотрудничества и, скорее всего, даже защищая свои куски кода от переписки на более понятные и поддерживаемые. Если у Рика было право на отдельный кабинет и власть, чтобы его не дергало начальство на планерки, и репутация у команды, то он с тем же успехом мог делегировать часть своей работы другим свободным людям без дополнительных согласований с менеджментом. Однако он выбрал роль рок-звезды проекта, а раз не справился с ней, то что оставалось делать компании?

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

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

Он взрослый человек и должен был оценивать объем работы. В статье нигде не сказано, что его раньше принуждали работать 24\7 и даже сказано, что после инцидента «He refused to take time off or allow any work to be delegated. He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools.» Новый менеджмент пытался сохранить сотрудника, какое-то время, просто Рик оказался человеком, не способным справится с падением ЧСВ и это уже вовсе не беда менеджмента. Они ведь были виноваты только в поднятии чсв Рика до неба.
Ну правильно. Новые фреймворки надо вводить в проект когда велосипеды еще не написаны.

Они даже не пытались его понизить нормальным путем. Они потом продолжали его подкармливать, совершая неправильные шаги.


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


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

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

Из оригинальной статьи:
I’d been aware of the project for a while, because it had grown infamous in my organization, but hadn’t been assigned to it.

I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues.
It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.

И снова из оригинально статьи:


We sat down with Rick and had a conversation about his role in the project. We reviewed our concerns. We sidestepped his self-comparison to Albert Einstein.

We explained our new strategy. The team was going to collaborate on building a new product from scratch.

Я про то, что в этом месте тоже была совершена ошибка.

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

Автор четко пишет:
His manager shares in this responsibility.


А в чем, по вашему мнению, ошибка? Нужно было дать Рику продолжать пилить проект в одиночку? Там же были использованы все возможные методы перед увольнением: от предложение взять несколько выходных до просьбы передать часть своей роботы команде.

Нужно было не обижаться на фразу, что за чужие факапы Рик не берёт на себя ответственности и, действительно, снять с него такую ответственность (как странно, правда?)
Нужно было получить, наконец, чёткое ТЗ — даже если заказчиков не существовало (а там похоже на то).
Нужно было, ять, встречаться с Риком (терпя его! Ахахах… как какие-то тупые разработчики! Может, ещё место в очереди их к нему занять?! А вы представляете, что мы слышали: он себя Эйнштейном перед кастомерами назвал! (Вроде бы). Фууу!!11) КАЖДЫЙ ДЕНЬ, а не в три китайских предупреждения.это же единственный ключевой человек проекта! Кризис-менеджмент Golden Horde mode?!
Неее, Вонючий Взрослый Мир — и всё тут.
Самое простое было бы ЗАСТАВИТЬ Рика писать документацию, раз в запасе было ещё полгода. Это не унизительно, а почётно, и в процессе он бы половину всего кода своего выправил. Но нужна же была картинка-биография-парабола вниз
В статьей не учитывается, что специфика ИТ-области уникальна.

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

Через 2 года, как описано в статье, Рик мог отправить несколько резюме в СФ и жить на 800+ к рублей в месяц. Почему он этого не сделал? Может потому что он идиот?
Потому что некоторым было выгодно, чтобы он больше взвалил на себя. Рику же было это приятно и почётно, что ему доверяют. Однако, постоянная работа в режиме 12х7 психически здорового человека скорее доведёт «до каления». Особенно, если на нём замыкаются многие процессы, происходящие в компании.

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

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


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

Во во, пришел стажером — 9 часов на работе работа и учеба, 3-4 часа учеба дома, учеба на выходных, иногда работа на выходных… Все что это мне дало — нервный тик еще на год после полугода в таком режиме, и постоянные головные боли от которых только года через 2 отходить начал.
да он и так был в СФ. И скорей всего зарплата была поболее

Через 2 года, как описано в статье, Рик мог отправить несколько резюме в СФ и жить на 800+ к рублей в месяц. Почему он этого не сделал? Может потому что он идиот?

Возможно все гораздо банальней — он человек которые до последнего верил в компанию, в которой работал, в продукт. Зарплата, скорей всего, устраивала. И то что перегрузки — «ну так это временно» (скорей всего еще и подпитывалось менеджментов «вот сейчас выйдем на ICO/нас купит Гуугл, вот тогда и заживем. Надо чуть-чуть потерпеть. На том свете выспимся.»). Ну а что бы понять, что такие проблемы не временные — нужен опыт и каждый его по разному и разное время набирается.
есть люди, для которых перерабатывать — это норма. у меня сейчас есть такой коллега.
сидит каждый день до поздна, пишет быстро, некоторые читают его гением.

Но код — просто вырви глаз. Этакое спагети с багами без намёков на паттерны.
Короче — много работать, ещё не значит хорошо. Я бы некоторым законодательно запретил перерабатывать.
Через 2 года, как описано в статье, Рик мог отправить несколько резюме в СФ и жить на 800+ к рублей в месяц. Почему он этого не сделал? Может потому что он идиот?

Это средняя зп миддла в калифорнии…
увольнение Рика было лучшим решением, которое они когда-либо принимали

Похоже на честное признание менеджмента, что кроме принять на работу, выжать все и уволить других методов управления нет.
С пониманием отношусь к такому решению менеджмента. За все свои работы убедился, что только это и работает. Не бывает полумер (к сожалению)
Наверное, Вы пробовали сугубо неправильно делать всё остальное.
Потому что таков директивный менеджмент, и в этом его ключевое отличие от servant leadership. Я бы еще обратил внимание на факт, который описывает в своей книге Чед Фаулер: если ты не рассказываешь начальству о своих успехах, начальство, как правило, не делает ничего, чтобы о них узнать. Речь здесь не идет о каком-то бахвальстве, а просто об информировании о положении дел. В эту ловушку и попал Рик — с его точки зрения он был героем, который тащил все на себе, а в глазах менеджмента оказался непонятным чудиком, замкнувшимся в кабинете и огрызающимся по каждому поводу. Наверняка в ход шли такие слова как «non-proactive», «unresponsive» и «pushback». Я предполагаю, что каждый либо уже оказывался, либо еще окажется когда-нибудь в подобной ситуации.
Спасибо, согласен с Вами
По-моему, в оригинальной статье все это изложено:
I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues.
It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.

Но в статье сделан акцент на менее очевидных вещах:
By this point the whole team knew he was destructive. But the cult of dependence was so strong that everyone believed he was the only option.
There is always another option.
Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.
«Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.»
Далеко не универсальное правило. Команда из крепкий середнячков не выдаст революционный продукт на гора и не сделает чего-то «сверх». Когда вы делаете новый продукт на конкурентном поле, нужен человек-звезда, лидер. Со своим взглядом и стратегическим видением. Он сформирует образ будущего продукта. А серая сплоченная масса хороша для поддержки опердня в банке.
У вас ложная дилемма. Из ваших слов получается, что в сплоченной команде с взаимным уважением никогда не бывает сильных лидеров.
Бывают сильные лидеры, почти не бывает «звёзд», способных создать что-то, чего никто до того не создавал.

Грубо говоря условный Стив Джобс никогда не будет подчиняться условному Джону Скалли — однако при этом он может создать как прорывной iPhone, так и мёртворождённую Lisa'у… как повезёт.
Лучший коммент, между прочим. А я голосовать не дорос…
Вы видимо не поняли текст автора. Воспользуйтесь переводчиком. Он отрицает первостепенную значимость индивидуальных талантов. Вот с чем я не согласен.
Прям Америку открыли. Любой тимлид знает что такие как Рик убивают проект. Кто-то считает что смертельная доза 1 рик на 5 человек, другие считают, что 1 рик на 30 человек. И использовать только для прочистки узких локальных затыков. И ваще не подпускать к основным вещам.

На черта мне быстрый конь. который не бежит в ту сторону в которую надо? Толку от того что он за 20 минут доскакал до Иркутска. если мне надо было в Рязань?
Проблема, видимо, в слишком разном уровне у людей в команде. Если один гений, а все остальные джуны, то если только он не гений в управлении людьми — ни чего не выйдет, все закончится именно так.
Сам был в роли почти такого Рика, хотя уволился на примерно пол пути.
В оригинале, конечно, виден целый ряд проблем. Лично по моему опыту и рассказу автора, получилось следующее:
  • в компании был отличный спец с багажом знаний;
  • в компании была толпа некомпетентных разработчиков, которым все это нафиг не нужно. Не джунов, а именно людей, кто не хочет разбираться, и программирование для них — просто какая-то профессия, за которую неплохо платят (это сейчас вообще довольно популярная проблема). В итоге получилась ситуация, что проще сделать самому, чем объяснять коллеге, куда смотреть и что делать. И даже если он сделает, то сделает плохо и придется переделывать.
  • в компании Рики рубил идеи других разработчиков. Если разработчики бы были компетентными, они могли бы аргументированно могли продвинуть свои дели. Значит, идеи были говно.
  • в компании за 2 года (или сколько там в сумме?) никто не задал вопрос, что происходит. Там вообще, кроме Рика, кто-нибудь хоть какую-нибудь функцию выполнял?
  • большая нагрузка в режиме 12/7 свидетельствует о том, что был дедлайн, и чувак пытался как мог к нему успеть. Часто такой режим подразумевает костыли, отсутствие серьезного тестирования, говнокод и прочие проблемы разработки. И тратить время самого ценного сотрудника компании на то, чтобы в этом аду дедлайна объяснить джуну, как поправить конфиги — кощунственно.
  • любой адекватный развивающийся разработчик с радостью перепишет свой код. Потому что сегодня ты лучше, чем вчера. А завтра будешь лучше, чем сегодня. Отказываться от этой затеи можно только в тот момент, когда нет желание этим больше заниматься, либо дедлайн (и это самая частая причина, почему нет рефакторинга).
  • в итоге оказалось, что было еще целых полгода, за которое толпа бездарей (либо же новых сотрудников? это как-то не указано явно) смогла переписать проект. Чо-то какой-то небольшой проект, вам не кажется? Можем, Рики вполне мог делать какие-то отдельные части?


Короче, что-то не так в этой компании.
Переписать, урезав функционал «от всего и вся, с 15000 свистелок и перделок» до «3 путей, которыми действительно пользуется 99% клиентов».

> Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow.
+ еще за два года Рика + два года переписывания вышли новые фреймворки более удобные.
А еще, когда переписываешь код, уже видишь весь функционал. Кто пишет приложение в гонке за сейлзами, такой возможности не имеет и потому его архитектура всегда неактуальна.
Понимаешь, ты читаешь это отверждение от менеджера, который обосновывает свое офигенное участие в этом проекте. Он, якобы, молодец, что все поняли и оптимизировал.

Только в большинстве случаев это неправда. Убрать доступ к ФС телефона или выпилить AUX разъем — это кагбэ тоже «убрать свистелки и перделки, упростить все до 3 путей использования», но лучше ли это для конечного продукта? Или, например, убрать кучу проверок из кода, может, и упрощает чтение кода, но уменьшает надежность.

Я тоже, бывает, открываю наши большие проекты и думаю, нафига тут сколько всего нагородили, нельзя было проще? А в реальности начинаешь думать, как сделать лучше — и не всегда получается все эффективно сократить, есть куча нюансов, о которых знаешь только при глубоком понимании предметной области.
Оригинальная статья мне понравилась намного больше. Помимо того что увольнение Рика явно было правильным решением независимо от того кто виноват в том что так получилось, там еще и внятно расписывалась довольно распространенная ошибка и говорилось «ребята, так делать не надо, это плохая практика». А эта статья — это какое-то унылое нытье о том кто больше виноват, не предлагающее ни практических рекомендаций как не доводить до подобных ситуаций и как их исправлять, ни практического опыта «сделали X стало плохо, сделали Y стало хорошо».
Был в ситуации Рика. К счастью, менеджмент быстро вывел меня на удаленку в режим «только обучай и никого не трогай». Иногда подключал к проектам в режиме «спаси мир за 2 дня до дедлайна». Это работало. я получал хорошие деньги и свободный график, а работодатель — высокие компетенции и командную работу, хоть и от разных людей.

Кирилл, Никита, если вы это читаете — спасибо :)
Наблюдал несколько со стороны подобную ситуацию.

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

Единственный выход — уход от взаимных обвинений и принятие каждой стороной на себя своей доли ответственности за ситуацию. Каждое возмущение на подобии: «А что это он, редиска, делает XXX» — нужно превратить в вопрос: «А каким своим поведением я даю понять, что со мной можно так себя вести?»

Прочитал исходную статью. Все они хороши, и Рик и компания. Но компания по-моему все-таки более неправа. Эту статью считаю правильной, но несколько однобокой.


Rick didn’t need anything anybody else built. He built everything he needed from scratch
Bugs were popping up in old tools he’d built
to replace about 150,000 lines of incomprehensible mess

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


You will never be able to understand any of what I’ve created. I am Albert F***ing Einstein and you are all monkeys scrabbling in the dirt.

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


Everyone was waiting for Rick

Это вопрос к компании. Почему вдруг все задачи стали зависеть от работы одного человека? Почему другие не могли сделать свое временное решение? Нет, давайте будем ждать. В остальном, в этой статье все написано.


He reverted code changes, including tested bug fixes by other developers.
He asserted that he wouldn’t be held accountable for supporting other people’s work.

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


We obtained an agreement from the project sponsor to shut off some edge-case functionality.

А до этого нельзя было договориться о его отмене? Рик пусть делает, мы подождем. А как самим понадобилось, так сразу "а может не будем делать?".
Если разработчику пришла задача, подразумевается, что ее обсудили и решили что она нужна. Поэтому глупо предъявлять претензии, что он не догадался, что не нужна.


He refused to take time off or allow any work to be delegated.

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


He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools.

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


First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick.

У них похоже такие разработчики, что им проще спросить и ждать ответа, а не разобраться самому, а виноват почему-то Рик.

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

UFO just landed and posted this here

Тесты это правильно, кто ж спорит. Не было у нас там тестов, и времени на них не было. global $db и все такое, по сотне задач на разработчике. Хотя я сам тогда в тестировании не особо разбирался. Потом правда тестировщики появились, вручную проверяли.


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

В таком случае будет мысль «ну блин, кто опять лазил в моих тестах»? :-)
Да дело не в этом!
Главное другое. Такая ситуация сплошь и рядом там где начальник озабочен только прибылью но совершенно не разбирается в специфике выпускаемого его фирмой продукта!
ДА как не смешно но это так!

Господа, имеет смысл почитать комментарии к оригинальной статье. Там автор довольно подробно отвечает на некоторые из них. С его слов своими словами:


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

То есть у человека есть опыт но он не придумал ничего лучшего как уволить… Это говорит не в пользу автора
Если увольнение такого сотрудника — лучшее решение менеджмента, то что же тогда можно считать плохим решением?
Ну вот кто минусует и почему? Всё правильно сказал.
Нет никакого смысла держать человека, из-за которого страдают другие. Помочь? Да, конечно. Но рассуждения, оправдывающие «Рика», про какой-то вакуум. У каждого есть свои интересы, семья, друзья и т.д. Речь в оригинальной статья идёт об огромном промежутке времени! Это и есть самое важное. Результат надежд и ожиданий большого коллектива. Давайте еще 5 лет подождем пока «Рик» сможет? А не может ли «Рик» сделать усилие на собой, мы ему поможем и поддержим, пусть он станет частью команды. Или все должны жить в мире «Рика».

Хотелось бы почитать статью написанную «Риком», о том, что он думает. Это было бы справедливо.
Я менеджер и у меня есть Рок-звезда.

В прошлом я более 10 лет был разработчиком. По поводу статьи:
Я в шоке от того, что все начали защищать Рика! Ребята, почему вы смотрите про переработки, которые он сам взвалил на себя (кстати, эта особенность большинства Рок звезд), но игнорируете результат, который добилась компания:
  • Пять лет работы (и результата нет), заменила на 1 год и готовый продукт. За пять лет на одного человека денег ушло куда больше, чем на команду 3-5 человек. Плюс ко всему через год продукт уже продается и начинает окупать вложения
  • От всего того, что сделал Рик, они оставили 10% действительно нужного кода. Все остальное судя по всему Рик закладывал на будущее, пытаясь предвидеть все и вся, хотя как правило оно так никогда и не требуется
  • Они уменьшили риски, упростили код, упростили техподдержку, ввели тестирование, в проект легко вводить новых разработчиков, улучшилась обстановка в компании


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

Теперь по поводу звезды в нашей компании:
Боюсь, что скоро нас может ждать тоже самое. Рок звезда делает очень важный модуль. Он молодец, реальный спец, хорошо и качественно пишет, мы его очень ценим. НО! Он НИКОГО даже близко не подпускает к своему коду. Как Рик в этой статье. Для нас это большие риски, т.к. проект растет. Мы регулярно предлагаем ему в помощь специалиста. На все попытки жутко раздражается и ревнует. Постепенно берет на себя больше работы. Я думаю, что Рок звезды прутся, когда от них все зависит.

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

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

Единственно, в чем мне удалось переучить Звезду за годы работы: это делать ровно то, что требуется для решения задачи. Раньше он как Рик писал кучу кода, абстракций, пытаясь предвидеть будущие требования. Спустя 5 лет он сам лично пришел ко мне и поблагодарил меня за это. Теперь он закрывает задачи очень быстро.

Но все равно, если у вас есть Рок звезда – будьте осторожны. К ним требуется особый подход.
Объясните, пожалуйста, что значит берет больше работы? Как это выглядит? Вы предлагаете ему работу, а он не отказывается?
Помимо наших задач, которые требуется для проекта, он находит интересные для СЕБЯ задачи и активно продвигает их. Хорошо, когда они действительно интересны и нам и ему. Тогда он с огромным энтузиазмом их решает, и даже во вне рабочее время, хотя мы его абсолютно об этом не просим. Но если то, что ему хочется делать — не является первоочередной задачей для бизнеса и приходится его оттормаживать, то начинается беда. Он становится невыносим.

Я лично, хочу уточнить один момент:


Раньше он как Рик писал кучу кода, абстракций, пытаясь предвидеть будущие требования.

Он когда-нибудь оказывался прав?


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

Конечно иногда оказывался прав.
Понятно дело, что всегда надо искать золотую середину. Если вы чувствуете что, следующий шаг неизбежен, то можно и заложить определенный запас в архитектуру. Но это уже больше опыт/чутье.
Но часто было так, что ему приходилось обратно выпиливать то, что он напридумывал, т.к. оно мешало активно развивать продукт. Теперь он не любить, когда в проекте валяется ненужный код, который ко всему еще приходится рефакторить при изменении требований. Чему я очень рад.

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

Звучит просто как переусложненный код без достаточной гибкости.

Звучит просто как переусложненный код без достаточной гибкости.
Значит что он пытался угадать какими будут бизнес требования через 5 лет — и сделал это неправильно.

Практический подход к «заделу на будущее»: если вы точно знаете кто, когда и для чего вашу «гибкость» будет используете (ответ вполне может быть что и вы — но только, пожалуйста, не «может быть, если рак на горе свистнет», а «когда я займусь багом номер NNNNNN») — идёте и обсуждаете с ними вам «задел».

Если вы точно не знаете — нафиг заделы. Переписать потом будет проще, чем иметь в 10 раз больше года, 90% потенциальной функциональности которого не использует никто и никогда.
Согласен полностью
«Рок звезда делает очень важный модуль. Он молодец, реальный спец, хорошо и качественно пишет, мы его очень ценим. НО! Он НИКОГО даже близко не подпускает к своему коду. Как Рик в этой статье. Для нас это большие риски, т.к. проект растет. Мы регулярно предлагаем ему в помощь специалиста. На все попытки жутко раздражается и ревнует. Постепенно берет на себя больше работы. Я думаю, что Рок звезды прутся, когда от них все зависит.»
Не проблема, если с вашей стороны есть жестко фиксированный интерфейс, а он лишь пишет реализацию, не залезая в остальной проект. Тут главное правильно этот интерфейс составить, чтобы у него не было выбора кроме как пилить простые и понятные в случае чего стороннему разработчику функции
Зачем тогда рок-звезда, если работа происходит в таких жестких рамках? Хватит и оутсорсера.
чтобы у него не было выбора кроме как пилить простые и понятные в случае чего стороннему разработчику функции

Оскорбится и уйдёт, очевидно же.
>Я менеджер и у меня есть Рок-звезда.
У меня для вас плохие новости…
Рок звезда делает очень важный модуль. Он молодец, реальный спец, хорошо и качественно пишет, мы его очень ценим. НО! Он НИКОГО даже близко не подпускает к своему коду. Как Рик в этой статье. Для нас это большие риски, т.к. проект растет.


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

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


Просто этот специалист — явно overqualified для данной формы.
Автор исказил смысл первоначальной статьи.
Там Рик был таким изобретателем велосипедов и запутанного кода, любителя копи-пасты.
Такие любители «поработать» совсем не редкость.
Нахватают проектов и задач и говнокодют днями и ночами и вскоре превращаются в bottleneck.

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

Я больше согласен с первоначальной статьёй — виноват менеджмент, в том, что не взял этого
«Эйнштейна» под контроль.

Хм, тогда в чем его рок-звездность? По мне так умение писать код быстро и качественно входить в понятие рок-звезды.
Видимо это была его самооценка и оценка его тогдашнего менеджера.
Судя по первоначальной статье, чувак просто загрёб всё под себя.
А писал быстро, много и не качественно, и всё с нуля, всё больше зарываясь во второстепенные детали.
По коментариям автора — вначале его код был не плох, видимо те самые 10%,
а потом гений зарылся.

У автора статьи — та же болезнь. Он считает что остальныеколлеги безграмотные, что менеджмент не умеет и т.д.
Что все кругом в такой ситуации виноваты — все, кроме него самого.

поддержу, складывается впечатление, что автор (не переводчик:) ) сам из таких вот обиженных Риков.
Глупая статья по факту. В стиле капитана очевидность.

1. Принцип 'У нас нет незаменимых' весьма неприятно работает, если нет внятной документации в объеме хотя бы 90-95% по процессам. И вообще нет внятной организации процессов.
Иначе компанию ждем сюрприз и маленький гешефт™ )

2. Уже все описано в той же книге 'Проект Феникс' — Рик это тот же Брент, только со звездной болезнью.
Если процессы зациклены на таком 'бутылочном горлышке' — это вопрос к адекватности менеджмента, не более того.
В статья забавная, но мне показалась что она описывает не высокомерного, зазнавшегося разраба, а не компетентных менеджеров/управленцев компании(что бывает чаще чем в других профессиях).
Когда в команде есть хотя бы один(больше лучше) знатный разраб это хорошо как и для команды так и для бизнеса. Даже при условии что менее гениальным сотрудником с ним/и будет сложно. Люди ленивы, тщеславны и жадны.
В статье нет главного — про деньги.
Есть тезис, что им стало лучше, но что оно такое в этом случае «лучше» так и раскрыто.
Дело не в деньгах.

Рок звезды нужны в стартапах, нужны на этапе создания мега продуктов.

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

Прочитал я оригинальную статью, эту и комментарии. Вот все тут пишут, да и в этой статье все подано так, как будто Рик бедный такой и несчастный, все его нагружали. Вы правда верите, что человек, который умеет планировать, расставлять приоритеты, будет брать на себя больше, чем сможет осилить? Нет конечно, скажете вы, на него это повесили менеджеры. У нас что рабство в ИТ? Дали на месяц работы, сказали сделать за пару дней и мы покорно делаем? Нормальный разработчик сам оценивает задачу и озвучивает сроки. Если такие сроки руководство не устраивают, всегда можно сменить работу. Или у нас в ИТ так сложно ее найти, что стоит держаться за место, где тебя заставляют работать по 12 часов в сутки 7 дней в неделю? Не думаю. Любой разработчик с таким опытом, как у Рика, сможет найти работу за пару недель, а если все происходит ещё и в Долине, то наверняка и быстрее. Рик сам выбрал себе такой режим, вполне возможно, ему действительно хотелось чувствовать себя звездой и быть незаменимым в коллективе. Достаточно прочитать, что он не давал никому править свой код. Код, который ты написал в компании — это собственность компании, за это и платят деньги. И это вроде как должно быть понятно с самого начала. А в конце так и вообще показал признаки мании величия, назвав себя Эйнштейном.
К автору оригинальной статьи также есть несколько вопросов. Почему, когда Рик не являлся на планерки, это не сильно волновало руководство? Чем этот человек там занимался, за что ему платили деньги? Странно, что руководство этот вопрос не беспокоил. Причём продолжалось это достаточно долго. Наводит на мысли, что автор оригинальной статьи либо исказил реальные факты, либо недосказал что-то, либо уровень разгильдяйства в компании был очень высок.
Я думаю, что тут проблемы были с обоих сторон. Проблема Рика в его звездности и желании делать все самому, есть такие перфекционисты, для которых важна чистота кода, а не его расширяемость, поддерживаемость и те задачи, которые он должен решать. Проблема руководства в том, что они не поняли сразу, к чему такой подход может привести и спускали все на тормоза, даже когда "зелёные метрики становились желтыми..." и таа далее. А в итоге удобнее всего было объявить Рика виновным во всех проблемах.

Минусуют видимо такие же Рики, которых «злые менеджеры» загружают. Каждый человек сам хозяин своей жизни. А если самоцель — сделать себя обиженным жизнью, тогда да, стоит придерживаться стратегии, что все вокруг плохие, нагружают меня и я ничего с этим поделать не могу.
Я хоть и рик, но не минусовал. Вообще в чем то вы правы, в любом конфликте если копнуть можно обнаружить что виноваты обе стороны. Даже в том случае что один что-то сделал не так, а вторая сторона закрывала глаза и игнорировала нарастающую проблему.
Ну не все хорошие специалисты звездятся. Такие вещи как правило тянутся из психических проблем и когда человек получает возможность их решить самоутверждение, то выходит вот так. Либо просто низкий общий интеллект, низкое чувство восприятия общества, людей, низкая эмпатия при хороших навыках всего в одном.
Йеп, автор статьи уже в самом начале в принципе все правильно уточнил.
В компании построили схему когда никто толком не работает потому что косяки можно спихнуть на местного вундеркинда и как только его уволили всем пришлось наконец-то перестать тупить.

У меня противоположная история, но тоже поучительная. Не поленитесь — прочтите до конца.

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

Но однажды произошел неприятный инцидент. При обновлении техники в бухгалтерии (а это ещё тот геморрой) один из закупленных ПК оказался с браком. Что-то было не в порядке с чипом, и компьютер самопроизвольно выключался через пару часов. Я, естественно, как полагается, оформил замену техники по гарантии. Технику поменяли, но на этот процесс ушло 2 недели. И все эти две недели тетки из бухгалтерии подымали «хай» — мол, как мы будем работать на такой технике, которая ломается. Короче, эти тетки протолкнули вопрос о моем наказании…

Наказал меня директор крайне жестко – не проиндексировал зарплату (мне и дворнику-алкоголику). Я долго жаловался, требовал пересмотреть наказание, но директор остался непреклонен. Я в итоге забил на это дело, так как работа все-таки нравилась мне.

Прошел год. Я усердно, как и прежде, работал. Пришла пора новой индексации зарплаты. И… мне индексируют зарплату на 2% (мне и дворнику-алкоголику).

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

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

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

Коллеги продолжают рассказывать. Через месяц после моего ухода отдел бухгалтерии протолкнул вопрос об обеспечении их отдела высокоскоростным интернетом. Я, кстати, этом вопрос всегда отклонял, т.к. во-первых, скоростной интернет нужен бухгалтерам, чтобы видео в «одноклассниках» смотреть, а во-вторых, нужно тянуть сеть через весь квартал (цена вопроса более 50 000 рублей).

С горем пополам, мои подчиненные провели сеть и, не разобравшись, почему так я сделал, объединили все подсети в одну. В результате все документы и базы бухгалтерии оказались в общем доступе в локальной сети организации. Ну, и через несколько месяцев все это дело «накрылось медным тазом» — кто-то или что-то удалило бухгалтерские базы и ряд документов.

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

Но это ещё не все. Через год после моего ухода в организацию пришла УБЭП с проверкой и не нашли ни одного документа на технику и софт… До сих пор не понимаю, как организация умудрилась потерять все оригиналы документов (были у директора в сейфе) и копии документов (были у меня в сейфе).

В срочном порядке был нанят ещё один сотрудник, который кое-как восстановил всю документацию и закупил лицензии. Уголовной ответственности удалось избежать. На все мероприятия было потрачено около 150 000 рублей.

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

И на этом моменте история не заканчивается. Директор дал указание удалить следы моего присутствия в организации. Новый сотрудник, занявший мое место, согласно этому указанию удалил весь софт с рабочей установки, который я писал в течение 5 лет. Как результат, рабочая установка стала работать через раз. Смешно? Смешно, то, что резервные копии до сих пор никто не делал.

После полугода «страданий» с рабочей установкой было решено заменить её на похожую (не новую), но с комплектом готового софта. Цена вопроса – чуть меньше 400 000 рублей.
И вот я сижу и обалдеваю от рассказа коллег. А они выдают последний решающий факт: за место меня в итоге работают 4 человека. Один занимается техникой, второй – документами, третий – софтом, а четвертый — начальник над этим тремя. У каждого зарплата как была у меня и больше… Все, финиш.

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

+ опасно вести дела с теми, у кого свое эго превыше всякого разума. Ибо только оно (это эго индюка) способно привести к результатам, описанным выше (не признаем свои ошибки любой ценой).
Но это ещё не все. Через год после моего ухода в организацию пришла УБЭП с проверкой и не нашли ни одного документа на технику и софт… До сих пор не понимаю, как организация умудрилась потерять все оригиналы документов (были у директора в сейфе) и копии документов (были у меня в сейфе).

Вы не думали, что они могут быть в доле. Более того, что все свои (госструктура)?

В срочном порядке был нанят ещё один сотрудник, который кое-как восстановил всю документацию и закупил лицензии. Уголовной ответственности удалось избежать. На все мероприятия было потрачено около 150 000 рублей.

Это не так уж и много. По крайней мере для Москвы.

Мораль тут такова, что в ГБУ весьма феодальный подход. Работал. Знаю отчасти изнутри, поэтому нисколько не жалею, что ушёл. У них же, с их слов, за воротами куча страждущих. :)
Как то раз прочитал ответ Линуса Торвальдуса, на вопрос почему в ядре не используется С++. Ответ начинался примерно так «You are full of bullsheet!!!».
Не знаю как там с С++ в ядре. Но работать с такими «звёздами» не хочется даже близко.
UFO just landed and posted this here
Ну если «Рик» подкованный специалист, то выполнять работу за троих, а потом идти просить повышение зарплаты хорошая тактика, наверное он просто не успел это сделать.
UFO just landed and posted this here
UFO just landed and posted this here
за три месяца вы предоставите результат чтоб можно было сказать «он незаменим»? как то не верю, три месяца как правило любой работник работет по полной на энутзиязме чтоб показать себя, да и заряд положительный от нового места, а потом работает как обычно.

Только на днях столкнулся с непрошибаемым мнением, что для вхождения в хайтек достаточно аккаунта на Lynda, Udemy или Tutsplus и одного месяца учёбы. При условии, что не ленивый, а ленивым в хайтеке делать нечего! :)


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

Хочется и свою лепту внести в комментариях к данной статьи. Я -«человек читающий», но зарегался, чтобы оставить комментарий к данному посту. ОЧЕНЬ МНОГО БУКВ, извините!
И у меня тоже история про вкалывание на голом энтузиазме. Но:
Для начала хочу рассказать немного (чуток) о себе: я — самоучка-интроверт. Экставертом являюсь только в подпитии)) Так вот… В недалеком 2007 (женат, есть дочка (а на данный момент: дочка и 2 пацана, еще через 2-3 недели пацанчика ждем)), работая водителем-экспедитором на своей газельке, попался мне диск с 3D Max. Стал его досконально изучать (благо учебник для чайников купил, ютуб тогда не смотрел, или его не было) Хорошо, что с детства любил такой предмет в школе, как «Черчение». Изучение мне далось легко. Через год начал вечерами рендерить сцены для местного челябинского завода. Оффициально на заводе не трудоустроен — только сделка. Заявок мало, потому продолжал работать оффициально водителем-экспедитором но уже не на своем авто (свою старенькую успешно продал)
Так вот. Устроиться куда то с умением рисовать и рендерить в максе до 2012 года я не мог. В Челябинске в те времена и вакансий таких то не было. Были интерьерщики, но я не из них.
И вот настал тот самый день, когда мне позвонили и предложили ту самую работу, о которой я мечтал на минимальную зарплату. Быстро ввели в курс дела и я начал выводить оборудование с фотографии в макс с последующим рендером. Управлялся быстро. Позже за обедом с учредителем компании мне дали понять, что моя ЗП может возрасти в N раз, если увеличишь объемы или как то покажешь себя. А это N раз как раз бы и не помешало, так как на тот момент у меня 2 детей (мальчик и девочка) Условия простые: вкалываешь как ишак. Не вопрос- начал вкалывать, потому как самому интересно. После второго месяца ЗП выросла. Думаю, ок, но нужно еще что-то сделать. В этот момент увольняется веб-мастер (кстати, один из моих друзей с той организации) Он то меня и сподвигнул к изучению модикс эво. Через месяц, после обучения в пространстве интернета и ютуб, я подошел к руководству с решением изменить сайт. Странно, но добро дали. <!___сайт изменили, всем понравилось, прошел 1 год___> После этого выставки, директы и т.д.
Из дизайнера 3d--->заместителя руководителя отдела рекламы и маркетинга
И вот тут то началось:
Я превратился в машину, которая умеет все… 3D — ко мне, коммерческое (в пдф) — ко мне, правки на сайте -ко мне, новую конструкцию на оборудовании, чтобы красиво смотрелось — опять ко мне… Это еще не весь список))) Короче, у меня нервы сдали… Напившись, просто не вышел на след. день. Телефон ломило от звонков… Не удержался — взял. В итоге, дали неделю отпуска на Черном море за счет компании. Если честно — помогло. Новые силы появились.Но для себя решил, что не буду больше ишачить. ЗП после отпуска подняли. Все таки договорился нанять 3д-дизайнера, графического дизайнера и веб-мастера.
Но то что я «сгорел на работе» мне уже было понятно. Энтузиазм пропал, новых идей нет. Продержался еще 1 год, после чего уволился в начале 2015 г. Не хотели отпускать, но и двухнедельной отработки не стали требовать. Отпустили, зная, что я нашел себе применение…
Через полгода решил навестить своих бывших коллег. Организация на грани банкротсва. ЗП задерживают. Меня, в шутку, обвинили в плачевном состоянии компании. Еще через полгода компания не то что обанкротилась — ее просто не стало… За 1 или 2 дня… Кризис или не дальновидное решение руководства — не понятно. Для меня это был шок. Столько сил вложил, а в итоге ноль…
P.S.: К чему это я? Может навеяло, решил поделиться.
P.P.S.: Многие бывшие сотрудники открыли ООО, конкурируя между собой

Ок фирму обанкротили))) Шутка, уверен что их банкротство связано с массой причин. А сейчас чем заняты если не сектрет?
Когда то в детстве очень сильно увлекался черчением… Наверное, поэтому, быстро изучил 3д макс. Научился переводить чертежи в Компас 3д. Наверное, поэтому в данный момент работаю в этой сфере, как изготовление нестандартного оборудования на гидравлике. Под словом «нестандарт» подразумевается то — что я могу сделать, а под словом «стандарт» — то, что уже сделали в китае и стоит очень дешево… Много букв… Работаю на себя…
Столько сил вложил, а в итоге ноль…

Как же ноль? Неужели вернулись к работе водителем-экспедитором?

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

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

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

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

в большинстве проблема из-за:
— непонимание руководством процесса разработки программного продукта
— нежелание руководства слушать разработчиков о процессе разработки, потому что они руководство, а ты какой-то там рабочий

Так бывает, все надо успеть за месяц, в полном объеме, чтобы не возиться пол-года, так сказать сократить расходы в х6 раз =)… а потом через 1.5 месяца слышишь: «Твой код — говно» ))

Articles