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