Комментарии 439
А потом они удивились что я ушел
Сейчас я все еще готов предлагать себя за те деньги, что мне платят, но:
— все теперь документировано
— просто так я не перерабатываю
— работаю в том темпе, который удобен мне. И пока все задачи решаются руководство это устраивает
И к людям нельзя так относиться, а потом еще писать восторженные статьи.
PS: Да, есть неумные работодатели, но это отдельный вопрос как оне такими стали.
Они жаждут лишь того, чтобы ты работал побольше и требовал поменьше)))
Нифига!
Многие из ещё требуют, что-бы задание — делалось строго так, как они хотят, и ни шага в сторону!!!
Многие из ещё требуют, что-бы задание — делалось строго так, как они хотят, и ни шага в сторону!!!Если бы они этого хотели — жизнь была бы сказкой.
В большинстве случаев заказчики сами не знают чего хотят — и это нормально. Ненормально — пытаться удовлетворять все их «хотелки» и надеяться, что за это вас «погладят по головке».
Которое не только (а иногда и не столько) требует исполнения чего-то — но и хочет исполнения этого вполне определённым образом.
«Не смей делать этого вот так! Не смей ничего трогать! Только так, как я сказал!!!»
«Никакого С++! Только глобальные переменные и читстый Си! И никаких enum'ов, struct'ов и прочих заморочек!!!»
Но в команде завелся супер-герой, который решил сам спасти мир до конца не видя картины и не имея достаточно опыта в доведении продукта до продакшна (делегирование — нет не слышал).
Естественно единственный способ — это дать возможность команде начать работать, и попрощаться с суперзвездой.
Естественно единственный способ — это дать возможность команде начать работать, и попрощаться с суперзвездой.
Самый взаимовыгодный вариант — это перевести «суперзвезду» на другой проект, где первое время он будет пилить MVP водиночку. А потом этот новый проект, в зависимости от успеха MVP, либо передадут команде разработчиков, либо закроют.
Конечно, передавать проект «суперзвезды» команде нужно намного раньше, чем зашевелились менеджеры Рика.
Именно поэтому стартапы обычно ищут на работу молодых, которые еще не приняли Вашу точку зрения и готовы вкалывать в том темпе, который нужен руководству.
Опытному, зрелому специалисту, нужна такая же опытная компания…
По мне, внушать что-то компаниям бесполезно, любой сотрудник = ресурс. Поэтому предупреждающего поведения для таких ситуаций предложу 2 варианта:
1. Воспринимать работу как
2. Тянуть компанию, но периодически честно и хладнокровно (но без сарказма и вызова) напоминать об этом менеджменту. Повторюсь, не эмоционально, а фактами — обученные люди, закрытые сложные ЧУЖИЕ таски, решения в критические моменты.
это трудно для чуваков, которые получают фан от исключительности знаний и опыта— вот это прям точно подмечено :(
По мне, внушать что-то компаниям бесполезно, любой сотрудник = ресурс.
А в чем проблема? Да, сотрудник — это ресурс. Но это означает, что не стоит о нем заботится? Наоборот, как раз стоит.
His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.Ну а то, что акцент в статье сделан на личности Гения, а не на управленческих просчетах, можно списать не на предвзятость автора, а на то, что это было первопричиной проблем. Возможно, Гений был основателем стартапа, но не смог доверить развивать свое детище другим разработчикам
«Капитализм!» (с) к/ф Красная Жара
Не оправдывая подход, скажу только, что у бизнеса стратегия, как правило, еще дерьмовей.
Я увидел именно такую историю. Причём не только в статье, но и в реальной жизни.
Если ты хочешь прибавку к ЗП, приди к начальнику и скажи «что я должен ещё сделать для того, чтобы получить прибавку?»
Но человек увольняется (или его увольняют) и на его место берут другого, от которого ждут выполнения не только его основных обязанностей, но и дополнительных. А он и в основные еще какое то время будет вникать.
Вот и получается, что с человеком расстаются, а потом руководств говорит, что человек зажрался и ничего не успевал, а простой народ говорит, как при нем всё было хорошо — он всё успевал и всё знал.
Равносильно запросам кучи совершенно постороннего народа — тыжпрограммист, сделай!!!
Зарплата Рика тут вообще не при делах.
Ведь его именно что выгнали, а не он сам ушел — как это было бы если бы его «доили но не платили».
Вот согласен, задача Рика очевидна.
Умный человек ДОЛЖЕН понимать, что его могут попытаться заменить, и иметь вариант на этот случай.
Мне шеф сделал наезд, мол, бездельничаешь, когда работать по настоящему начнёшь? Ответил, мол, давайте обсудим условия.. Мой ответ не понравился, явно ожидались оправдания. Тут же предложил мне уволится. Тут же ответил согласием.
До сих пор (два года после) выслушиваю предложения вернутся. Где-то даже греет востребованность ))
"Если у вас случаются озарения по написанию хорошего кода, значит большую часть времени вы так себе программист"
я не лично кому-то, просто в голове мысль родилась
Если вы пишете хороший код только короткие промежутки времени (при озарениях), значит в остальное время программируете вы не очень хорошо
по-моему, все вполне разумно
Иногда есть проблемы которые с наскока не решить, например у меня было два таких случая — в первом я месяц бился над решением задачи и в итоге когда уже совсем отчаялся — тупо лег спать и увидел решение во сне, утром я сразу попробовал реализовать его и оно как не странно сработало.
Второй случай похож, в общем я неделю загонялся по одной таске но потом в офис пришел корпоратив, я наклюкался в дрова и набыдлокодил непонятно что — после на трезвую голову я понял что решил это, отрефакторил код, вылил на прод и уже как 3 года он работает.
Да типовые задачи должны решаться на раз, желательно подключением готовой и отлаженной профессионалами библиотеки, но иногда есть проблемы для которых нет готовых решений, вот тут и надо немного удачи и вдохновения и тонны тяжелого труда.
Это не тупо.
Во сне мозг напрямую подключается к коллективному бессознательному.
А обычно схожую задачу в мире кто-то решал, и решение есть,надо только его выудить.
Только надо мозг настроить на это выуживание. Обычно он настраивается путем усиленного обдумывания проблемы. Некоторые думают до упора,но я думаю до тупика, а потом спать ложусь. Обычно утром решение приходит,гениальное по своей простоте обычно.
Само собой, это не "гениальность" реципиента, хотя для непосвященного и может так выглядеть. Типа,утром МЕНЯ озарило.. Обычный хуман-интерфейс..
Технология. В фольклере получившая наименование "утро вечера мудренее" .
Есть проблема в работе на износ, это вредно для здоровья и в дальней перспективе это ведет к плохим последствиям. Нужно уметь думать об этом.
Вина есть однозначно! Человек не хочет делегировать задачи другим, под предлогом что они не сделают её так хорошо как он. Неужели в проекте все задачи были мегасложными? Нет, но способ работы через костыли делал делегирование почти невозможным. Плюс самомнение, что если не сделаю всё сам, то будет плохой код. К тому же насколько я понял, изначально Рику предложили продолжить работать в команде по созданию проекта с нуля — но по правилам, но его вариант быть не звездой, а винтиком — не устроил и он взорвался. Однозначно проблема в Рике и менеджерах которые допустили развитие такого сценария.
Если тебя не заставляют ОТВЕЧАТЬ ща чужой код, да пусть пишут,что хотят..
Но обычно эти манагеры же говорят "вот ты технически грамотный, проверь за ними, а если чо, ты же проверял, и отвечать будешь". А ЛЮБОМУ технарю проще сделать или переделать самому, чем проверять за другим.
У Рика и фирмы — разные интересы.
У Рика — реализовать идею, добиться чтобы работала невероятно сложная альфа-версия.
У фирмы — получить и альфу и бету и релиз. И релиз — да, да.
У меня есть подобный знакомый — мешает в коде 100500 библиотек и парадигм. Оно работает, он удовлетворен, но поддерживать это говно не реально. Сам он уже не хочет, не интересно. Ну а другим проще с нуля переделать
Но практически сразу, как наш «Рик» закончил проект и потерял к нему интерес, через 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, сотрудник в аналогичной ситуации получал минимум полдня отгула.
Правила менеджмента везде одинаковые. Если менеджер не тупой, он должен понять что и сколько времени занимает и уточнить у специалиста, поскольку он не разбирается в предметной области и вроде как не может дать валидной оценки.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.
А не должно напрягать. Давать ревьювить свой код джунам полезно во всех отношениях — они учатся на хороших примерах, а если не можешь объяснить джуну, зачем ты сделал это именно так — это повод задуматься над уровнем собственного понимания дао программирования.
Если бы я решал, кого присылает наш HR отдел нам в работнички…
На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
С таким отношением слона не продашь) Надо искать сильные стороны в людях и давать им соответствующую работу. Кто-то любит сложные задачи, а кого-то не напрягает в режиме 8/5 рисовать DAO. Или писать документацию. Или тесты. Или скрипты для деплоймента.
То, что вы описывается годится для рутины в каком нибудь отделении банка где последние 20 лет правят какой нибудь их внутренний опердень и звезд с неба не хватают.
Если джун именно делает ревью кода сеньора: человек пытается профессионально оценить и дать отклик о работе другого человека, но квалификация не дает этого вроде как сделать. Думаю, что это может напрягать.
Как по мне — пусть код смотрят в команде все кто хотят и обсуждают как хотят, это хорошо — кто-то чему-то научится, кто-то даст качественный отклик и ты сам научишься. Но ревью должен делать кто-то по уровню сопоставимый с тем, кто код писал. Потому что если человек будет заметно слабее, он некоторых моментов может не понять и общее отношение будет «как-то все мудрено и можно сделать проще», но пройдет несколько лет и человек сам будет писать так же — потому что так будет эффективнее и качественнее.
Хорошо написаный код должен быть доступен даже джуниору
да, но не ценой его читаемости миддлами. Джун может не знать, как работают некоторые редкоиспользуемые методы/классы языка, но лучше пусть джун посмотрит в документации, нежели в продакшене будут простые самодельные велосипеды на сотни лишних строк.
Если, скажем, джун не знает какую-то фичу языка, ей теперь не пользоваться, что ли?
Вот, я уверен, куча людей не знает, что в python есть оператор для перемножения матриц. Можно ли его использовать?
Потому что если человек будет заметно слабее, он некоторых моментов может не понять и общее отношение будет «как-то все мудрено и можно сделать проще», но пройдет несколько лет и человек сам будет писать так же — потому что так будет эффективнее и качественнее.
По моему опыту, как раз наоборот — чем опытнее программист, тем проще его код.
Не во всех.
Иногда набирают ТАКИХ идиотов, что им обясняй,нет, толку нет.
Был чувак,присылает довольно примитивный расчёт в экселе. Проверил, указал ошибки. Присилает ревью, указанные ошибки исправленны, НО,сделаны новые там, где И ДО ЭТОГО ВСЁ ОК БЫЛО.
Т.е.мало отфиксить ошибки, надо ЗАНОВО весь проект проверить,потому что ошибка может вылезти там, где раньше всё было ок.
В итоге перевёл его в режим "принеси, подай, никому не мешай", раз уж уволить не мог. И тут ПРАЗДНИК: пишет заявление сам. Я потираю руки, наконец, на эту ставку нормального кого возьмём..
Через месяц просится назад, шеф его принимает, мол, он со спецификой знаком...
Я поддерживаю вариант, когда ревьювит человек с опытом и в теме. И он же подтверждает мердж. Тогда все уходит в 90% без сучка без задоринки, а если возникают вопросы — то по делу и действительно можно чему-то научиться самому.
SelectorInfo* x = new SelectorInfo[size]();
а не
SelectorInfo* x = new SelectorInfo[size];
то это нормально.
Ненормально — когда он после этого начинает требовать добавлять в код комментарии и пояснения.
P.S. А FoxCanFly, скорее всего, имеет в виду, что использовать «голый» new сегодня — не комильфо. Нужно использовать всякие unique_ptr и фабрики аллокаторов. Что, в принципе, верно. Но тут есть ньюанс: C++ — это не Java, тут всякие варианты возможны. В конце-концов у вас может FFI подобного требовать… Однако же инициализацию из-за этого опускать не стоит…
По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.
Вот вообще не парит, когда джун ревьюит мой код.
Во-первых он на этом учится,
во-вторых я прекрасно знаю, что я могу просмотреть в том числе простейшую опечатку, внимательный джун с высокой долей вероятности это выловит.
В-третьх "пока объяснял сам понял" — весьма эффективная методика.
Получается, ни ревью полноценного, ни обучения, на которое требуется время.
Или вы путаете ревью с изучением кода?
Таким образом, джуниор должен принимать участие в ревью, но должен быть и кто-то опытный в составе.
Все зависит от того, какая политика у компании относительно джуниоров. Я могу и ошибаться, но это может быть не так уж и сложно делать ревью в паре опытный-молодняк в качестве ревьюеров. Теоретически, такие ревью позволят быстрее взрастить джуниора. Даже если такая пара будет ревьюить джуниоровский код, то обучаемый джуниор запомнит ошибки именно своего уровня и будет больше обращать на это внимание вместо того, чтобы получить реджекты на собственном ревью на тех же граблях.
А когда времени в обрез то в следующем порядке забивается на:
- Юнит тесты
- Ревью
- Дизайн
- Составление требований
- Тестирование в общем
И в такой обстановке, нормального специалиста из джуниора вырастить нельзя. Да и из нормальных тоже можно сделать быдлокодеров при длительном замачивании.
У владельцев компании задача вырастить из джуниоров специалистов — так за это надо дополнительно платить. У меня задача сделать в срок и качественно свои таски (за что мне платят деньги) и пойти домой вовремя.
Все правильно, время на ревью должно учитываться во времени разработки, собственно из-за того, что на ревью не выделяется положенное время, на него начинают забивать ибо своих дел полно.
Это уже не ревью. Это — обучение. А его пытаются втиснуть в ревью и таким образом не доплачивать. Одна из многих уловок хитрого менеджмента по высасыванию соков из людей. Нафик-нафик. Забивайте отдельно время на обучение и отдельно на ревью. Это будет честно.
Так время на ревью отличается принципиально, когда его делает подготовленный человек и недостаточно квалифицированный, которому надо разжевывать, объяснять и доказывать.
Представьте, что ваш код через десять лет будет дебажить кто-то, кто с вами даже не знаком, а вы уже давно в другой компании.
Код, который будет непонятен «человеку с улицы» без получаса разжёвывания, объяснения и доказывания тем, кого больше нет — это жёсткая подлянка для компании. Совершенно нормально, если тимлид запретит мержить такой код.
сделать в срок и качественно свои таски (за что мне платят деньги)
Это заблуждение, которое часто используют для манипулации.
Деньги наемным работникам платят за отработанное время, а не за решение проблем.
Обязанность простого программиста — добросовестно 8 часов в день делать то, что ему скажет лид
Обязанность лида — добросовестно 8 часов в день исполнять свои обязанности и коммуницировать результаты и проблемы наверх.
Если вам не оплачивают переработки под любым предлогом (ты сам виноват, компании надо) — меняйте работу
Если оплачиваемые переработки случаются регулярно — нужно ставить вопрос о качестве менеджмента или менять работу
Хронически перерабатывать могут только те, чьи доходы качественно зависят от результата: средне-высшний менеджмент и собственники бизнеса. Еще как вариант, владельцы пакетов акций компании или за обещанную крупную премию в случае успешной сдачи проекта.
Вполне себе ревью. Я не даром третий пункт написал. Джун непонятное должен спрашивать. А ты пока объясняешь сам себя и перепроверишь. Т.е. этакий IoC только для мозгов разработчика, а не среды выполнения.
Нет, если после этого ещё опытный товарищ посмотреть — будет только лучше, но и считать это бесполезной времязатратой — глупость полная.
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
А почему ты считаешь, что твоя "головная боль" и твоё мнение о расходе собственного рабочего времени должны идти вразрез мнению твоего руководителя? Может быть, ты рок-звезда? По-моему, если босс решил, что для всей команды выгоднее, чтобы джуны смотрели твои пулл-реквесты, а ты бы им разъяснял, то будь добр — показывай и разъясняй. Или ищи другую команду.
Дружище, с таким подходом, мол я начальник — ты дурак, команда не работает.
И если я пишу код, то задача босса как раз создать мне комфортные условия. А если мне не комфортно — конечно, надо расставаться. «Сейчас везде нужны хорошие счетоводы». А вот боссы из серии «я начальник — ты дурак» востребованы разве в гос структурах и то там все занятно плотно.
Чёт заминусили. а реально не могут даже оценить работу.
Далёк от программирования, но встала задача сделать инвентаризацию на складе.
Для этого проще простого всё разложить по полочкам, а потом втупую пересчитать.
Понятно, что львиную долю времени занимает именно разложить по полочкам,считать это таблица умножения, ряды на столбцы.
Был бардак на складе, взялся за инвентаризацию, спрашивают, когда закончишь? Ну недели две надо ещё..
Не пойдёт, иди на фиг, так пересчитаем..
Прошло 3 года, ничего не пересчитано. Говорят, шеф приходил на склад месяца через три, посмотрел, что я успел сделать, и хотел предложить заняться складом. Правда, уже "уволил" меня )))
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
Ну и если бы он был качественный, его бы не пришлось переписывать из-за отсутствия документации.
Я все же позволю себе усомниться что качество когда было низкое.Вы вдруг выворачиваете так, будто я его в этом обвиняю.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
А я как раз работал с такими синьорами. Они (и их начальство) считают, что если код решает проблемы пользователей, то вообще без разницы, как он написан, лишь бы поскорее в продакшн. А рефакторят пусть джуны, которые всё равно пока не способны решать проблемы пользователей; так пусть хотя бы с кодом познакомятся таким образом.
(Что получается, когда джуны рефакторят код, который непонятно что делает и непонятно как работает, без тестов и без документации — деликатно умолчу.)
Реально сами себе ноги расстреляли, потом радостно их отрезали и сказали, что теперь гораздо лучше: и ходить никуда не надо и на ботинки деньги не уходят
Сам был зрителем того, как уволили именно так минимум 3-х сотрудников. Не самых плохих.
Конкретно данной ситуации — думаю что вся вина на менеджерах, они этого программиста возвысили, в общем то возложили всю ответственность на него — и он просто работал в том режиме который задало ему его начальства. Все большие ожидания от него порождали все больший напряг для сотрудника. Ну и понятное дело что в таком режиме долго не протянешь и рано или поздно просто сорвешься.
Ничего из описанного не может оправдать фразы на совещаниях вроде «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.» Когда разработчик, нанятый для работы в команде, позволяет сказать себе такое, он должен быть уволен безо всяких сожалений. Пусть работает себе дальше как свободный художник, можно например консультантом его нанять, но для работы над проектом он непригоден. Вина менеджмента только в том, что они не сделали этого раньше и тормозили до последнего.
Если у проекта есть какая-то проблема — виноваты всегда менеджеры. Потому что только у него есть рычаги влияния, у него должно быть средство сбора информации и так далее.
Если программисты будут решать еще задачи менеджеров, то нафига они тогда вообще нужны?
В данном случае то, что называло себя менеджером должно было убить себя об стену, чтобы не создавать проблемы для проекта. К сожалению, это ничтожество не только не сделало этого, но ещё и, как водится в вашей среде, подставило очень ценного (при должном отношении) резработчика.
Гениев мало, их ценить нужно, увольнять (а потом оправдываться отсутствием хороших сотрудников) много ума не нужно…
И тебе не нужна вина, с ней некомфортно.
Ты всегда белый работящий честно вкалывающий и высокопрофессиональный.
А баги вносишь не ты а менеджеры ночью в Гит лазают все портят
Ну вот сидит тут 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.", все-таки это был одноразовый взрыв.
Да это не правильно, не справедливо, так не должно быть, но с фактами не поспоришь.
В реальной жизни у нас часто нет юнит-тестирования, тестировщиков и вообще какой либо слежки за кодом, кроме "ну, я вроде у себя проверил".
Тем не менее — это не нормальные ситуации. Почему вдруг такая ситуация стала нормальной?
потом перестал, да. вопрос «почему?» исходная статья не особо проясняет. Так-то если одно и то же раз за разом объяснять, тратя по полдня — можно и устать. Или как в том анекдоте про байкеров что «чего с вами знакомиться, вы же каждый год новые»
Фраза из контекста вырвана, если бы я полгода пахал в режиме 24/7 по 10 часов я бы и более резкие высказывания мог себе позволить.
24/7 по 10 часовЯ не очень люблю придираться к словам, но…
Проблема ещё и в том, что человек при режиме 24/7 по 10 часов
— из-за хронической усталости становится раздражительным теряя адекватность,
=> и как следствие остальная команда может его из-за это начать воспринимать как "злобного неадекватного мудака", хотя он не мудак, а ему просто нужно отдохнуть.
Даже если мне дадут команду их лучших программистов и дадут время и ресурсы, чтобы их учить, то они только начнут меня понимать хорошо если через года.
Соверешнно нормальная ситуация. Много раз такое видел. Более-менее успешная компания. Но все сотрудники какие-то самородки-самоучки. Которые никогда нигде больше не работали, ничего другого не делали и живут в своём мирке. Кое-как с работой справляются. Ну и как там будет смотреться специалист с двое бОльшим стажем реальной работы, кучей проектов и опыта?
А иначе вы бы им и даром не сдались
А то получается, что тебя завут, как классного спеца, ты их спасаешь, а дальше начинается " а почему так?", «а мы так не делаем, ну и что, что не работает», «это ты специально выпендриваешься, а мы по-старинке». И начинают нагибать, чтобы ты шёл с ними по полю граблей, по которомы ты уже не раз прошёл. Всё равно конфликт возникает.
Или получается, что они приходят с кучей своих «гениальных» идей, а ты им раз за разом рассказываешь, что их идеи — говно и на практике работать не будут.
Завышенное самомнение, это когда оно скилам не соотвествует. А если соответсвует?
Именно тебя и нанимают чтобы ты им помог и здесь и сейчас и сделал бы свою работу так чтобы и потом у них было хорошо.
И это есть то за что тебе платят.
А если бы «они» разбирались бы в контроле версий, а не ты — то не они бы тебе за это платили, а ты им.
Если я им сделаю как положено — с итерациями разработки, сквозной интеграцией, тестированием, автоматизацией сборки, контролем версий и т.п. — то они это не поймут и не смогут использовать.
А если я буду работать, как «они», то и результат и качество моей работы будет как у них — бардак, ошибки, говнокод.
Что с этим делать я до конца ещё не определился. Требовать отдельный независмый отдел, учить людей и выстраивать правильную организацию работы? Но это дополнительная трудоёмкость и может вызвать проблемы в организации — одно подразделение будет работать не так, как другие. При этом «другим» будет казастья, что это подразделение работает меньше, т.к. они делает меньше дурной работы и меньше переделывает. Это даже в случае отдельного человека вызывает проблемы — все носятся, как угорелые, правят свои ошибки по пять раз, а один рабоет по графику и не сидит ночами. Ну и просить отдельные независимый отдел… Это часто воспринимается, как наглость и не находит понимания «зачем?» — Зачем новый отдел? У нас же есть — будешь с ними работать и постепенно учить.
Да, в источнике эта фраза есть.
Удручает неумение уважаемых хабровцев в критику источников — даже при наличии сходного или аналогичного опыта, подкреплённого релевантными исследованиями. Но это можно понять и простить: специфика профессии. Когда у тебя в отладчике вместо «от нуля до 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 года починки багов в большом проекте большой компании.
Это ваше мнение? Может быть он просто заменил какой-то «влобный» алгоритм чуть более продвинутой оптимизацией? Я согласен с предыдущим комментатором, что ускорить в два раза, чтобы было понятно всем — это совершенно другая задача.
Я видел лично этот процесс т.к хотел научиться лучшему. Сидел рядом и смотрел как смещения в массиве подбираются путем перебора.
А насчет того, что было стелано — решены проблемы CPU кэшинга, что реально очень важно там, где миллисекунды идут на счет.
Что делали мы: замена всего что можно на SIMD и переписывание кривого С++ интерфейса сторонней библиотеки, т.к. С++ интерфейс допускал лишние вызовы тяжелых С функций.
Но опять же, возможно вы и правы, и это был действительно криворукий ламер.
Толсто.
Судя по тому что вы пишете про кеши и то что вы до этого уже оптизировали в два раза — это весьма вероятно. Поэтому у человека не было иного выхода кроме как усложнять код.
Как пример кода, рекомендую взглянуть этот коммент и учесть что ни a
, ни ddd
не являются стандартными терминами в области, из которой был код.
Пофиг кто виноват, число грузовика = 1 — абсолютно ненормальная ситуация, давящая на всех. Кто-то должен был это прекратить — или Рик, или компания. Остальное — эмоции и поиск козла отпущения.
Зашибенный успех менеджмента. Кто платит за весь этот праздник щедрости?
О каком менеджменте вы говорите? Его не было как такового, одна большая ошибка с неизбежным плохим концом. Не возникло бы конфликта — случилось бы что-нибудь ещё. Начиная с того самого пресловутого грузовика и заканчивая тем, что разработчика могли сманить в другую фирму. Ну или Рик женился бы на ежихе и уехал жить в дурдом (весьма вероятно при таком ритме работы).
Понятно, что проблема была не в Рике. Не он создал эту ситуацию. Но решать её так или иначе надо. Не смогли по хорошему (договориться с Риком и ввести людей в проект так, чтобы любой кусок понимало хотя бы 2-3 человека) — значит, проиграли, надо бросать полотенце и начинать всё с начала.
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
Почему уволили Рика, а не менеджмент?
Потому что решение об увольнении именно менеджмент и принимает, ну, как они самих себя уволят.
И что-то мне подсказывает, что за всё случившееся они сами себя щедро наградили — за "героическую борьбу" с проблемами, которые они сами создали.
С себя, как вы понимаете, никто увольнять не начинает.
Если есть кто-то сверху над Риком и менеджерами — возможно, он их уволит/уволил за некомпетентность. Это разумно (число грузовика — очень простой индикатор, и менеджер, не отслеживающий его, мягко говоря вызывает сомнения в своей компетентности).
Но в любом случае ситуацию уже довели до момента, когда Рика им было не сохранить. А манагеров ещё можно обучить и использовать.
В статье же просматривается только личная эффективность Рика при отсутствии эффективности командного взаимодействия всех сотрудников, включая самого Рика.
Поэтому статья про Рика является ярким примером истории компании-банкрота, в которой роль Рика сильно преувеличена.
ну там и аджайлом и не пахнет, судя по описанию. Во всяком случае циклов разработки уж точно не было. На мой взгляд, проект в духе "а давайте сделаем всё, а потом выпустим готовый продукт и посмотрим что скажут пользователи" обречён на провал и без Рика. Очень легко потерять ориентир уже на второй месяц разработки и уйти вообще не туда.
Рика можно обвинить только в том, что он, будучи сеньором, пренебрегал знаниями о менеджменте. Он — герой-одиночка. Хорошо кодит, но не задумывается о долгосрочных последствиях, о том, что герой-одиночка не сможет написать в одно лицо работающую систему и что в команде архитектуру и код нужно писать не на уровне самого умного, а на уровне самого тупого члена команды. Или упрощать, или обучать.
Думаю, правильным решением было бы при первых признаках переработки запретить ему программировать, пока он не начнет справляться с основной обязанностью архитектора: формировать единое видение архитектуры у всей команды и контролировать реализацию.
"Звёздная болезнь встречается практически в любой работе" — особенно среди тех самых начальников. Недавно ради интереса прочёл маленькую книжку "Как пасти котов" где один большой менеджер рассказывает как этих котов (то есть программистов) надо пасти. Была у него даже такая фраза: "ведь его, программиста, карьера и судьба полностью в ваших руках" (это он призывал других начальников быть снисходительнее). Неплохо так раздутое эго.
Приходилось работать с коллегой, подходящим под описание Рика. Могу сказать, что в моем случае, руководство и команда настолько привыкли к весьма сжатым срокам решения задач и нагрузкам, что и на меня пытались повесить такие же.
Я пытался донести до человека, что его код поддерживать сложно, и руководству, что ему нужна помощь и отстоять свои интересы. Но ничего не получилось, все делали вид, что не контролируют ситуацию и говорили что ничего не могут с этим поделать.
В итоге решил уйти. Грустно это все, конечно.
Хех. Мне одно время приходилось быть таким rock star — в своём же проекте это было несложно. К тому моменту звёздной болезнью я уже не страдал, поэтому более слабых коллег не задирал. Ну… разве что когда они наглели. Тоже жаловались на то, что мой код слишком сложный, но с моей стороны ситуация выглядела как нытьё слабых программистов, что этот и-те-ра-тор это слишком сложная штука и им проще написать в 10 раз больше кода, зато простого. Были тёрки с одним сеньором и его начальником по поводу того как надо работать работу. Попытались даже меня уволить, но в итоге уволили их самих. Потом было другое начальство, там тоже была своя санта-барбара. В конце концов я на всё забил, сменил проект, работаю в пол силы и занимаюсь своими делами в свободное время. Сейчас вспоминаю то время и думаю, что зря всё это было: излишняя привязанность к проекту привела к ненужным конфликтам и практически к выгоранию.
Но вообще вина «Рика» тоже может наличествовать.
Собственно есть такой стандартный бюрократический метод. Он может даже неосознанно работать — человек (или отдел) стягивает на себя полномочия и функции, потому что может и потому что справляется. Особенно хорошо это заметно, когда полномочия размыты.
С программистами тоже может быть похоже — один человек становится незаменимым контрибьютором и диктует условия. Так как он писал проект долго — он в нем хорошо разбирается, разработка архитектуры только под себя, документации — нет.
Новые разработчики приходят, видят тонны говнокода и человека, который яростно его защищает. И уходят. Со стороны начальства выглядит как будто новые специалисты просто не могут соответствовать требованиям от Гуру.
«Порадовал» коммент от Brenna Harris: Рик просто не повзрослел, как и большинство комментаторов. А главное в истории — решить, чья это проблема и не спихивать Ответственность на Взрослых. Потому «Рик» и под вымышленным именем: если назвать или вычислить его подлинное имя, он может подать в суд и обоснованно утверждать, что вот такая история — крест на любых карьерных перспективах в Вонючем Взрослом Мире.
Он просто не понимал, чем ему это грозит как специалисту и ничего не предпринял. А выход тут простой — надо уходить из такой фирмы самому и как можно быстрей.
Просто нужно осознать, что если все коллеги на голову ниже, начальник боится тебе — то вероятность накрутить себя и вырастить в себе Наполеона стремится к бесконечности. Изифолд.
Подчиненные/соседние админы есть?
Если работаете больше 8 часов в день, то требуйте подчиненных или уходите. Для меня смена работы всегда оказывалась очень хорошей идеей.
Такой подход открывает очень большой простор для злоупотреблений со стороны работодателя.
Сначала "не успеваешь — плохо работаешь значит, работай сверхурочно". Потом "не успел — подставил компанию, изволь заплатить штраф". Потом сговор относительно условий труда и уровня зарплат. А потом опять 1917й.
Цивилизованный подход — или менять хотелки, или искать работника, который может и хочет за указанные деньги выполнять указанный объем работ.
Вы бы делали то, за что вам платят…
То есть, чаю налить нельзя, в окно посмотреть нельзя, в туалет нельзя, прогуляться по коридору отдохнуть нельзя, так что ли? А если импорт идет, программа компилируется, пакеты устанавливаются, другой человек долго на сообщение не отвечает? Наверно надо в это время имитировать бурную деятельность.
А если можно, то какая разница, на что человек потратит эти 10 минут? Если такой промежуток времени влияет на результат, это само по себе говорит, что времени на задачу отведено впритык.
1)штаты разрабатывается либо пузатый дядя времен хрущева либо его женская версия, для которых слово «связь» — это телефонная трубка, и о том чем я по факту занимаюсь они вообще не имеют ни малейшего представления. а потому даже моя должность звучит не совсем с оттенком хоть какого то налета IT.
2)добавь к штатным обязанностям еще общевойсковую головомойку, как то — наряды, кучи построений, выезды, тревоги etc.
и получается что на выполнение прямых обязанностей за которые мне платит деньги моя страна, у меня остается не так много времени. и хрен бы с тем временем — сил почти не остается. а у меня парк серверов, куча VoIP оборудования, транкинг…
3) на хабре я сижу во время обеда.
Я вот как начальство, вижу только
Alphary 18.10.17 в 15:16
Alphary 18.10.17 в 13:42
Alphary 18.10.17 в 17:22
Мне б такой…
Смешит убеждённость некоторых, что хронометраж дня, всякие там ЛУРВы — не просто «самый верный показатель» целеустремлённости и качества работы, но могут искренне удивить, потрясти, обескуражить владельца замеренного времени (я про человека, а не про его работодателя).
Машина построена таким образом, что каждый отвечает исключительно за свой небольшой кусочек и если в какой-то из частей системы (имею в виду предприятие в глобальном смысле) произошел сбой узнать где именно и почему это произошло порой очень не просто.
Некоторые люди же совершенно не могут работать в таком стиле и они рано или поздно либо увольняются либо пытаются возглавить этот бардак. Обычно такие люди появляются в больших проектах по оптимизации/автоматизации/внедрению новых бинзнес процессов и начинают постепенно скапливать знания, которые по хорошему доступны любому из участников процесса — просто никто не хочет заглянуть дальше своего носа. Да, знания оседают в их головах и копятся годами и да — они не переносятся на бумагу в виде документации по двум причинам:
1. Банальная нехватка времени — к рок звездам постоянно кто-то заходит с вопросами, причем с разных сторон — тикеты/телефон/скайп/почта/личная встреча. К стати, в ходе таких консультаций тоже копятся новые знания (вот такой вот снежный ком)
2. Полнейшее отсутствие мотивации — 90% документов все равно никто тупо не будет читать
И такой расклад в первую очередь бьет по «рок звезде» т.к снежный ком знаний растет а времени меньше и меньше. И тут опять возможно 2 варианта развития событий:
а. Рок звезда увольняется, оставив все накопленные знания при себе. При этом в компании ничего не изменилось и процессы стают на тот же уровень коммуникаций как и до появления рок звезды
б. Рок звезда вежливо общается с руководством (т.к это прежде всего в его интересах) и руководство составляет конкретный план действий по изменению корпоративной культуры к лучшему.
У нас в компании есть похожий человек, его зовут Фрэнк. Уже полгода минимум одна из историй в каждом спринте посвящена эпику под названием "defrankifying" ;-)
Никто вам не поможет, кроме вас самих (как, например, коментататор ниже). Увы.
Менеджеры, плохо эксплуатирующие станки, которые могут работать по 20-30-50 лет точно так же подлежат увольнению, как менеджеры, «ухайдакивающие» разработчиков за 2-3 года.
Точно так же, как лучше у станка сменить прокладки до того, как у него там закоротит всё нафиг наглухо, так же и сотрудника дешевле отправить на хороший курорт, чем искать нового и ждать, пока он «притрётся».
Да, есть менеджеры, строящие свою репутацию на том, что умеют «выдать результат» «загнав вноль» всё ресурсы, которые у них есть — но это не значит, что это хорошие менеджеры.
Мой код слишком сложен — слышал я (пишу на Java). Слишком сложно — это использовать Stream api для трансформации/фильтрации. Другой «сениор» это не осилил. Переписал на итератор. Слишком сложно пишу видимо(или просто квалификация разработчиков остается на каком-то уровне выше которого им подниматься лень).
Из статьи еше стало понятно, что Рик задал вектор движения. А что смогли сделать остальные девелоперы за оставшийся промежуток времени — это выкинуть бОльшую часть фичей и навставлять костылей(поныв менеджменту что ничего непонятно, мы не успеем и т.п. — те в свою очередь задрейфили и пошли на уступки).
Да и руководство тоже молодцы. Сделали все для того что бы Рик выгорел. А потом нашли крайнего вместо того, что бы разобраться в ситуации на самом деле. Не снимаю вину с Рика, но менеджер должен уметь менеджить(простите меня за тавтологию). И уволить нужно было еще парочку менеджеров вместе с Риком(хотя может быть Рика нужно было просто отправить в принудительный отпуск/кинуть на другой проект).
И всё же, согласитесь, исходная статья полезнее и информативнее для Риков и потенциальных Риков, чем даже отклик его «адвоката»! Только если все инсинуации насчёт самооценки и якобы фраз про Эйнштейна пропускать мимо ушей, ибо BS. Но как оно работает при смене руководства затянувшегося проекта и как талантливый разработчик может перестать быть талантливым — уэлкам!
А я в статье узнал себя пятилетней давности: высокомерный оверинженер, неспособный к кооперации. Однажды мне очень повезло с работой и командой. Ребята меня натурально носом потыкали в мои абстрактные фабрики абстрактных фабрик и попросили решать, те проблемы, которые ставит бизнес, а не моё воображение.
С тех пор открыл для себя принцип YAGNI (you ain't gonna need it), который практикую сам и пропагандирую коллегам.
Следование YAGNI отрезвляет, способствует прислушиваться к нуждам бизнеса и к написанию простого и выразительного кода. Это как KISS, который нельзя интерпретировать двояко.
Уверен что Рик был незнаком с этим принципом.
В лучшем случае — дерзновенные «pre-sale customers», не путать с «заказчиками»!
Впервые услышал сейчас про YAGNI.Интересно, что об этом думает Paul Graham — человек не без бизнес-опыта, но приверженный панматематизму и культу мощности языка, а потому евангелист Лиспа.
Сейчас пишу с телефона, а завтра с полноценного ПК обязательно поищу, что он думает.
Если человек м*к и всех бесит — надо его убирать, независимо от его гениальности. Потому что из-за него кому-то другому просто неприятно находиться на рабочем месте. А 100 центурионов в боевом порядке, работающие слаженно круче 1000 берсерков, хотя 1 берсерк круче 10 центурионов. Разлад и дрязги в команде — предвестник конца.
А если человек просто специфический (но при этом не напрягает своих коллег там поведением, запахом, внешним видом итп) и не очень может работать в корпоративном духе (ну вот не может он раз в неделю писать отчеты о своей работе и документировать каждый шаг), но при этом весьма квалифицирован — то с таким ИМХО лучше научиться жить. Вероятно руководителю даже имеет смысл сделать исключение и взять процедурные обязанности этого сотрудника на себя. Все-таки квалифицированных кадров не так просто найти.
Я думаю смысл понятен.
Другая аналогия — рядовой армии ни в каком сравнении не стоит рядом с опытным боевиком-наемником, который с 16 лет бегает с автоматом.
Однако регулярная армия всегда эффективней.
Однако регулярная армия всегда эффективней.
Чеченские кампании Вас ничему не научили.
Армия в подавляющем большинстве случаев выигрывает числом и технологиями. Если те же самые технологии попадают в руки активных, опытных и мотивированных людей, то эти бойцы становятся намного эффективнее немотивированных малоопытных солдат армии.
Чеченские кампании Вас ничему не научили.
Научили тому, что когда в армии бардак — она воевать не может. Даже если велика числом и имеет артиллерию с авиацией.
Наша армия (по крайней мере того периода времени) — не самый лучший пример.
Хотя по этому конкретному вопросу у меня тоже есть отдельное мнение, но я не хотел бы углубляться в эту тематику.
Тем более что там не какие-то бородатые мужики были а куски собственной армии в том числе.
Должен быть порядок и мотивация. Как в Израиле например. А не борьба политической элиты за место у кормушки. Без этого армия — не армия.
Все три приведенных Вами примера — это по сути гражданская война. Гражданская война — это априоре ппц и анархия. Если Тель-Авив и его метрополия захотят отделиться от Израиля — израильская армия мгновенно перестанет быть самой боеспособной армией в мире.
Вообще в наше время довольно трудно найти подходящие примеры — потому что все войны это либо разборки внутри страны либо противостояние разных регулярных армий.
Дальше надо искать — как раз во временах легионеров/центурионов или крестоносцев.
а) к теме статьи это отношения не имеет
б) как я выше написал — этот околополитический дискус я развивать не хотел бы (ну то есть это вежливая форма фразы — не буду).
Но на один большой оффтопный комент меня развели. Больше не получится.
Просто если продолжать — начнется срач на тему хорошего/плохого Каддафи, хорошего/плохого Асада, Америки, Путина, Навального. Понабигут политически ангажированные тролли.
Нафик.
Ну то есть я могу порассуждать на тему состояния радиоэлектронной промышленности в нашей стране, но дальше этого я стараюсь не ходить.
Все политически ангажированы — но не все бегают и с пеной у рта доказывают свои взгляды.
По этой причине мое участие в политических дискуссиях является бессмысленным.
За сим предлагаю эту тему не развивать.
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.
Это крайность.
Но он не должен там… вонять. Его одежда, руки итп — должна быть чистой. Он не должен эпатировать окружающих своим поведением и внешним видом. Это же вполне нормальные требования. Если это не соблюдено — то мне абсолютно пофиг сколько там чего такой человек знает. Ни я ни моя команда с ним работать не сможет — а это сводит на нет всю пользу от его квалификации.
Скорее у него работают неплохие спецы, моющиеся каждый день
Именно так и есть. У нас достаточно эффективная команда, на которую в то же время приятно посмотреть и c которой не стремно находится в одном помещении торговцам и прочим ребятам, для которых лицо — это часть работы.
Ответа на вопрос «зачем» — у меня нет. Такой офис.
Это кстати еще большой вопрос кто более шумный :)
Ну т.е. работодатель, как всегда, экономит, а ужиматься, как всегда, в чём-либо приходится работникам.
И нет, шум одной с тобой команды мешает слабо, а вот шум других ребят (даже если это тоже программисты) — отвлекает и ещё как. При этом те самые "фейс-работники" обычно создают шум регулярно.
Нет никакой необходимости писать 5 страниц текста, чтобы попытаться оправдать зазвездившегося сотрудника.
Судя по тексту статьи, он довёл себя самостоятельно.
Косяк руководства заключается в том, что они все симптомы успешно проигнорировали, в то время как следовало в течение 3 месяцев после первых тревожных симптомов сделать следующее:
1) Беседа №1
2) Беседа №2 ("если не справишься, нам придется расстаться")
3) Чемодан-вокзал
это хорошая отговорка для менеджера этого сотрудника.
2) Беседа №2 («если не справишься, нам придется расстаться»)
Ну да, сотруднику который тащит на себе больше задач чем кто либо, подходить с такой фразой. 5 баллов для «эффективного менеджера».
Да вместо 2й беседы должна быть принудительное отправка такого сотрудника в отпуск недели на 2, а то и на 4 (явно у него там с таким графиком работу, отгулов и отпусков было море). И ручное раскидывание задач по другим сотрудникам.
И ручное раскидывание задач по другим сотрудникам.
Он в детском саду работает? Нет? Тогда должен самостоятельно оценивать объёмы работ, которые сможет выполнять, укладываясь в сроки.
Да вместо 2й беседы должна быть принудительное отправка такого сотрудника в отпуск недели на 2
Опять детский сад. Ему никто не запрещал уйти в отпуск и не заставлял работать овертайм, насколько я понимаю.
Нет, он работал под менеджером который должны оценивать количество задач вообще и количество задач на сотруднике. Это его прямая задача — управлять. В том числе и нагрузкой. Задача сотрудника вроде Рика — выполнять задачи.
Опять детский сад. Ему никто не запрещал уйти в отпуск и не заставлял работать овертайм, насколько я понимаю.
Ну да… «Чувак, ты можешь в любой момент пойти в отпуск. (за кадром) Только помни — твои задачи сможешь сделать только ты. Так что после отпуска придется работать по 20 часов в сутки, что бы закрыть то, что накопилось за эти 2 недели + то что будет приходить в обычном режиме. И да — компьютер с корпоративным доступом не забудь. Т.к. руководство понаобещала клиентам множество новых функций и сделать их надо ASAP, а на дополнительных сотрудников у нас денег нет. Ты же не хочешь подвести команду???»
И опыт говорить «нет» в таких ситуациях приходят с годам и с количеством «граблей»!
за кадром
Я мысли читать не умею, так что завидую, что у вас есть такая способность
менеджером который должны оценивать количество задач вообще и количество задач на сотруднике
Я писал, что косяк менеджмента именно в том, что они позволяли брать ему на себя любое количество задач, что не отменяет всего остального вышесказанного.
А зачем тогда менеджеры? Если он все должен сам делать?
Опять детский сад. Ему никто не запрещал уйти в отпуск и не заставлял работать овертайм, насколько я понимаю.
Если на нем так много держалось, то вполне могли и запрещать.
Ну, просто это как-то глупо. Программист же пишет код, а не сначала занимается херней, а потом "менеджеры могли сами код написать, что за детский сад".
Я не понимаю, о чём тут с вами спорить.
Может ему мама попу вытирает, пока он код пишет, поскольку он сам не в состоянии увидеть, что она грязная.
Ещё раз — мы говорим о взрослых дееспособных людях или о ком?
Да, мы говорим именно о взрослых дееспособных людях, которые знают про разделение труда и должностные инструкции.
Задача программиста — это писать код. Да, он мог сделать много чего, но если он этого не сделал — это не его ошибка.
Потому что делегировать и распределять надо уметь, а это не сильно коррелирует с навыками программирования.
Может поделитесь ссылками на авторитетные источники с исследованиями данного вопроса?
если сеньор не способен адекватно раскидывать задачи и тикеты
… значит ему нужно поискать другую работу, где не нужно раскидывать задачи и тикеты, например.
Не соглашусь, "сеньорный" сеньор должен уметь работать в любой роли SDLC, от продукт овнера до тестировщика. И совмещать их при необходимости.
При этом быть человеком-оркестром необязательно, обязательно понимать и прилагать усилия для улучшения культуры хотя бы своей команды.
Под SDLC подразумеваю Systems development life cycle. Возможно, вы подразумевали что то другое.
Насчёт "должен уметь работать" вопрос, безусловно, дискуссионный, но иметь понимание о том, как это должно работать и вовремя выкидывать красный флаг / зажигать лампочку / давать тройной гудок — да.
Я не фрилансер и никогда им не был, это раз.
Это вопрос не про сам-себе-менеджер, а про "ты же зубы с утра без напоминания чистишь", это два.
А то, что мы обсуждаем — в детстве редко закладывается. Обычно это уже могут закрепить и развить работодатели и наставники в более взрослом периоде.
Зубы… вонь, как от бомжа… в голове один мат… что ещё сопутствует либо подтянется само собой к фричеству+упрямству, м?
Гораздо хуже когда непонятно — чем пронять человека, чтоб повысить его эффективность. Кому то денег надо, кому-то ответственности, а кому-то публичности. Это нормально.
наоборот надо всячески холить и лелеять его самооценку
Ага, от этого у них вырастает холка и лелейка
Я просто только сейчас спустя много лет понимаю, что это была нормальная такая манипуляция с целью предотвратить мой уход из компании малой кровью (а мысли у меня такие были на тот момент), то есть при этом сохранив достаточно скромную заработную плату. И это сработало. Тяжелая артиллерия в общем.
У меня конечно эго сразу отросло ниже колена в этот момент — но я бы не сказал, чтобы это как-то повредило. Скорее наоборот.
повесить на меня перк «лучший молодой специалист радиоэлектронной промышленности».
Господи, это работает? И правда детсад.
Я правильно понимаю, что прошлый работодатель — это гос. компания?
Положение дел в оных мне не интересно от слова совсем, я свои выводы сделал на основании собеседований с сотрудниками этих компаний.
Во вторых когда тебе между 20 и 30 — конечно же работает.
Сейчас уже наверное бы не сработало — я стал более финансово ориентирован. Но тогда — еще как. Побежал работать как миленький с утроенным усердием.
Видимо мне повезло, потому что на меня эти свистульки и погремушки никогда не влияли.
Я понимаю Ваш скепсис по поводу всего этого, потому что и сам его не лишен.
Но ничего плохого в таких вещах нет.
У разных людей разные ценности. Не стоит их осуждать только за то, что они не совпадают с Вашими.
Кому-то нравится Филипп Киркоров — ну что теперь поделать — это физиология.
Так я не отнимаю право у человека иметь свои ценности.
Просто когда один человек демотивирует 20 других — с ним надо прощаться, потому что за 20 человек он работать не сможет.
Ну то есть пусть он имеет право на свои ценности где-нибудь ещё, где он не будет ими мешать остальным.
Если человек м*к — от него надо избавляться независимо от его скилов.
Причем «звездность» далеко не всегда сопряжено с вышеозначенным признаком, равно как и вышеозначенный признак далеко не всегда сопряжен с «звездностью».
Чаще наоборот — эти вещи вместе не ходят.
Мрачный и стремный гений — это скорее стереотип чем регулярное явление.
Я правильно понимаю, что прошлый работодатель — это гос. компания?
Нет, не гос. Но рядом там. Хотя у нас в стране почти все рядом там…
я свои выводы сделал на основании собеседований с сотрудниками этих компаний
Ну и кстати зря. Молодежь там весьма толковая бывает. Не опытная да (собственно поэтому она там и ошивается — надо же где-то начинать) — но опыт дело наживное. Вот с людьми постарше, которые там 15-20 лет просидели — да, надо быть аккуратнее. У них уже сложившиеся стереотипы и подходы к работе есть, не самые оптимальные часто.
Ну и добавлю еще по поводу «работает». Не смотря на свое текущее виденье той ситуации и некоторый цинизм по этому поводу — я все равно этим дипломчиком горжусь, и не преминую указывать его в своем CV. И на работодателя оно вполне себе тоже действует, хотя конечно не в виде определяющего фактора, а как дополнительный плюс при прочих равных.
Так что работает и еще как. Финансовая мотивация не есть панацея на все случаи.
В оригинальной статье, главная мысль про необходимость командной работы, а не про то, как выгонять гениев или что гении не нужны.
В оригинальной статье, главная мысль про необходимость командной работы, а не про то, как выгонять гениев или что гении не нужны.
Это же так отлично, когда менеджеры, вместо того, что бы заниматься созданием этой командной работы, сначала факапят, а потом такие "ну, командная работа же важна, не забывайте".
Они даже не пытались его понизить нормальным путем. Они потом продолжали его подкармливать, совершая неправильные шаги.
Тут уже предлагали в комментах, что нужно было делать по нормальному. Подойти к нему и сказать, что он слишком много работает, ему стоит заняться собой и даже принудительно отправить его в отпуск. Вместо этого они подошли к нему и такие "ну знаешь, в целом нам не нравится качество твоего кода, сделай с этим что-то". Так дела не делаются же.
После такого я думаю, начать вести себя неадекватно в целом вполне нормально.
I’d been aware of the project for a while, because it had grown infamous in my organization, but hadn’t been assigned to it.
I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues.
It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.
И снова из оригинально статьи:
We sat down with Rick and had a conversation about his role in the project. We reviewed our concerns. We sidestepped his self-comparison to Albert Einstein.
We explained our new strategy. The team was going to collaborate on building a new product from scratch.
Я про то, что в этом месте тоже была совершена ошибка.
они не заметили особо провтыков менеджмента предыдущего
Автор четко пишет:
His manager shares in this responsibility.
А в чем, по вашему мнению, ошибка? Нужно было дать Рику продолжать пилить проект в одиночку? Там же были использованы все возможные методы перед увольнением: от предложение взять несколько выходных до просьбы передать часть своей роботы команде.
Нужно было получить, наконец, чёткое ТЗ — даже если заказчиков не существовало (а там похоже на то).
Нужно было, ять, встречаться с Риком (терпя его! Ахахах… как какие-то тупые разработчики! Может, ещё место в очереди их к нему занять?! А вы представляете, что мы слышали: он себя Эйнштейном перед кастомерами назвал! (Вроде бы). Фууу!!11) КАЖДЫЙ ДЕНЬ, а не в три китайских предупреждения.это же единственный ключевой человек проекта! Кризис-менеджмент Golden Horde mode?!
Неее, Вонючий Взрослый Мир — и всё тут.
Вы разделяйте между 12 на 7 у станка или таскание кирпичей на 8 этаж от разработки. В первом случае через 6 месяцев ты будешь таскателем кирпичей с подорванным здоровьем и больной спиной. Во втором случае опытным специалистом, умеющим разделять задачи, управлять командной, с навыками решения проблем. Мозг учиться очень быстро, для него нет понятия предела, чем больше его нагружать, тем быстрее он адаптируется.
Через 2 года, как описано в статье, Рик мог отправить несколько резюме в СФ и жить на 800+ к рублей в месяц. Почему он этого не сделал? Может потому что он идиот?
На самообразование при таком графике редко хватает времени. Скорее что-то быстрое, а не какие-то курсы, так как материалу тоже нужно усвоится и найти свою область применения в повседневной работе.
Во втором случае опытным специалистом, умеющим разделять задачи, управлять командной, с навыками решения проблем. Мозг учиться очень быстро, для него нет понятия предела, чем больше его нагружать, тем быстрее он адаптируется.
Нет, у вас будет помимо убитого здоровья еще убитые нервы, раздражение, куча психических проблем и еще подорванные отношения с семьей, скорее всего.
Потому что мозгу нужно отдыхать, нельзя жить одной работой, потому что потом вот тебя уволили и что дальше? Идти прыгать с крыши, потому что у тебя больше жизни нет? Ну и если у вас были овертаймы хотя бы недельку-другую, вы бы знали, что мозг еще и как устает.
Через 2 года, как описано в статье, Рик мог отправить несколько резюме в СФ и жить на 800+ к рублей в месяц. Почему он этого не сделал? Может потому что он идиот?
Возможно все гораздо банальней — он человек которые до последнего верил в компанию, в которой работал, в продукт. Зарплата, скорей всего, устраивала. И то что перегрузки — «ну так это временно» (скорей всего еще и подпитывалось менеджментов «вот сейчас выйдем на ICO/нас купит Гуугл, вот тогда и заживем. Надо чуть-чуть потерпеть. На том свете выспимся.»). Ну а что бы понять, что такие проблемы не временные — нужен опыт и каждый его по разному и разное время набирается.
сидит каждый день до поздна, пишет быстро, некоторые читают его гением.
Но код — просто вырви глаз. Этакое спагети с багами без намёков на паттерны.
Короче — много работать, ещё не значит хорошо. Я бы некоторым законодательно запретил перерабатывать.
Через 2 года, как описано в статье, Рик мог отправить несколько резюме в СФ и жить на 800+ к рублей в месяц. Почему он этого не сделал? Может потому что он идиот?
Это средняя зп миддла в калифорнии…
увольнение Рика было лучшим решением, которое они когда-либо принимали
Похоже на честное признание менеджмента, что кроме принять на работу, выжать все и уволить других методов управления нет.
I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues.
It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.
Но в статье сделан акцент на менее очевидных вещах:
By this point the whole team knew he was destructive. But the cult of dependence was so strong that everyone believed he was the only option.
There is always another option.
Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.
Далеко не универсальное правило. Команда из крепкий середнячков не выдаст революционный продукт на гора и не сделает чего-то «сверх». Когда вы делаете новый продукт на конкурентном поле, нужен человек-звезда, лидер. Со своим взглядом и стратегическим видением. Он сформирует образ будущего продукта. А серая сплоченная масса хороша для поддержки опердня в банке.
Грубо говоря условный Стив Джобс никогда не будет подчиняться условному Джону Скалли — однако при этом он может создать как прорывной iPhone, так и мёртворождённую Lisa'у… как повезёт.
На черта мне быстрый конь. который не бежит в ту сторону в которую надо? Толку от того что он за 20 минут доскакал до Иркутска. если мне надо было в Рязань?
Сам был в роли почти такого Рика, хотя уволился на примерно пол пути.
- в компании был отличный спец с багажом знаний;
- в компании была толпа некомпетентных разработчиков, которым все это нафиг не нужно. Не джунов, а именно людей, кто не хочет разбираться, и программирование для них — просто какая-то профессия, за которую неплохо платят (это сейчас вообще довольно популярная проблема). В итоге получилась ситуация, что проще сделать самому, чем объяснять коллеге, куда смотреть и что делать. И даже если он сделает, то сделает плохо и придется переделывать.
- в компании Рики рубил идеи других разработчиков. Если разработчики бы были компетентными, они могли бы аргументированно могли продвинуть свои дели. Значит, идеи были говно.
- в компании за 2 года (или сколько там в сумме?) никто не задал вопрос, что происходит. Там вообще, кроме Рика, кто-нибудь хоть какую-нибудь функцию выполнял?
- большая нагрузка в режиме 12/7 свидетельствует о том, что был дедлайн, и чувак пытался как мог к нему успеть. Часто такой режим подразумевает костыли, отсутствие серьезного тестирования, говнокод и прочие проблемы разработки. И тратить время самого ценного сотрудника компании на то, чтобы в этом аду дедлайна объяснить джуну, как поправить конфиги — кощунственно.
- любой адекватный развивающийся разработчик с радостью перепишет свой код. Потому что сегодня ты лучше, чем вчера. А завтра будешь лучше, чем сегодня. Отказываться от этой затеи можно только в тот момент, когда нет желание этим больше заниматься, либо дедлайн (и это самая частая причина, почему нет рефакторинга).
- в итоге оказалось, что было еще целых полгода, за которое толпа бездарей (либо же новых сотрудников? это как-то не указано явно) смогла переписать проект. Чо-то какой-то небольшой проект, вам не кажется? Можем, Рики вполне мог делать какие-то отдельные части?
Короче, что-то не так в этой компании.
> Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow.
А еще, когда переписываешь код, уже видишь весь функционал. Кто пишет приложение в гонке за сейлзами, такой возможности не имеет и потому его архитектура всегда неактуальна.
Только в большинстве случаев это неправда. Убрать доступ к ФС телефона или выпилить AUX разъем — это кагбэ тоже «убрать свистелки и перделки, упростить все до 3 путей использования», но лучше ли это для конечного продукта? Или, например, убрать кучу проверок из кода, может, и упрощает чтение кода, но уменьшает надежность.
Я тоже, бывает, открываю наши большие проекты и думаю, нафига тут сколько всего нагородили, нельзя было проще? А в реальности начинаешь думать, как сделать лучше — и не всегда получается все эффективно сократить, есть куча нюансов, о которых знаешь только при глубоком понимании предметной области.
Кирилл, Никита, если вы это читаете — спасибо :)
Трагедия ситуации в том, что при увольнении все остаются при своем. Гений еще больше озлобляется, команда и менеджмент облегченно вздыхают и говорят: «Слава Богу, вот теперь то мы заживем!» Но через пару лет все повторяется. Гений устраиваться работать в команду, где он опять будет обиженным гением, а команда находит или взращивает новую обиженную рок звезду.
Единственный выход — уход от взаимных обвинений и принятие каждой стороной на себя своей доли ответственности за ситуацию. Каждое возмущение на подобии: «А что это он, редиска, делает XXX» — нужно превратить в вопрос: «А каким своим поведением я даю понять, что со мной можно так себя вести?»
Прочитал исходную статью. Все они хороши, и Рик и компания. Но компания по-моему все-таки более неправа. Эту статью считаю правильной, но несколько однобокой.
Rick didn’t need anything anybody else built. He built everything he needed from scratch
Bugs were popping up in old tools he’d built
to replace about 150,000 lines of incomprehensible mess
Писал велисипеды, причем похоже вообще для всего. Конечно потом появлялись баги, сразу все не предусмотришь, тем более в таких объемах. Он не документировал код даже когда было на это время.
Но проект видимо изначально был самописный. Он просто "поддерживал традицию".
You will never be able to understand any of what I’ve created. I am Albert F***ing Einstein and you are all monkeys scrabbling in the dirt.
Я понимаю, можно на нервах наорать по поводу "я дофига всего сделал" или "это не мое дело" или там "задолбали вы уже с новыми задачами каждый день". Но так высокомерно оскорблять это уже черта характера. Просто из-за напряженной работы она проявилась.
Everyone was waiting for Rick
Это вопрос к компании. Почему вдруг все задачи стали зависеть от работы одного человека? Почему другие не могли сделать свое временное решение? Нет, давайте будем ждать. В остальном, в этой статье все написано.
He reverted code changes, including tested bug fixes by other developers.
He asserted that he wouldn’t be held accountable for supporting other people’s work.
Это можно понять. Он там все делал, а они там сломают что-нибудь, и потом к нему опять пойдут. Ведь похоже код-ревью с его стороны не было, они просто взяли и поменяли.
We obtained an agreement from the project sponsor to shut off some edge-case functionality.
А до этого нельзя было договориться о его отмене? Рик пусть делает, мы подождем. А как самим понадобилось, так сразу "а может не будем делать?".
Если разработчику пришла задача, подразумевается, что ее обсудили и решили что она нужна. Поэтому глупо предъявлять претензии, что он не догадался, что не нужна.
He refused to take time off or allow any work to be delegated.
Тут он сам дурак, в отпуск сходить не помешало бы. Хотя со стороны компании было бы правильнее сказать — мы убираем тебя с этого проекта, за ошибки других ты отвечать не будешь. Делегировать часть работы принципиально ситуацию не изменит.
He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools.
Это тоже можно понять, они же неизвестно как работают, вдруг что-то сломается. Но отношение "работает — не трогай" это признак плохого кода. Видимо Рик не особо профессиональный разработчик, раз такое допустил и не хочет менять.
First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick.
У них похоже такие разработчики, что им проще спросить и ждать ответа, а не разобраться самому, а виноват почему-то Рик.
Был в похожей ситуации, когда делаешь в одиночку некоторую часть функционала. Когда в новых коммитах кто-то меняет "твои" файлы, появляется мысль "кто там опять лазил и зачем". Ведь если сломается, спросят тебя. И делегирование так же. Помимо новых задач будешь объяснять как что-то работает, код проверять, или брать задачи по этому функционалу если кто-то не успевает. Поэтому лучше когда основной разработчик перейдет на другой проект/часть проекта и не будет отвечать за ошибки новых, проверять или исправлять, максимум консультировать.
Тесты это правильно, кто ж спорит. Не было у нас там тестов, и времени на них не было. global $db
и все такое, по сотне задач на разработчике. Хотя я сам тогда в тестировании не особо разбирался. Потом правда тестировщики появились, вручную проверяли.
Я больше о том, что когда сам все делаешь, привязываешься к коду, и неожиданные посторонние изменения немного беспокоят. Pull-реквесты тут хорошо подходят. Если они есть.
Главное другое. Такая ситуация сплошь и рядом там где начальник озабочен только прибылью но совершенно не разбирается в специфике выпускаемого его фирмой продукта!
ДА как не смешно но это так!
Господа, имеет смысл почитать комментарии к оригинальной статье. Там автор довольно подробно отвечает на некоторые из них. С его слов своими словами:
Автор имеет опыт спасения некоторых тонущих бизнесов из подобных ситуаций и был вызван как раз ради этого. Рика достаточно долго и деликатно пытались перевести на рельсы командной работы, а не сразу взяли и уволили. Но в первую очередь уволили текущих менеджеров, как позволивших сложиться такой ситуации. Рика не заставляли работать в режиме 12х7, он отказывался брать выходные. Вдобавок к этому он пилил не только основной проект, но забирал себе некоторые работы других членов команды, считая, что сделает лучше. В самом начале писал качественный код, а потом начался обильный нечитабельный говнокод из хаков, скреплённых говном и палками. И всё же процентов 10 от его кода, то, что работает стабильно, продолжает использоваться. В команде не джуны и не дебилы, а хорошие интеллигентные инженеры, хоть и не самородки-гении с синдромом Мюнгхаузена, от которого им приходилось регулярно терпеть словесные унижения. И который подавлял любые идеи и инициативы, как технические, так и рекомендации руководства по выходу из тупиковой ситуации. Потому, избавившись от тирана и получив творческую свободу и возможность использовать готовые решения, в том числе и платные, команда смогла быстро реализовать базовую необходимую функциональность.
Хотелось бы почитать статью написанную «Риком», о том, что он думает. Это было бы справедливо.
В прошлом я более 10 лет был разработчиком. По поводу статьи:
Я в шоке от того, что все начали защищать Рика! Ребята, почему вы смотрите про переработки, которые он сам взвалил на себя (кстати, эта особенность большинства Рок звезд), но игнорируете результат, который добилась компания:
- Пять лет работы (и результата нет), заменила на 1 год и готовый продукт. За пять лет на одного человека денег ушло куда больше, чем на команду 3-5 человек. Плюс ко всему через год продукт уже продается и начинает окупать вложения
- От всего того, что сделал Рик, они оставили 10% действительно нужного кода. Все остальное судя по всему Рик закладывал на будущее, пытаясь предвидеть все и вся, хотя как правило оно так никогда и не требуется
- Они уменьшили риски, упростили код, упростили техподдержку, ввели тестирование, в проект легко вводить новых разработчиков, улучшилась обстановка в компании
Полностью согласен с руководством компании, которые уволили менеджеров Рика и самого Рика. Это надо было сделать гораздо раньше. Толку от звезды, если он никого не слушает. Все ваши разговоры про то, что остальные разработчики в компании лохи – не соответствует действительности. Продукт был успешно выпущен без него.
Теперь по поводу звезды в нашей компании:
Боюсь, что скоро нас может ждать тоже самое. Рок звезда делает очень важный модуль. Он молодец, реальный спец, хорошо и качественно пишет, мы его очень ценим. НО! Он НИКОГО даже близко не подпускает к своему коду. Как Рик в этой статье. Для нас это большие риски, т.к. проект растет. Мы регулярно предлагаем ему в помощь специалиста. На все попытки жутко раздражается и ревнует. Постепенно берет на себя больше работы. Я думаю, что Рок звезды прутся, когда от них все зависит.
Есть много интересных задач, которые он с удовольствием берет на себя. Но же мы только получаем еще больше модулей, в которые он никого не пускает.
Из-за этого он стал узким звеном, в производительность которого (пусть даже высокую) все упирается. Переработок у нас нет, стараемся этого не делать. Но сроки по внедрению новых задач в итоге переносятся. Когда мы предлагаем нашим программистам похалтурить на нас во внерабочее время (бывает крайне редко), то всегда договариваемся о дополнительной оплате.
Единственно, в чем мне удалось переучить Звезду за годы работы: это делать ровно то, что требуется для решения задачи. Раньше он как Рик писал кучу кода, абстракций, пытаясь предвидеть будущие требования. Спустя 5 лет он сам лично пришел ко мне и поблагодарил меня за это. Теперь он закрывает задачи очень быстро.
Но все равно, если у вас есть Рок звезда – будьте осторожны. К ним требуется особый подход.
Я лично, хочу уточнить один момент:
Раньше он как Рик писал кучу кода, абстракций, пытаясь предвидеть будущие требования.
Он когда-нибудь оказывался прав?
Лично у меня сейчас есть проект, в котором требования довольно сильно менялись в прошлом (такой вот заказчик), но уже тогда была большая кодовая база и из-за некоторых изменений приходилось переписывать довольно большие модули.
Сейчас я уже заранее стараюсь писать более гибкий код, ибо чем дальше — тем больше кодовая база и если из-за каждого даже 10го изменения придется ее переписывать, то новые фичи займут сначала недели, потом месяцы, а потом и годы.
Понятно дело, что всегда надо искать золотую середину. Если вы чувствуете что, следующий шаг неизбежен, то можно и заложить определенный запас в архитектуру. Но это уже больше опыт/чутье.
Но часто было так, что ему приходилось обратно выпиливать то, что он напридумывал, т.к. оно мешало активно развивать продукт. Теперь он не любить, когда в проекте валяется ненужный код, который ко всему еще приходится рефакторить при изменении требований. Чему я очень рад.
Но часто было так, что ему приходилось обратно выпиливать то, что он напридумывал, т.к. оно мешало активно развивать продукт
Звучит просто как переусложненный код без достаточной гибкости.
Звучит просто как переусложненный код без достаточной гибкости.Значит что он пытался угадать какими будут бизнес требования через 5 лет — и сделал это неправильно.
Практический подход к «заделу на будущее»: если вы точно знаете кто, когда и для чего вашу «гибкость» будет используете (ответ вполне может быть что и вы — но только, пожалуйста, не «может быть, если рак на горе свистнет», а «когда я займусь багом номер NNNNNN») — идёте и обсуждаете с ними вам «задел».
Если вы точно не знаете — нафиг заделы. Переписать потом будет проще, чем иметь в 10 раз больше года, 90% потенциальной функциональности которого не использует никто и никогда.
Не проблема, если с вашей стороны есть жестко фиксированный интерфейс, а он лишь пишет реализацию, не залезая в остальной проект. Тут главное правильно этот интерфейс составить, чтобы у него не было выбора кроме как пилить простые и понятные в случае чего стороннему разработчику функции
У меня для вас плохие новости…
Рок звезда делает очень важный модуль. Он молодец, реальный спец, хорошо и качественно пишет, мы его очень ценим. НО! Он НИКОГО даже близко не подпускает к своему коду. Как Рик в этой статье. Для нас это большие риски, т.к. проект растет.
А организовать работу так, что-бы код был доступен внутри компании изначально — невозможно? Ну там — общий репозиторий, периодические (возможно даже еженедельные) — обсуждения кода и т.д.?
Но все равно, если у вас есть Рок звезда – будьте осторожны. К ним требуется особый подход.
Просто этот специалист — явно overqualified для данной формы.
Там Рик был таким изобретателем велосипедов и запутанного кода, любителя копи-пасты.
Такие любители «поработать» совсем не редкость.
Нахватают проектов и задач и
Приходилось сталкиваться с подобными трудоголиками, писавшими всё-всё с нуля, полностью
игнорируя уже существующие стандартные библиотеки.
Доводилось и рефакторить их код — выбрасывая классы и файлы, заменяя на пару вызовов
опенсоурсных библиотек.
Я больше согласен с первоначальной статьёй — виноват менеджмент, в том, что не взял этого
«Эйнштейна» под контроль.
Судя по первоначальной статье, чувак просто загрёб всё под себя.
А писал быстро, много и не качественно, и всё с нуля, всё больше зарываясь во второстепенные детали.
а потом гений зарылся.
У автора статьи — та же болезнь. Он считает что остальныеколлеги безграмотные, что менеджмент не умеет и т.д.
Что все кругом в такой ситуации виноваты — все, кроме него самого.
1. Принцип 'У нас нет незаменимых' весьма неприятно работает, если нет внятной документации в объеме хотя бы 90-95% по процессам. И вообще нет внятной организации процессов.
Иначе компанию ждем сюрприз и маленький гешефт™ )
2. Уже все описано в той же книге 'Проект Феникс' — Рик это тот же Брент, только со звездной болезнью.
Если процессы зациклены на таком 'бутылочном горлышке' — это вопрос к адекватности менеджмента, не более того.
Когда в команде есть хотя бы один(больше лучше) знатный разраб это хорошо как и для команды так и для бизнеса. Даже при условии что менее гениальным сотрудником с ним/и будет сложно. Люди ленивы, тщеславны и жадны.
Есть тезис, что им стало лучше, но что оно такое в этом случае «лучше» так и раскрыто.
Рок звезды нужны в стартапах, нужны на этапе создания мега продуктов.
На этапе когда продукт выходит на этап поддержки или ленивого развития, когда основные сложности преодалены — рок звезды не нужны. Вообще
А обычного человека интересует лишь сиюминутное упрощение своей работы, которое не заставит менять привычки или вкладывать много сил в обучение.
Прочитал я оригинальную статью, эту и комментарии. Вот все тут пишут, да и в этой статье все подано так, как будто Рик бедный такой и несчастный, все его нагружали. Вы правда верите, что человек, который умеет планировать, расставлять приоритеты, будет брать на себя больше, чем сможет осилить? Нет конечно, скажете вы, на него это повесили менеджеры. У нас что рабство в ИТ? Дали на месяц работы, сказали сделать за пару дней и мы покорно делаем? Нормальный разработчик сам оценивает задачу и озвучивает сроки. Если такие сроки руководство не устраивают, всегда можно сменить работу. Или у нас в ИТ так сложно ее найти, что стоит держаться за место, где тебя заставляют работать по 12 часов в сутки 7 дней в неделю? Не думаю. Любой разработчик с таким опытом, как у Рика, сможет найти работу за пару недель, а если все происходит ещё и в Долине, то наверняка и быстрее. Рик сам выбрал себе такой режим, вполне возможно, ему действительно хотелось чувствовать себя звездой и быть незаменимым в коллективе. Достаточно прочитать, что он не давал никому править свой код. Код, который ты написал в компании — это собственность компании, за это и платят деньги. И это вроде как должно быть понятно с самого начала. А в конце так и вообще показал признаки мании величия, назвав себя Эйнштейном.
К автору оригинальной статьи также есть несколько вопросов. Почему, когда Рик не являлся на планерки, это не сильно волновало руководство? Чем этот человек там занимался, за что ему платили деньги? Странно, что руководство этот вопрос не беспокоил. Причём продолжалось это достаточно долго. Наводит на мысли, что автор оригинальной статьи либо исказил реальные факты, либо недосказал что-то, либо уровень разгильдяйства в компании был очень высок.
Я думаю, что тут проблемы были с обоих сторон. Проблема Рика в его звездности и желании делать все самому, есть такие перфекционисты, для которых важна чистота кода, а не его расширяемость, поддерживаемость и те задачи, которые он должен решать. Проблема руководства в том, что они не поняли сразу, к чему такой подход может привести и спускали все на тормоза, даже когда "зелёные метрики становились желтыми..." и таа далее. А в итоге удобнее всего было объявить Рика виновным во всех проблемах.
В компании построили схему когда никто толком не работает потому что косяки можно спихнуть на местного вундеркинда и как только его уволили всем пришлось наконец-то перестать тупить.
Когда-то я работал заведующим отделом в одной гос.оргнизации. Проработал там долго – 5 лет. Зарплата была достойной (немного ниже, чем в целом на рынке), но работа мне нравилась. Поэтому работал от души, за эти года сделал очень много для организации. Работа, кстати, была разноплановой – и с техникой повозиться надо, и документы оформить и софт написать.
Но однажды произошел неприятный инцидент. При обновлении техники в бухгалтерии (а это ещё тот геморрой) один из закупленных ПК оказался с браком. Что-то было не в порядке с чипом, и компьютер самопроизвольно выключался через пару часов. Я, естественно, как полагается, оформил замену техники по гарантии. Технику поменяли, но на этот процесс ушло 2 недели. И все эти две недели тетки из бухгалтерии подымали «хай» — мол, как мы будем работать на такой технике, которая ломается. Короче, эти тетки протолкнули вопрос о моем наказании…
Наказал меня директор крайне жестко – не проиндексировал зарплату (мне и дворнику-алкоголику). Я долго жаловался, требовал пересмотреть наказание, но директор остался непреклонен. Я в итоге забил на это дело, так как работа все-таки нравилась мне.
Прошел год. Я усердно, как и прежде, работал. Пришла пора новой индексации зарплаты. И… мне индексируют зарплату на 2% (мне и дворнику-алкоголику).
Я иду к директору, подымаю вопрос – почему такая индексация? Почему у меня зарплата стала как у рядового сотрудника? Он мне в ответ – это мое решение. Я не обламываюсь, выхожу за дверь и сразу пишу заявление на увольнение. В итоге я уволился. Директор так и не поменял решение.
Прошло два года. Я, случайно проходя мимо, зашел проведать бывших коллег. Встретили меня на «ура» — сначала подумали, что я вернулся на прежнюю должность. Тут начался рассказ коллег о том, что было «после меня».
Первой вышла из строя одна вспомогательная установка через две недели после моего ухода (сбились настройки после скачка напряжения). Моим подчиненным восстановить её работу не удалось, т.к. никому до неё не было дела (было, видимо, лень читать трехстраничную инструкцию). С тех пор установка не работала ни разу. Ну, в принципе ладно – установка вспомогательная, на производство практически не влияет.
Коллеги продолжают рассказывать. Через месяц после моего ухода отдел бухгалтерии протолкнул вопрос об обеспечении их отдела высокоскоростным интернетом. Я, кстати, этом вопрос всегда отклонял, т.к. во-первых, скоростной интернет нужен бухгалтерам, чтобы видео в «одноклассниках» смотреть, а во-вторых, нужно тянуть сеть через весь квартал (цена вопроса более 50 000 рублей).
С горем пополам, мои подчиненные провели сеть и, не разобравшись, почему так я сделал, объединили все подсети в одну. В результате все документы и базы бухгалтерии оказались в общем доступе в локальной сети организации. Ну, и через несколько месяцев все это дело «накрылось медным тазом» — кто-то или что-то удалило бухгалтерские базы и ряд документов.
И тут выяснилось, что после моего ухода никто резервных копий не делал. Короче, одного моего подчиненного уволили, базу кое-как через пару месяцев восстановили.
Но это ещё не все. Через год после моего ухода в организацию пришла УБЭП с проверкой и не нашли ни одного документа на технику и софт… До сих пор не понимаю, как организация умудрилась потерять все оригиналы документов (были у директора в сейфе) и копии документов (были у меня в сейфе).
В срочном порядке был нанят ещё один сотрудник, который кое-как восстановил всю документацию и закупил лицензии. Уголовной ответственности удалось избежать. На все мероприятия было потрачено около 150 000 рублей.
После инцидента с документами директор (по подсказке отдела бухгалтерии) решил, что это мои злые происки. Но официально выдвигать мне какие-либо обвинения побоялся, т.к. вдруг нашелся приказ о передаче мною всей документации директору.
И на этом моменте история не заканчивается. Директор дал указание удалить следы моего присутствия в организации. Новый сотрудник, занявший мое место, согласно этому указанию удалил весь софт с рабочей установки, который я писал в течение 5 лет. Как результат, рабочая установка стала работать через раз. Смешно? Смешно, то, что резервные копии до сих пор никто не делал.
После полугода «страданий» с рабочей установкой было решено заменить её на похожую (не новую), но с комплектом готового софта. Цена вопроса – чуть меньше 400 000 рублей.
И вот я сижу и обалдеваю от рассказа коллег. А они выдают последний решающий факт: за место меня в итоге работают 4 человека. Один занимается техникой, второй – документами, третий – софтом, а четвертый — начальник над этим тремя. У каждого зарплата как была у меня и больше… Все, финиш.
Суть этого длинного рассказа не в том, что я какой-то идеальный сотрудник. Нет, я не идеальный сотрудник, я просто любил свою работу. Суть в том, что надо беречь сотрудников, которые любят свою работу и работают.
Про суть рискну сделать добавку:
Суть в том, что надо беречь сотрудников, которые любят свою работу и работают.
+ опасно вести дела с теми, у кого свое эго превыше всякого разума. Ибо только оно (это эго индюка) способно привести к результатам, описанным выше (не признаем свои ошибки любой ценой).
Но это ещё не все. Через год после моего ухода в организацию пришла УБЭП с проверкой и не нашли ни одного документа на технику и софт… До сих пор не понимаю, как организация умудрилась потерять все оригиналы документов (были у директора в сейфе) и копии документов (были у меня в сейфе).
Вы не думали, что они могут быть в доле. Более того, что все свои (госструктура)?
В срочном порядке был нанят ещё один сотрудник, который кое-как восстановил всю документацию и закупил лицензии. Уголовной ответственности удалось избежать. На все мероприятия было потрачено около 150 000 рублей.
Это не так уж и много. По крайней мере для Москвы.
Мораль тут такова, что в ГБУ весьма феодальный подход. Работал. Знаю отчасти изнутри, поэтому нисколько не жалею, что ушёл. У них же, с их слов, за воротами куча страждущих. :)
Не знаю как там с С++ в ядре. Но работать с такими «звёздами» не хочется даже близко.
А вот и памятка:
http://harmful.cat-v.org/software/c++/linus
Только на днях столкнулся с непрошибаемым мнением, что для вхождения в хайтек достаточно аккаунта на Lynda, Udemy или Tutsplus и одного месяца учёбы. При условии, что не ленивый, а ленивым в хайтеке делать нечего! :)
Так что, кто знает, может, и есть такие сверх-вундеркинды, которые за три месяца способны стать незаменимыми… Впрочем, лично я в это не верю.
И у меня тоже история про вкалывание на голом энтузиазме. Но:
Для начала хочу рассказать немного (чуток) о себе: я — самоучка-интроверт. Экставертом являюсь только в подпитии)) Так вот… В недалеком 2007 (женат, есть дочка (а на данный момент: дочка и 2 пацана, еще через 2-3 недели пацанчика ждем)), работая водителем-экспедитором на своей газельке, попался мне диск с 3D Max. Стал его досконально изучать (благо учебник для чайников купил, ютуб тогда не смотрел, или его не было) Хорошо, что с детства любил такой предмет в школе, как «Черчение». Изучение мне далось легко. Через год начал вечерами рендерить сцены для местного челябинского завода. Оффициально на заводе не трудоустроен — только сделка. Заявок мало, потому продолжал работать оффициально водителем-экспедитором но уже не на своем авто (свою старенькую успешно продал)
Так вот. Устроиться куда то с умением рисовать и рендерить в максе до 2012 года я не мог. В Челябинске в те времена и вакансий таких то не было. Были интерьерщики, но я не из них.
И вот настал тот самый день, когда мне позвонили и предложили ту самую работу, о которой я мечтал на минимальную зарплату. Быстро ввели в курс дела и я начал выводить оборудование с фотографии в макс с последующим рендером. Управлялся быстро. Позже за обедом с учредителем компании мне дали понять, что моя ЗП может возрасти в N раз, если увеличишь объемы или как то покажешь себя. А это N раз как раз бы и не помешало, так как на тот момент у меня 2 детей (мальчик и девочка) Условия простые: вкалываешь как ишак. Не вопрос- начал вкалывать, потому как самому интересно. После второго месяца ЗП выросла. Думаю, ок, но нужно еще что-то сделать. В этот момент увольняется веб-мастер (кстати, один из моих друзей с той организации) Он то меня и сподвигнул к изучению модикс эво. Через месяц, после обучения в пространстве интернета и ютуб, я подошел к руководству с решением изменить сайт. Странно, но добро дали. <!___сайт изменили, всем понравилось, прошел 1 год___> После этого выставки, директы и т.д.
Из дизайнера 3d--->заместителя руководителя отдела рекламы и маркетинга
И вот тут то началось:
Я превратился в машину, которая умеет все… 3D — ко мне, коммерческое (в пдф) — ко мне, правки на сайте -ко мне, новую конструкцию на оборудовании, чтобы красиво смотрелось — опять ко мне… Это еще не весь список))) Короче, у меня нервы сдали… Напившись, просто не вышел на след. день. Телефон ломило от звонков… Не удержался — взял. В итоге, дали неделю отпуска на Черном море за счет компании. Если честно — помогло. Новые силы появились.Но для себя решил, что не буду больше ишачить. ЗП после отпуска подняли. Все таки договорился нанять 3д-дизайнера, графического дизайнера и веб-мастера.
Но то что я «сгорел на работе» мне уже было понятно. Энтузиазм пропал, новых идей нет. Продержался еще 1 год, после чего уволился в начале 2015 г. Не хотели отпускать, но и двухнедельной отработки не стали требовать. Отпустили, зная, что я нашел себе применение…
Через полгода решил навестить своих бывших коллег. Организация на грани банкротсва. ЗП задерживают. Меня, в шутку, обвинили в плачевном состоянии компании. Еще через полгода компания не то что обанкротилась — ее просто не стало… За 1 или 2 дня… Кризис или не дальновидное решение руководства — не понятно. Для меня это был шок. Столько сил вложил, а в итоге ноль…
P.S.: К чему это я? Может навеяло, решил поделиться.
P.P.S.: Многие бывшие сотрудники открыли ООО, конкурируя между собой
Столько сил вложил, а в итоге ноль…
Как же ноль? Неужели вернулись к работе водителем-экспедитором?
Потому что из начальной статьи напрямую следует:
— что гуру писал неуправляемый запутанный г*нокод.
— что гуру писал не только бизнес-логику, но и вообще все с нуля.
Мне приходилось иметь дело с похожим человеком. Он полностью блокировал работу, много возмущался, всех обижал. А так же много пил и психовал. Вообще, у него была справка. Так что просчеты менеджеров конечно есть, но мужик был непрофессионален сам по себе, и по сути выгнали его за затягивание сроков.
Кстати, переработка — это не только признак того, что на вас бедного менеджмент навалил уйму задач, это еще и признак того, что может быть, ваши дизайны настолько плохи, что для их фиксации вам надо кучу времени.
в большинстве проблема из-за:
— непонимание руководством процесса разработки программного продукта
— нежелание руководства слушать разработчиков о процессе разработки, потому что они руководство, а ты какой-то там рабочий
Так бывает, все надо успеть за месяц, в полном объеме, чтобы не возиться пол-года, так сказать сократить расходы в х6 раз =)… а потом через 1.5 месяца слышишь: «Твой код — говно» ))
Вы уволили самого талантливого сотрудника. Надеюсь, теперь вы довольны