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

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

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

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 компаний!

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Рефакторить надо.

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


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


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

Вы точно ещё не спите?
image

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

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

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

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

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

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

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

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

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

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

У меня есть подобный знакомый — мешает в коде 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 смены. Даже сторож имеет сутки через трое без умственной нагрузки, лежа на диване.
Если бы в ИТ все соблюдали трудовое законодательство то разработчики работали бы дня три в неделю. Как кстати один чувак в Гугле и делает — три дня работает остальное время путешествует.
Там все виноваты, но Рик может отвечать только за себя. Этот процесс был не случаен, и, наверняка, под давлением руководства. Да, какой-нибудь супергерой смог бы разрулить ситуацию как офигенный менеджер, но этого нельзя требовать от Рика, он на это не подписывался, и, строго говоря, не имел достаточного умения и влияния.
Очень часто хорошие и ответственные специалисты не могут себя защитить в этом плане. Впахивают пока не сломаются.
Полностью согласен с выводами автора статьи.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
Но подождите, ведь в первую очередь менеджмент виноват в том, что не было код-ревью и документации. А может и Рик изначально не хотел давать свой код на ревью, считал это унизительным. Многое осталось за кадром…
По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.

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

Или над уровнем джуниоров :-).
Если бы я решал, кого присылает наш 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. Тестирование в общем

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

Ребята там речь о ГОДАХ!
Да, бывает что несмотря на все увещевания программистов — продолжают наваливать новое, что только костылями прилепить удается и баги которые возникают из за непродуманной архитектуры «быстрей-быстрей», вместо того чтобы остановиться и переделать по нормальному. И так до тех пор пока либо это нагромождение костылей не развалится, либо до момента когда уже любое изменение обходится в недели вместо часов, либо до момента когда любое изменение добавляет багов больше чем исправляет, либо… Ну вы поняли.
Можно найти ответ автора в дискуссии, что качество кода начало ухудшаться с определенного времени. То есть, когда он перестал справляться, начались хаки и копипаста.
Я все же позволю себе усомниться что качество когда было низкое. Потому что автор как раз как бы саркастически пишет: «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 часов в день каждый день.
Ну и если бы он был качественный, его бы не пришлось переписывать из-за отсутствия документации.

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

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

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

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

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

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

Это не работает если тебе приносит удовольствие то что ты делаешь… В любой профессии такие есть !

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

Ничего из описанного не может оправдать фразы на совещаниях вроде «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 часов
Я не очень люблю придираться к словам, но…
Спасаю положение: 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 года починки багов в большом проекте большой компании.

Я сталкивался с людьми, которые не понимали четкий стройный код написанный в функциональном стиле на javaslang. Хотя там все очень понятно, стройно и лаконично.
Вместо этого они предпочитали адову императивщину с кучей ифов.

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

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

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

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


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

Возможно вы правы. А возможно чувак просто влез в желтую и красную зоны. — вот здесь подробнее. habrahabr.ru/company/jugru/blog/338732

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

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

Толсто.


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

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

Я сталкивался с людьми, которые не понимали четкий стройный код написанный в функциональном стиле на javaslang. Хотя там все очень понятно, стройно и лаконично.
Вместо этого они предпочитали адову императивщину с кучей ифов.

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

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

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

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

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


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

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

Проблема в том, что два "Эйнштейна" в команда сожрут друг друга. Ибо "должен остаться только один".

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

Если есть работа и на неё отведена штатная единица — значит она должна эту работу выполнять в отведённые сроки.

Обычно те, кто определяют число этих «штатных единиц», нихрена не понимают ни в работе, ни в нужном числе человек для её выполнения, лишь потому, что невозможно разбираться во всём. Так что подгонка числа работников после определения или каких-либо изменений — вполне нормальная штука. А то поставят человека, потом навесят на него в два раза больше обязанностей и удивляются, что он не справляется и требует помощника.
смысл ясен.
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 года до сих пор жива-здорова.
Ищите способ уйти. Особенно, если руководство не интересуется реальным положением дел.
Таким манагерам еще расти и расти, а вы себе можете не плохо попортить дальнейшую жизнь.
Незаменимых людей не бывает. У меня тоже была иллюзия, что «на дедах вся армия держится»
тут законных оснований нет, что бы уйти)) срок контракта еще не вышел)
а проблемы уже начинаются

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

в кратце — не прокатывает у нас
Я глубоко убежден в том, что таких «рок звезд» выращивает сама корпоративная культура. Особенно ярко такие звезды сияют в таком классическом энтерпрайзе, в таких коллективах большинство людей держатся за свои обжитые позиции и пытаются снять с себя побольше ответственности при этом скрывая подальше от окружающих свои компетенции или таланты.
Машина построена таким образом, что каждый отвечает исключительно за свой небольшой кусочек и если в какой-то из частей системы (имею в виду предприятие в глобальном смысле) произошел сбой узнать где именно и почему это произошло порой очень не просто.
Некоторые люди же совершенно не могут работать в таком стиле и они рано или поздно либо увольняются либо пытаются возглавить этот бардак. Обычно такие люди появляются в больших проектах по оптимизации/автоматизации/внедрению новых бинзнес процессов и начинают постепенно скапливать знания, которые по хорошему доступны любому из участников процесса — просто никто не хочет заглянуть дальше своего носа. Да, знания оседают в их головах и копятся годами и да — они не переносятся на бумагу в виде документации по двум причинам:
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.
Вы просто поймите правильно. Я же говорю не о том, что человек должен ходить в костюме с галстуком и свеженькой прической каждую неделю.
Это крайность.
Но он не должен там… вонять. Его одежда, руки итп — должна быть чистой. Он не должен эпатировать окружающих своим поведением и внешним видом. Это же вполне нормальные требования. Если это не соблюдено — то мне абсолютно пофиг сколько там чего такой человек знает. Ни я ни моя команда с ним работать не сможет — а это сводит на нет всю пользу от его квалификации.
Ты примешь на работу человека, которой аккуратен, опрятен и вменяем, но при этом в 15 раз хуже по квалификации неопрятного или неаккуратного?

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

У меня на позапрошлой работе был случай, когда мы с тимлидом не взяли чувака только потому, что от него нереально пахло табаком на собеседовании, при том, что человек был весьма грамотен. Причина та же — либо мы не берем одного _возможно_ хорошего специалиста (ведь еще непонятно, как он будет работать), либо _возможно_ теряем уже гарантированно хороших людей.

она прогорит и очень быстро

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

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

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

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

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

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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


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

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


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

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

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


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

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