Comments 179
Примадонна не приемлет руководства. Он рассматривают любую попытку руководства как оскорбление, поскольку он выше того, чтобы нести ответственность за свои действия.
Глупейшая ремарка. Как раз нежелание быть руководимым означает желание взять ответственность за свои действия на себя. Люди, боящиеся ответственности, всегда ищут руководящую руку.
Теперь, годы спустя, благодаря многолетним отношениям с основателями компании, он считает своё мнение выше мнения простого менеджера среднего звена.
Еще одна странная ремарка. Мнение о чем? У них разные зоны ответственности. Менеджер должен отвечать за то, как должен функционировать программный продукт, программист за то, какими программными путями этого добиться. Это не вопрос мнений, просто разные зоны компетентности.
Разработчик настолько одержим достижением архитектурной элегантности и совершенства кода, что забывает, что его работа должна приносить пользу бизнесу.
Здесь не может быть противоречий. Каким образом хорошая архитектура и совершенство кода может помешать бизнесу? Хороший код легче дорабатывать и отлаживать, это прямая помощь бизнесу. Если бизнес не понимает, что лучше потратить лишний день на хорошую архитектуру, вместо того, чтобы потом тратить 10 раз по полдня на доработки плохой, думаю «перфекционисту» стоит подыскать более умного бизнесмена.
PS В остальном очень жизненно. Спасибо. =))
Как раз нежелание быть руководимым означает желание взять ответственность за свои действия на себя
Это несвязанные вещи. Человек может противиться любому управлению собой, и при этом сваливать ответственность за свои действия на всех подряд. Пример такого поведения: типичный подросток.
Каким образом хорошая архитектура и совершенство кода может помешать бизнесу?
Хорошее — никак, идеальное/совершенное — тем, что на его воплощение требуется чуть менее, чем бесконечное количество времени.
У меня опыт прямо противоположный — чем более красиво ты делаешь, тем меньше на это требуется времени, потому что реализация идеальной архитектуры происходит легко и естественно, а реализация корявого кода как раз занимает время.
Вы что-то путаете) Коряво пишут обычно, потому что надо быстро. Хорошую архитектуру надо планировать заранее и, в зависимости от размера проекта, это может занимать на порядки разное время. Если у вас получается написать идеальную архитектуру быстрее, чем корявый код, что в принципе невозможно по определению, то вы либо вкладываете другие значения в эти слова, либо лукавите) Есть ещё вариант, что вы не делали действительно больших проектов, потому что разработка архитектуры в большинстве маленьких проектов сводится к разбиению на модули и их сопряжению. В этом случае действительно планирование занимает немного времени, но даже в этом случае, чтобы написать корявый код за большее время, надо сильно постараться.
Если у вас получается написать идеальную архитектуру быстрее, чем корявый код, что в принципе невозможно по определению, то вы либо вкладываете другие значения в эти слова, либо лукавите)Есть еще третий вариант — «написать код» было понято слишком буквально и имеется ввиду именно написание кода. Когда хорошая архитектура уже есть, то хороший код, особенно для сложного проекта, написать вполне может быть быстрее. Проблема именно в том, что для плохого кода не нужн планирование, которое отнимает гораздо больше времени чем собственно реализация.
Каким образом хорошая архитектура и совершенство кода может помешать бизнесу?
Элементарно. Если на них убита куча времени, и дедлайн безнадежно просран, то там уже пофигу, какая хорошая архитектура.
Почему на хорошую архитектуру должна быть убита куча времени? В любом случае это проблема неправильного планирования ресурсов, а не перфекциониста.
Если разработчик допиливает код постоянно, не выдавая релиз, т.к. он ещё не идеален, то его вред бизнесу очевиден. Его идеально отлаживаемы и поддерживаемый код не работает, а значит ничего не приносит.
> В любом случае это проблема неправильного планирования ресурсов, а не перфекциониста.
Часто проблема перфекциониста неправильное планирование ресурсов (например, он не знает что для идеала в его понимании нужно бесконечное количество времени). И единственноправильным вариантом планирования будет отстранение перфекциониста (на старте или после таймаута). На то он и перфекционист, а не хороший разработчик.
> В любом случае это проблема неправильного планирования ресурсов, а не перфекциониста.
Часто проблема перфекциониста неправильное планирование ресурсов (например, он не знает что для идеала в его понимании нужно бесконечное количество времени). И единственноправильным вариантом планирования будет отстранение перфекциониста (на старте или после таймаута). На то он и перфекционист, а не хороший разработчик.
В какой-то момент показалось, что я читаю не о взрослых людях а учебник колониального управления для белых британцев в странах третьего мира.
Меня такое каждый раз печалит.
Очень.
У каждого хорошего менеджера в списке прочитанных книг есть парочка про воспитание деней и общение с ними :)
Не расстраивайтесь, очень хорошо что есть такие статьи по «управлению» программистами
Мне хотелось сразу 3 комментария написать на нее)))
1. Автор как кот которому нечего делать начинает лизать… изучать программистов.
2. Это одна из «техник» как нагнуть программиста, и что даже техничка может управлять программистами.
Кстати про техничку это не шутка, была такая реальная методика и эта бы статья плавно бы вошла туда как отдельная глава )))
3.БРАВО!!! СУПЕР!!!
Чем больше будет таких учений, менеджеров которые им следуют, тем больше будет работы для Программистов и выше будут зарплаты!
Никто не отменял правило озвученное Бруксом несколько десятков лет в его книге «Мифический человеко-месяц».
Если Владельцу или менеджеру нравится гнобить программистов, тем лучше, стОящий и знающий программист может уйти в другую компанию и строить с нуля новую систему, на крайняк сделать свой стартап, а в компании в которой гнобят (нет нет, конечно же управляю программистами <ха-ха 3 раза>), вместо одного наймут 10, которые в конечном итоге угробят систему или будет стогнация.
Если менеджерам нужна «игра в управление», а по факту в гнобление с сокращением зарплаты, то еще существуют фирмы, где на первом месте стоит разработка ПО, его качество, отказоустойчивость, расширяемость, гибкое управление проектом, а не программистами. )))
Первый критерий программиста это его код(!), скорость, профессионализм.
Потом работа в коллективе (тк программист в одиночку писать высокопроизводительные библиотеки, сервисы), умение работать с несколькими программистами над одним проектом. Придерживание стандартам компании в написании кода и т.д. и т.п.
В статье озвучиваются ярлыки, но тот кто их навешивает сидит читает спецификацию по выходным? Дебажит сутки на пролет выискивая неточность? Днем и ночью продумывает архитектуру даже в ущерб своему здоровью?
Тот кто не любит программировать, но идет в программисты за деньгами, не выдержит никакой конкуренции с фанатами-профессионалами. Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО! Пустышка с деньгами и огромным самомнением, что за пару тысяч ему будут лизать ботинки. Может в других сферах это так, но не у программистов к которым приходит волшебная палочка выручалочка -Интернет.
И сейчас все больше и больше команд основное время работает по удаленке.
Пусть менеджеры эту крысиную возню с ярлыками оставят для себя, написав себе эти ярлыки на бейджиках и приколят их к своей груди. )))
А мы будем писать код благодарному работодателю или для своего бизнеса, под пальмами у моря или в том месте где душа поет и из под пальцев выходит код который хочется поцеловать.
Мне хотелось сразу 3 комментария написать на нее)))
1. Автор как кот которому нечего делать начинает лизать… изучать программистов.
2. Это одна из «техник» как нагнуть программиста, и что даже техничка может управлять программистами.
Кстати про техничку это не шутка, была такая реальная методика и эта бы статья плавно бы вошла туда как отдельная глава )))
3.БРАВО!!! СУПЕР!!!
Чем больше будет таких учений, менеджеров которые им следуют, тем больше будет работы для Программистов и выше будут зарплаты!
Никто не отменял правило озвученное Бруксом несколько десятков лет в его книге «Мифический человеко-месяц».
Если Владельцу или менеджеру нравится гнобить программистов, тем лучше, стОящий и знающий программист может уйти в другую компанию и строить с нуля новую систему, на крайняк сделать свой стартап, а в компании в которой гнобят (нет нет, конечно же управляю программистами <ха-ха 3 раза>), вместо одного наймут 10, которые в конечном итоге угробят систему или будет стогнация.
Если менеджерам нужна «игра в управление», а по факту в гнобление с сокращением зарплаты, то еще существуют фирмы, где на первом месте стоит разработка ПО, его качество, отказоустойчивость, расширяемость, гибкое управление проектом, а не программистами. )))
Первый критерий программиста это его код(!), скорость, профессионализм.
Потом работа в коллективе (тк программист в одиночку писать высокопроизводительные библиотеки, сервисы), умение работать с несколькими программистами над одним проектом. Придерживание стандартам компании в написании кода и т.д. и т.п.
В статье озвучиваются ярлыки, но тот кто их навешивает сидит читает спецификацию по выходным? Дебажит сутки на пролет выискивая неточность? Днем и ночью продумывает архитектуру даже в ущерб своему здоровью?
Тот кто не любит программировать, но идет в программисты за деньгами, не выдержит никакой конкуренции с фанатами-профессионалами. Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО! Пустышка с деньгами и огромным самомнением, что за пару тысяч ему будут лизать ботинки. Может в других сферах это так, но не у программистов к которым приходит волшебная палочка выручалочка -Интернет.
И сейчас все больше и больше команд основное время работает по удаленке.
Пусть менеджеры эту крысиную возню с ярлыками оставят для себя, написав себе эти ярлыки на бейджиках и приколят их к своей груди. )))
А мы будем писать код благодарному работодателю или для своего бизнеса, под пальмами у моря или в том месте где душа поет и из под пальцев выходит код который хочется поцеловать.
Боже мой, как вы делаете из мухи слона! Программисты уж какие-то суперлюди по Ницше. Вы можете себе придумывать что угодно, пока спрос на специалистов такой высокий, но по-моему лучше себя не обманывать и просто признать, что мы инженеры, просто в немного специфической сфере, которая отличается от классического инженерного дела (возможность быстро вносить измения, почти моментальный фидбэк).
Да да, я знаю, простая техничка может управлять отделом программистов )))
И еще дополню.
Программирование часто изобретение чего-то нового.
Каждый изобретатель может быть инженером.
Но далеко не каждый инженер может быть изобретателем.
И еще дополню.
Программирование часто изобретение чего-то нового.
Каждый изобретатель может быть инженером.
Но далеко не каждый инженер может быть изобретателем.
Фантазии у Вас и обиды. Как правило изобретатель это плохой инженер который во что-то «тупо верит». Их полно сейчас — с двигателями с супер КПД, альтернотивной физикой и пр.
Да я разве спорю.
Изобретатель конечно плохой инженер, который «тупо верит»
( Блин в мемориз надо этот перл ))) )
Программист конечно же обычный скот который надо поставить в стойло, что бы не брыкался и зарплату не просил, ярлычок навесить и знать как пнуть больнее.
Зарплату в вашей конторе не снижают еще «опущенным звездам»?
Девиз висит «Не заменимых людей нет»?
«Верной дорогой идете товарищи» (с)
И я конечно же фантазер и обижаюсь, на кого, на вас?
Ой рассмешили, только мало. ))))
Как говорят? «Пиши исчо!»
Чем больше будут придерживаться менеджеры этой идеологии тем лучше.
Когда менеджеры сядут в лужу, не прав конечно останется толькоскот программисты, но пусть на грабли наступают и по чаще, может просветление будет. )))
Еще Крылов да-авным давно написал басню Квартет, как раз подходит под ваше управление.
PS:
Программист, когда ему становится не комфортно может сменить релокацию на любой город или страну не выходя из дома. Люди в команде могут не видеть друг друга годами, но при этом слаженно работать.
Пусть ваши менеджеры потешат свое ЧСВ ярлыками и методами «опускания звезд», если им не хватает мозгов управлять командой. Так как при разработке ПО другие ярлыки и оценки применяются.
Так чтопилите пишите Шура, пишите.
Изобретатель конечно плохой инженер, который «тупо верит»
( Блин в мемориз надо этот перл ))) )
Программист конечно же обычный скот который надо поставить в стойло, что бы не брыкался и зарплату не просил, ярлычок навесить и знать как пнуть больнее.
Зарплату в вашей конторе не снижают еще «опущенным звездам»?
Девиз висит «Не заменимых людей нет»?
«Верной дорогой идете товарищи» (с)
И я конечно же фантазер и обижаюсь, на кого, на вас?
Ой рассмешили, только мало. ))))
Как говорят? «Пиши исчо!»
Чем больше будут придерживаться менеджеры этой идеологии тем лучше.
Когда менеджеры сядут в лужу, не прав конечно останется только
Еще Крылов да-авным давно написал басню Квартет, как раз подходит под ваше управление.
PS:
Программист, когда ему становится не комфортно может сменить релокацию на любой город или страну не выходя из дома. Люди в команде могут не видеть друг друга годами, но при этом слаженно работать.
Пусть ваши менеджеры потешат свое ЧСВ ярлыками и методами «опускания звезд», если им не хватает мозгов управлять командой. Так как при разработке ПО другие ярлыки и оценки применяются.
Так что
Это Вы вываливаете свои обидки.
Я консультант и работаю со многими организациями и да я «вершитель судеб» и таких как Вы и менеджмента, с крайне высоким КПД.
Незаменимых, действительно нет. Есть стоимость замены.
Большинство — простые ремесленники, начинающие визжать, когда только достал линейку, для объективных измерений. Устраивающие истерики при увольнении о их незаменимости, а потом отказывающееся забирать трудовую…
Я консультант и работаю со многими организациями и да я «вершитель судеб» и таких как Вы и менеджмента, с крайне высоким КПД.
Незаменимых, действительно нет. Есть стоимость замены.
Большинство — простые ремесленники, начинающие визжать, когда только достал линейку, для объективных измерений. Устраивающие истерики при увольнении о их незаменимости, а потом отказывающееся забирать трудовую…
Я консультантЯ это понял )))
Незаменимых, действительно нет. Есть стоимость заменыЯ про это же.
Очень часто «стоимость замены» IT специалиста может не только о-очень больно ударить по карману владельцев бизнеса, но и уничтожить сам бизнес. И бизнес совершенно не относящийся к IT сфере. А у IT бизнеса риски еще выше при смене ключевых специалистов.
Кто не наступал на эти грабли, пусть наступает, каску им давать не обязательно )))
PS:
Из-за не грамотного админа или из-за не протестированного продукта простой в ОДИН день может вылиться в недополучении прибыли в десятки миллионов рублей.
2-3 дня таких в год и владельцы, которые умеют считать деньги понимают что принять «супер-звезду» с максимальной зарплатной планкой всегда выгоднее, чем иметь 10 середнячков, которые не в зуб ногой, не в…
UFO just landed and posted this here
Завтра м/б война, метеорит, ссора учредителей и продажа бизнеса с выкидыванием на улицу всех, включая «эффективных менеджеров».
Сегодня важно использовать ресурс который у тебя есть и если у тебя более ценный ресурс, то более эффективно его можно использовать. Новые библиотеки, архитектуру, алгоритмы, все что может «Головастик» ( это мой ярлык Специалиста с большой буквы). Что будет потом, то будет, потом и будем решать проблемы которые будут, а не которые мы придумываем в своей голове. Винтики нужны на конвейере, саппорте продукта, разработке мелких фич, но не на архитектуре проекта и не на ключевых ветках.
Ведь информационная разработка и поддержка это ряд методологий и правил сугубо технических. Если для менеджера важен продукт, его качество, расширяемость, поддержка, продвижение — это один порядок правил и методик.
Если для менеджера важно как выглядят IT специалисты, их манера речи, распорядок дня, стиль общения, их социальная мотивация то это другой ряд правил и методик, менеджеров которые бит от байта не отличают. Они с этими методиками хороши когда уже есть продукт с «жировой прослойкой» и устоявшаяся команда. Какое то время они будут управлять, могут даже увеличиться продажи, но в конечном итоге они обескровят команду, снизят мотивацию разработчиков и свалят на новое место, а контора за-агнется ибо Специалисты — штучный продукт. И даже высоко классному специалисту нужно время «въехать» во все тонкости существующего продукта. И срок «въезда» идет на месяцы, а ему зарплату все это время платят (возможно больше, чем ушедшему специалисту), а продукт стоит или клепаются только заплатки.
Для стартапа, когда надо творить их методика не подойдет, потому что продукт всегда штучный и в нем заложено все понимание главного разработчика (ов), как оно должно быть. И от уровня компетенции основного разработчика напрямую зависит жизнь продукта. Кто будет делать скелет? Команда винтиков или Головастик? Головастик в данном случае предпочтительней с любой стороны, как с финансовой, так и с технической. Да с ними трудно, да тяжело, но выхлоп результата значительно больше чем от винтиков.
Вот «эффективному менеджеру/консультанту» дать Х денег и срок, набрать команду, сделать продукт (все циклы силами набранной командой). Что бы он не пришел консультировать как руководить в команду, а пришел создавать ее с нуля. То в его голове что то бы и прояснилось.
Но только не подумайте, я не отговариваю от методологии технички с изучением проблемных личностей разработчиков, боже упаси.
Наоборот, пусть побольше таких менеджеров будут, после них растет зарплата. Потому что те кто считает деньги, они готовы принять на работу хоть дьявола с чертями, лишь бы увеличился доход.
А менеджеры пусть играют в свои крысиные игры )))
Сегодня важно использовать ресурс который у тебя есть и если у тебя более ценный ресурс, то более эффективно его можно использовать. Новые библиотеки, архитектуру, алгоритмы, все что может «Головастик» ( это мой ярлык Специалиста с большой буквы). Что будет потом, то будет, потом и будем решать проблемы которые будут, а не которые мы придумываем в своей голове. Винтики нужны на конвейере, саппорте продукта, разработке мелких фич, но не на архитектуре проекта и не на ключевых ветках.
Ведь информационная разработка и поддержка это ряд методологий и правил сугубо технических. Если для менеджера важен продукт, его качество, расширяемость, поддержка, продвижение — это один порядок правил и методик.
Если для менеджера важно как выглядят IT специалисты, их манера речи, распорядок дня, стиль общения, их социальная мотивация то это другой ряд правил и методик, менеджеров которые бит от байта не отличают. Они с этими методиками хороши когда уже есть продукт с «жировой прослойкой» и устоявшаяся команда. Какое то время они будут управлять, могут даже увеличиться продажи, но в конечном итоге они обескровят команду, снизят мотивацию разработчиков и свалят на новое место, а контора за-агнется ибо Специалисты — штучный продукт. И даже высоко классному специалисту нужно время «въехать» во все тонкости существующего продукта. И срок «въезда» идет на месяцы, а ему зарплату все это время платят (возможно больше, чем ушедшему специалисту), а продукт стоит или клепаются только заплатки.
Для стартапа, когда надо творить их методика не подойдет, потому что продукт всегда штучный и в нем заложено все понимание главного разработчика (ов), как оно должно быть. И от уровня компетенции основного разработчика напрямую зависит жизнь продукта. Кто будет делать скелет? Команда винтиков или Головастик? Головастик в данном случае предпочтительней с любой стороны, как с финансовой, так и с технической. Да с ними трудно, да тяжело, но выхлоп результата значительно больше чем от винтиков.
Вот «эффективному менеджеру/консультанту» дать Х денег и срок, набрать команду, сделать продукт (все циклы силами набранной командой). Что бы он не пришел консультировать как руководить в команду, а пришел создавать ее с нуля. То в его голове что то бы и прояснилось.
Но только не подумайте, я не отговариваю от методологии технички с изучением проблемных личностей разработчиков, боже упаси.
Наоборот, пусть побольше таких менеджеров будут, после них растет зарплата. Потому что те кто считает деньги, они готовы принять на работу хоть дьявола с чертями, лишь бы увеличился доход.
А менеджеры пусть играют в свои крысиные игры )))
У вас совершенно нездоровые фантазии, выдающие в вас комплекс неудачника. Программист — обычный ремесленник, типа электрика, рядовой персонал организации, замена которых на другие стоит весьма немного. Не более того. Только почему то многие из них настолько уязвлены этим фактом, что в своей голове выстраивают воображаемые миры, в которых на них держится все.
Я рад за ваши «здоровые» фантазии и ваш комплекс удачника )))
Если серьезно, то с точки зрения профессионализма есть градации и вы их знаете. Но сравнивать программиста и электриком в офисе просто глупо.
Любой мужчина в офисе может поменять розетку или лампочку от директора до дворника. Но посадите этих же мужчин за комп и пусть они сделают по ТЗ продукт. Вот и весь ответ.
Есть конечно конторы в которых программисты ремесленники, но в которых написаны тонны кода и применяются типовые решения или на двери табличка «Программист», а по факту за ней работает сисадмин.
И если у вас все работает и разрабатывать ничего не надо, я вам открою секрет. Вы можете уволить всех программистов и эффективных менеджеров в куче и забыть про них как страшный сон. )))
Если серьезно, то с точки зрения профессионализма есть градации и вы их знаете. Но сравнивать программиста и электриком в офисе просто глупо.
Любой мужчина в офисе может поменять розетку или лампочку от директора до дворника. Но посадите этих же мужчин за комп и пусть они сделают по ТЗ продукт. Вот и весь ответ.
Есть конечно конторы в которых программисты ремесленники, но в которых написаны тонны кода и применяются типовые решения или на двери табличка «Программист», а по факту за ней работает сисадмин.
И если у вас все работает и разрабатывать ничего не надо, я вам открою секрет. Вы можете уволить всех программистов и эффективных менеджеров в куче и забыть про них как страшный сон. )))
Сравнивать программиста и электрика в офисе можно и нужно.
С точки зрения владельца бизнеса и тот, и другой — обычные наемные рабочие.
А что — электрик, это только лампочку менять? Про силовые кабели в 6кв что-нибудь слышали? В некоторых офисах разобраться в проводке и сделать так, чтобы все не сгорели, куда сложнее, чем по заранее известным алгоритмам писать программы.
Как вы относитесь к другому офисному персоналу? Офис-менеджер, например, либо HR?
С точки зрения владельца бизнеса и тот, и другой — обычные наемные рабочие.
А что — электрик, это только лампочку менять? Про силовые кабели в 6кв что-нибудь слышали? В некоторых офисах разобраться в проводке и сделать так, чтобы все не сгорели, куда сложнее, чем по заранее известным алгоритмам писать программы.
Как вы относитесь к другому офисному персоналу? Офис-менеджер, например, либо HR?
Отвечу почти по Маршаку:
Люди разные нужны, Люди разные важны.
И хороший HR и хороший электрик, как ген.дир и менеджер проекта ценны сами по себе. Но хороших специалистов к сожалению мало. А хороший специалист, он знает себе цену и не каждый будет терпеть подковерные гнобления.
И мне нравятся методологии которые раскрывают потенциал, позволяют более эффективно работать.
Ведь построение более эффективной работы IT отдела это более интереснее и полезнее, чем составлять список животных у себя в отделе и организовывать дрессировочные мероприятия.
Как то так.
Люди разные нужны, Люди разные важны.
И хороший HR и хороший электрик, как ген.дир и менеджер проекта ценны сами по себе. Но хороших специалистов к сожалению мало. А хороший специалист, он знает себе цену и не каждый будет терпеть подковерные гнобления.
И мне нравятся методологии которые раскрывают потенциал, позволяют более эффективно работать.
Ведь построение более эффективной работы IT отдела это более интереснее и полезнее, чем составлять список животных у себя в отделе и организовывать дрессировочные мероприятия.
Как то так.
Любой мужчина в офисе может поменять розетку или лампочку от директора до дворникаЯ не умею менять розетки. Разрабатываю продукт, которым пользуется половина населения Земли.
Не передёргивать, пожалуйста. Быть воспитателем в детском саду (менеджером) очень непростая задача. Не знаю какие вы задачи решаете, но я не вижу что такого "изобретательного" в том, чтобы дёрнуть за пару АПИ в правильной последовательности. Зато вижу, что надо это протестировать, написать логи и объяснить в документации почему надо дергать за эти два, а не те; что всегда и делали инженеры.
Ну, наконец-то.
Автор, спасибо вам душевное за статью.
Спасибо — по нескольким причинам.
99% статей о разработчиках в контексте управления можно свести к одному тезису: “Как тяжело жить/решать задачи/доставлять ценность разрабу в условиях постоянно сопровождающих его внешних, отвлекающих факторов”.
Я, безусловно, чуть-чуть утрирую, но, почему-то, в подавляющем большинстве таких статей суть сводится к тому, как тяжело именно программисту. И задачи, чаще всего, не решаются или решаются с трудом, поскольку все время есть что-то, что отвлекает/не дает работать.
Причем, во многих из таких статей, как правило, виноват менеджер/бизнес/ или стейкхолдер, не пишущий код, а творящий вокруг себя хаос и разнообразный “микроменеджмент”.
А между тем, в адрес не-разработчика летят так им любимые “Я это делать не буду!”, “У меня все работает!”, “Ненене, мне пораньше уйти нужно — завтра задачки перетащу в code/review” и еще куча приевшихся, остоездивших фразочек из очередного стикерпака в телеграмме.
Одним словом — редко можно “проблемные статьи” о самих мастерах кода.
Это причина, скажем так, лирическая — о наболевшем.
И, поверьте мне, тут не работают аргументы в стиле “Да это просто чувак с нормальными кодерами работать не умеет, вот и слышит это постоянно”. Не работают т.к. с такими вот фразочками сталкивался далеко не один мой коллега из стана pm’ов, сейлзов, аналитиков и прочего так некоторыми нелюбимого комьюнити “не-программистов”.
Далее — о комментариях выше.
Уважаемый, AWSVladimir. Вас послушать/почитать, так это получается что у нас каждый 2й, если не 1й разраб — гений пера и кода, за которым просто очереди стоят и бизнес их носит на руках.
Естественно. Менеджер — это такая смесь интерфейса, вашей личной секретарши-напоминалки и пожаротушителя. Он — ничтожество. Просто потому что код не пишет.
Можно просто сказать: “Ты — менеджер? Иди пол мой и составляй свои доки, общайся на переговорах! Ты же — из стана бизнеса, подлец!”.
Вот здорово, правда? Вы же на работу ходите/растите свой бизнес исключительно ради кода, верно? ЗП/прибыль тут максимум на третьем месте.
Позвольте, а кто бегает и улаживает косяки программиста, когда баг на баге? Кто согласовывает переносы срока и новые “подводные камни”, которые не были оговорены разработчиком, что называется, на берегу?
Конечно, всего не распознаешь заранее и не продумаешь. Так-то оно так. Только вот какая штука:
1. Обычно за описанное вами и платят деньги. Если речь идет о труде и задачах программиста. Это называется — зарабатывать деньги. Продумывать архитектуру (ой-ой-ой) в ущерб своему здоровью.
Вы не поверите, но в свой выходной/больничный/день свадьбы/похорон любимого котика руководитель проекта тоже может приходить в офис или, болея, с сизым горлом читать и писать доки, пересогласовывать новые сроки, улаживать тут и там возникающие пожары, просто потому что кто-то из ведущих программистов думал, что подойдет вот такое решение, а оказалось — что это не решение, а говно. А кроме того, там вообще айсберг пилить нужно.
За эту работу точно также платят деньги, как и вам.
А еще деньги платят за неудачные дни. Это когда исполнители косячат и нужно что-то порешать, как говорится, in-real-time. Потому что виноват же у нас, прежде всего, не исполнитель. А тот, кто так напланировал и надоговаривался. Просто по той причине, что “ПРОГРАММИСТ-НЕ-СОВЕРШАЕТ-ОШИБОК”.
Да, у нас каждый второй — Ричард Хэндрикс с потенциально прорывной идеей и соткой пройденных посевных раундов. Ну вот сейчас, еще чуть-чуть, позвонит по скупе Уоррен Баффет или Юрий Мильнер и скажет: “Дружище! У нас для тебя ярд завалялся! Нам очень нужен очередной notepad! Это просто бомба!”.
Оукеееееей.
Г-споди, что вам за менеджеры-то попадались.
Вероятно, вы лучше меня знаете, что любой бизнес — это, прежде всего бизнес. Фундаментальная задача любого бизнеса — каким бы технологичным и легаси-ориентированным (уж простите за каламбур) он бы ни был — прибыль. Это банально, пыльно, пошло и зазорно, но это просто факт. Исходя из этого, в корне неверно полагать, что больше чем к 3-5% компаний в мире есть практически неисчерпаемые ресурсы и космический объем терпения у акционеров/собственников/наемного топа, который может бесконечно переносить выпуск в прод “гениальной архитектуры ради архитектуры”.
Не хочется придираться и занудствовать, но…… откуда такое мнение? Есть пруфы? Все больше и больше по сравнению с чем/когда?
Я руководствуясь ровно такой же логикой могу утверждать, что еще лет 10-15 и появятся наконец решения, которые позволят создавать функционал движением пальца!
И нам больше не придется писать бесконечные доки и терпеть этих наглецов, которые понакодили вот-этого-вот-всякого! Просто потому что грядет время святых Цукербринов, которые вернут все на круги своя!
И, напоследок.
Вам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?
Ну….просто так получается, что кто-то занимается решением конкретных задач и использованием технологий, а кто-то — планированием, распределением ресурсов, контролем и результатами производства?
Форд был не дурак, вероятно. И, возможно, вспоминать это в очередной раз было бы глупо, если бы это не было так актуально по сей день.
А вас послушать: ежкин кот, разработчик — это самая важная деталь организма под названием “Бизнес”.
Без фактических исполнителей, естественно, никакое производство, ни один механизм не сдвинется — это факт. Просто не стоит недооценивать и преуменьшать роль тех, кто по стечению обстоятельств не роется в коде.
А то создается ощущение, что вы — это один из персонажей описанных в статье.
Автор, спасибо вам душевное за статью.
Спасибо — по нескольким причинам.
99% статей о разработчиках в контексте управления можно свести к одному тезису: “Как тяжело жить/решать задачи/доставлять ценность разрабу в условиях постоянно сопровождающих его внешних, отвлекающих факторов”.
Я, безусловно, чуть-чуть утрирую, но, почему-то, в подавляющем большинстве таких статей суть сводится к тому, как тяжело именно программисту. И задачи, чаще всего, не решаются или решаются с трудом, поскольку все время есть что-то, что отвлекает/не дает работать.
Причем, во многих из таких статей, как правило, виноват менеджер/бизнес/ или стейкхолдер, не пишущий код, а творящий вокруг себя хаос и разнообразный “микроменеджмент”.
А между тем, в адрес не-разработчика летят так им любимые “Я это делать не буду!”, “У меня все работает!”, “Ненене, мне пораньше уйти нужно — завтра задачки перетащу в code/review” и еще куча приевшихся, остоездивших фразочек из очередного стикерпака в телеграмме.
Одним словом — редко можно “проблемные статьи” о самих мастерах кода.
Это причина, скажем так, лирическая — о наболевшем.
И, поверьте мне, тут не работают аргументы в стиле “Да это просто чувак с нормальными кодерами работать не умеет, вот и слышит это постоянно”. Не работают т.к. с такими вот фразочками сталкивался далеко не один мой коллега из стана pm’ов, сейлзов, аналитиков и прочего так некоторыми нелюбимого комьюнити “не-программистов”.
Далее — о комментариях выше.
Уважаемый, AWSVladimir. Вас послушать/почитать, так это получается что у нас каждый 2й, если не 1й разраб — гений пера и кода, за которым просто очереди стоят и бизнес их носит на руках.
Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО!
Естественно. Менеджер — это такая смесь интерфейса, вашей личной секретарши-напоминалки и пожаротушителя. Он — ничтожество. Просто потому что код не пишет.
Можно просто сказать: “Ты — менеджер? Иди пол мой и составляй свои доки, общайся на переговорах! Ты же — из стана бизнеса, подлец!”.
Вот здорово, правда? Вы же на работу ходите/растите свой бизнес исключительно ради кода, верно? ЗП/прибыль тут максимум на третьем месте.
В статье озвучиваются ярлыки, но тот кто их навешивает сидит читает спецификацию по выходным? Дебажит сутки на пролет выискивая неточность? Днем и ночью продумывает архитектуру даже в ущерб своему здоровью?
Позвольте, а кто бегает и улаживает косяки программиста, когда баг на баге? Кто согласовывает переносы срока и новые “подводные камни”, которые не были оговорены разработчиком, что называется, на берегу?
Конечно, всего не распознаешь заранее и не продумаешь. Так-то оно так. Только вот какая штука:
1. Обычно за описанное вами и платят деньги. Если речь идет о труде и задачах программиста. Это называется — зарабатывать деньги. Продумывать архитектуру (ой-ой-ой) в ущерб своему здоровью.
Вы не поверите, но в свой выходной/больничный/день свадьбы/похорон любимого котика руководитель проекта тоже может приходить в офис или, болея, с сизым горлом читать и писать доки, пересогласовывать новые сроки, улаживать тут и там возникающие пожары, просто потому что кто-то из ведущих программистов думал, что подойдет вот такое решение, а оказалось — что это не решение, а говно. А кроме того, там вообще айсберг пилить нужно.
За эту работу точно также платят деньги, как и вам.
А еще деньги платят за неудачные дни. Это когда исполнители косячат и нужно что-то порешать, как говорится, in-real-time. Потому что виноват же у нас, прежде всего, не исполнитель. А тот, кто так напланировал и надоговаривался. Просто по той причине, что “ПРОГРАММИСТ-НЕ-СОВЕРШАЕТ-ОШИБОК”.
… на крайняк сделать свой стартап
Да, у нас каждый второй — Ричард Хэндрикс с потенциально прорывной идеей и соткой пройденных посевных раундов. Ну вот сейчас, еще чуть-чуть, позвонит по скупе Уоррен Баффет или Юрий Мильнер и скажет: “Дружище! У нас для тебя ярд завалялся! Нам очень нужен очередной notepad! Это просто бомба!”.
Если менеджерам нужна «игра в управление», а по факту в гнобление с сокращением зарплаты, то еще существуют фирмы, где на первом месте стоит разработка ПО, его качество, отказоустойчивость, расширяемость, гибкое управление проектом, а не программистами. )))
Оукеееееей.
Г-споди, что вам за менеджеры-то попадались.
Вероятно, вы лучше меня знаете, что любой бизнес — это, прежде всего бизнес. Фундаментальная задача любого бизнеса — каким бы технологичным и легаси-ориентированным (уж простите за каламбур) он бы ни был — прибыль. Это банально, пыльно, пошло и зазорно, но это просто факт. Исходя из этого, в корне неверно полагать, что больше чем к 3-5% компаний в мире есть практически неисчерпаемые ресурсы и космический объем терпения у акционеров/собственников/наемного топа, который может бесконечно переносить выпуск в прод “гениальной архитектуры ради архитектуры”.
И сейчас все больше и больше команд основное время работает по удаленке.
Не хочется придираться и занудствовать, но…… откуда такое мнение? Есть пруфы? Все больше и больше по сравнению с чем/когда?
Я руководствуясь ровно такой же логикой могу утверждать, что еще лет 10-15 и появятся наконец решения, которые позволят создавать функционал движением пальца!
И нам больше не придется писать бесконечные доки и терпеть этих наглецов, которые понакодили вот-этого-вот-всякого! Просто потому что грядет время святых Цукербринов, которые вернут все на круги своя!
И, напоследок.
Вам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?
Ну….просто так получается, что кто-то занимается решением конкретных задач и использованием технологий, а кто-то — планированием, распределением ресурсов, контролем и результатами производства?
Форд был не дурак, вероятно. И, возможно, вспоминать это в очередной раз было бы глупо, если бы это не было так актуально по сей день.
А вас послушать: ежкин кот, разработчик — это самая важная деталь организма под названием “Бизнес”.
Без фактических исполнителей, естественно, никакое производство, ни один механизм не сдвинется — это факт. Просто не стоит недооценивать и преуменьшать роль тех, кто по стечению обстоятельств не роется в коде.
А то создается ощущение, что вы — это один из персонажей описанных в статье.
ЕсВам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?
Вот Вы реально в теме и реально крутитесь где создается ПО.
Я хотел сказать, что эта статья — крысиная возня и не имеет ничего общего с реальной разработкой. Программист — царь и бог на своем участке. Постановщик задач, тех лид на своем участке царь и бог, так же хелперы, тестировщики, даже тех.поддержка важна и часто от нее идут идеи оптимизации софта. И просто замечательно если на каждом участке есть Головастики.
Любая часть важна и требует уважения и благодарности, а не методологии «У них получился продукт, расправили плечи, улыбаются ждут что им повысят зарплату? Что они возомнили? Петухи, козлы, коалы (все они в верху на картинке), да вы же скот. В стойло скот, в стойло!»
Я про это.
У реальных Менеджеров работы выше крыши.(далее с большой буквы я говорю о монстрах-титанах-Менеджерах на чьих плечах лежит вся ответственность за проект) И своим я благодарен до земли. Сколько они работы проворачивают утрясая эти требования, хотелки, сколько пустой болтовни через них проходит, а на выходе только нужная выжимка необходимая для создания ПО.
На этом этапе Менеджер царь и бог, и конечно намного важнее любого программиста в команде, так как он задает основной вектор, оценивает рынок, затраты, риски. Программисты лишь исполнители. Да они боги на своем участке, но только в своем. И они не выше и не главнее Менеджеров, я хотел сказать что НИКТО это «крысиный менеджер». Он не то что в подметки не годится Менеджеру, это просто не совместимые вещи которые нельзя сравнивать.
И я глубоко уважаю Менеджеров с большой буквы которые выдают постановку как конфетку. У меня есть проекты на разработку которыми я восхищаюсь уже более 10 лет как они написаны, в них нет ни строчки кода, ни одного названия таблицы, но которое так написаны, что я ими восхищаюсь и я знаю, что если бы я захотел так грамотно и скурпулезно написать, я бы не написал. Я технарь, максимум тех.ТЗ на разработку.
Вот к Менеджерам я испытываю огромное уважение и понимаю «за что» им платят. Но я презираю «крысиных менеджеров», которые играют в свои социальные игры, напрочь не видят технической части. (прокомментирую, что бы опять не поняли привратно, техническую часть может видеть Менеджер гуманитарий, а «крысиный менеджер» может быть и с тех.дипломом их отличие Менеджер душу вкладывает в проект как в своего ребенка, а «крысиного менеджера» интересует только социальная возня).
Все евреи жадные, а американцы тупые, гуманитарии не могут мыслить логично, женщины не умеют пользоваться молотком. Куча каких-то штампов. Для комичной статьи написанно слишком серьезно. Для серьезной статьи написанно слишком глупо.
Чтобы круг замкнулся в каждой статье этого цикла, описывающей следующий уровень иерархии, надо бы иметь отдельный повторяющийся стереотип персонажа: Доверяющий Стереотипным Описаниям в Управлении Персоналом.
Когда какой-то набор стереотипов, например, поведенческих или вкусовых, привязывают к национальности, полу, расе, образованию — то есть характеристикам, совершенно сторонним по отношению к поведению или вкусам — это глупость.
Когда просто некое множество людей дробится на подмножества в соответствии с проявляемыми поведенческими паттернами — действительно наблюдаемыми среди этого множества! — это нормально.
То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.
Говорить, что россияне в НГ делятся на тех, кто ест оливье потому, что нравится, кто ест потому, что традиция, и тех, кто вообще не ест — вполне себе корректно.
Когда просто некое множество людей дробится на подмножества в соответствии с проявляемыми поведенческими паттернами — действительно наблюдаемыми среди этого множества! — это нормально.
То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.
Говорить, что россияне в НГ делятся на тех, кто ест оливье потому, что нравится, кто ест потому, что традиция, и тех, кто вообще не ест — вполне себе корректно.
UFO just landed and posted this here
Делить по паттернам поведения тоже не верный подход.
Все люди делятся на две категории: те, у кого револьвер заряжен, и те, кто копают. Копай.
Я ем оливье когда я хочу его есть. Т.е. преодически, меня нельзя отнести ни к какой категории. Я использую новые технологии, переодически. Довожу до идеала код переодичекски. Проявляю оптимизм или пессимизм тоже перодически и.т.д. стараюсь всегда смотреть по ситуации, относить меня к какой-то категории нельзя. А к чему призывает эта статья — увидели паттерн поведения человека. Поставьте на нем клеймо. И по этому клейму применяйте решение.
Все люди делятся на две категории: те, кто мыслит стериотипами, и те, кто умеют думать. Копай.
Правильно — перИодически. Простите, но многократное повторение «переодически/перодически» с вашей стороны — это уже не опечатки.
Спасибо, что поправили. Тут это сделано скорее умышленно. Проверять грамотность написанного текста также можно периодически. Если есть возможность потратить на это время. Мне это дается сложнее, но это однако не значит, что я не могу написать текст без ошибок. А если верить авторам вышеизложенной статьи то я «безграмотный».
То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.
Отчего же? Почти все едят — не поголовно, конечно, но подавляющее большинство-таки едят.
Глупость — это говорить, что в России медведи по улицам ходят с балалайками, а Россию в иностранных фильмах показывать с музыкальным бэкграундом в виде мелодии баяна или балалайки непонятного происхождения. Но и та глупость по незнанию чужой культуры, наши стереотипные представления о других культурах будут выглядеть в их глазах не меньшей глупостью.
UFO just landed and posted this here
Ну тут уже надо быть занудой и делать уяснения для всех сторон, скажем:
— большинство, это когда 40% едят оливье, 20% спят в оливье, 10% затрудняются ответить (раз на раз не приходится) и 30% не едят оливье.
Т.е. логике не будет никакого противоречия, если даже только эти 40% стабильно едят оливье на НГ — все равно получается самая большая группа из прочих остальных.
Если спросоня я не прав — прошу извинить.
— большинство, это когда 40% едят оливье, 20% спят в оливье, 10% затрудняются ответить (раз на раз не приходится) и 30% не едят оливье.
Т.е. логике не будет никакого противоречия, если даже только эти 40% стабильно едят оливье на НГ — все равно получается самая большая группа из прочих остальных.
Если спросоня я не прав — прошу извинить.
UFO just landed and posted this here
Некомпетентный
…
Возможность исправления: нет
Тут меня, как человека с синдромом самозванца, ощутимо покоробило.
а вы уверены, что у вас просто синдром?
Судя по дальнейшему описанию возможность исправления здесь не свойство характерное для этого паттерна, а необходимое условие. Вот когда некомпетентный И без возможности исправления, то тогда — так. Потому что очевидно что это не может быть правдой в общем случае — любой программист когда-то был не компетентен, вроде бы еще не было человека родившегося со знанием ассемлерных инструкций, например.
Так как m1rko не отвечает, продублирую своё сообщение здесь:
Я думаю, «aspiring manager» в данном случае не «честолюбивый менеджер» (он ещё не менеджер, а разработчик всё же), а «стремящийся стать менеджером» или «метящий в менеджеры».
Забейте в Google Translate «aspiring» — первое определние слова и пример:
>«directing one's hopes or ambitions toward becoming a specified type of person.
>»an aspiring artist""
Очередь пальцев в небо. Всё зависит от задачи, организации работы и погоды на Марсе.
Стороны разработчика софта и эксплуатации софта (часто с доработками) требуют совершенно разных подходов. Разный софт требует разных подходов (для примера можно выполнить мысленный эксперимент сравнивая oracle db, поделку на php и 1С). Кроме того, есть вполне актуальный торгуемый софт, чуть более чем полностью состоящий из легаси кода (тот же oracle db).
Например, даже в рамках одной компании могут быть условия, когда «прима» сильно мешает или наоборот, эффективно спасает проект (особенно, если техническая цена спасения проекта не особо важна). Впрочем, по каждому типу разработчика в этой классификации я могу привести как подтверждающий, так и опровергающий пример (видимо, как и большинство реально практикующих управленцев в ит).
Впрочем, статья хорошо написана и неплохо переведена. Как развлекательное чтиво, которое к тому же заставляет немного подумать — отлично.
Стороны разработчика софта и эксплуатации софта (часто с доработками) требуют совершенно разных подходов. Разный софт требует разных подходов (для примера можно выполнить мысленный эксперимент сравнивая oracle db, поделку на php и 1С). Кроме того, есть вполне актуальный торгуемый софт, чуть более чем полностью состоящий из легаси кода (тот же oracle db).
Например, даже в рамках одной компании могут быть условия, когда «прима» сильно мешает или наоборот, эффективно спасает проект (особенно, если техническая цена спасения проекта не особо важна). Впрочем, по каждому типу разработчика в этой классификации я могу привести как подтверждающий, так и опровергающий пример (видимо, как и большинство реально практикующих управленцев в ит).
Впрочем, статья хорошо написана и неплохо переведена. Как развлекательное чтиво, которое к тому же заставляет немного подумать — отлично.
Вообще-то есть наука психология, и есть психологи и психотерапевты. Желаете поразвлекаться — можете почитать подобные статьи и начать обзывать других людей новыми словами. Для решения вопросов полезнее обращаться к специалистам. Тж. полезнее отказаться от наклеивания ярлыков.
Забавная статья. Я хоть и не ITшник но много лет занимаюсь персоналом и НОТ.
Соглашусь с BD9 — заниматься подобным должен специалист. Только не психолог — их квалификация притча во языцех. Они, скорее, натурфилософы и пишут подобную галиматью.
Правы в общем то все комментаторы.
Например «Честолюбивый менеджер», из всего написанного, верно только:
Остальное — неверно, например, это может быть и разочаровавшийся «идеалист», (по этому предложенный пример работы с «идеалистом» спорен — может привести к подобным изменениям).
А выдавать плохой код (плохо работать)он может из-за исчезновения мотивации. Как из-за смены парадигмы, так и из-за выгорания.
«Солдатом» становятся многие после 30 — это связанно в основном с некоторыми физиологическими изменениями в человеке и частично с социальными.
Люди не должны работать сутками — это физиологически не возможно. Резерв по способности к переработкам индивидуален и то же не безграничен. В таких случаях проблема всегда в менеджменте, но в любой отрасли управленцев наказывают не охотно.
Это не касаясь таких проблем, как «отыгрыш» наказанных на подчинённых.
Метод внеочередных отпусков неплох, но работает только на уставших людях. На выгоревшем это не работает, с ним, лучше попрощаться.
Ну и т.д.
Соглашусь с BD9 — заниматься подобным должен специалист. Только не психолог — их квалификация притча во языцех. Они, скорее, натурфилософы и пишут подобную галиматью.
Правы в общем то все комментаторы.
Например «Честолюбивый менеджер», из всего написанного, верно только:
Невозможно решить проблему честолюбивого менеджера, потому что он уже сделал чёткий карьерный выбор
Остальное — неверно, например, это может быть и разочаровавшийся «идеалист», (по этому предложенный пример работы с «идеалистом» спорен — может привести к подобным изменениям).
А выдавать плохой код (плохо работать)он может из-за исчезновения мотивации. Как из-за смены парадигмы, так и из-за выгорания.
«Солдатом» становятся многие после 30 — это связанно в основном с некоторыми физиологическими изменениями в человеке и частично с социальными.
Люди не должны работать сутками — это физиологически не возможно. Резерв по способности к переработкам индивидуален и то же не безграничен. В таких случаях проблема всегда в менеджменте, но в любой отрасли управленцев наказывают не охотно.
Это не касаясь таких проблем, как «отыгрыш» наказанных на подчинённых.
Метод внеочередных отпусков неплох, но работает только на уставших людях. На выгоревшем это не работает, с ним, лучше попрощаться.
Ну и т.д.
Метод внеочередных отпусков неплох, но работает только на уставших людях. На выгоревшем это не работает, с ним, лучше попрощаться.
Поматросить и бросить? Ну такое… оставшаяся команда быстро словит мессендж что ждёт их самих в будущем, когда они сломаются и выгорят.
Выгоревший сотрудник будет портить атмосферу. Т.к. находиться в депрессии, имеет низкую производительность труда и много брака. Если команда полна альтруистов, могут скинуться ему на годовалый отпуск (и это минимум). Никто ж не говорит о том, что его надо «выкинуть». Человеку надо выдать все положенные выплаты по полной. В РФ это 3 мес. з/п + что набежало по отпускным.
могут скинуться ему на годовалый отпуск (и это минимум)
Человеку надо выдать все положенные выплаты по полной. В РФ это 3 мес. з/п + что набежало по отпускным
Т.е. уволить с явным осознанием того, что он не сможет позволить себе полное восстановление на выходное пособие?
Да.
В идеале, в организации должен быть специалист, который поставляет информацию менеджменту о состоянии сотрудников, что бы не допускать подобного.
В идеале, в организации должен быть специалист, который поставляет информацию менеджменту о состоянии сотрудников, что бы не допускать подобного.
Спасибо за честность.
Если бы я работал в вашей компании, то не позволил бы себе никаких переработок и авралов даже под угрозой увольнения.
Если бы я работал в вашей компании, то не позволил бы себе никаких переработок и авралов даже под угрозой увольнения.
Это из серии: когда нам от вас что-то надо, что мы команда и вообще уже давно в коммунизме и коллективизме.
Когда вам что-то надо (или вы не нужны)- это просто бизнес, ничего личного.
Когда вам что-то надо (или вы не нужны)- это просто бизнес, ничего личного.
Я работаю в разных компаниях. Уровень компетентности позволяет исполнять свои обязательства без «раскрытия» мотивов работодателя сотрудниками. Все умные в интернете.
Не переживайте, я всегда на стороне справедливости. Просто так никого под увольнение не подводят, а все переработки оплачивают.
Не переживайте, я всегда на стороне справедливости. Просто так никого под увольнение не подводят, а все переработки оплачивают.
UFO just landed and posted this here
В европейских странах есть такое понятие как Саббатикал: https://en.m.wikipedia.org/wiki/Sabbatical
После нескольких лет работы на одну компанию она разрешает взять очень долгий (до 1 года) оплачиваемый отпуск и отдохнуть. Лично знаю людей которые так делали и мне эта идея тоже нравится
В СССР и РФ как минимум до нулевых такое в некоторых профессиях тоже есть/было, правда отпуск этот без содержания. Берут его редко, запасы на год редко у кого есть, но вот мой отец, например, воспользовался и провёл в таком отпуске последний год перед пенсией по выслуге лет. Просто физически работать не мог, выворачивало, классически выгорел.
Обычно все же неоплачиваемый. По крайней мере, в компаниях-гигантах, типа Google.
Во Франции саббатикал неоплачиваемый. Это просто возможность придержать за собой рабочее место (не больше 11 месяцев), если вдруг основываешь стартап или решил поработать в другом месте, но не уверен, что хочешь туда свалить насовсем.
Значит, либо я не так понял своих знакомых, либо мне что-то напарили.
Спасибо вам и alexeykuzmin0 за пояснения!
Спасибо вам и alexeykuzmin0 за пояснения!
А что делать выгоревшим?
Я напишу алгоритм для идеального случая. На практике, конечно по разному.
При проявлении симптомов сотрудник должен идти/быть направлен к психиатру через психоневролога. Бояться психиатра не надо. Да, вы не псих, но отнюдь не здоровы. Адекватный специалист, как правило ставит на ноги за 6 — 10 сеансов. Редко, когда нужно больше. Как минимум, он должен найти источник.
Одним из направлений восстановления в любом случае будет длинный отпуск и занятие чем-то совсем другим. Возможно, сменить род деятельности придётся навсегда. Если повезёт, то только место работы.
При проявлении симптомов сотрудник должен идти/быть направлен к психиатру через психоневролога. Бояться психиатра не надо. Да, вы не псих, но отнюдь не здоровы. Адекватный специалист, как правило ставит на ноги за 6 — 10 сеансов. Редко, когда нужно больше. Как минимум, он должен найти источник.
Одним из направлений восстановления в любом случае будет длинный отпуск и занятие чем-то совсем другим. Возможно, сменить род деятельности придётся навсегда. Если повезёт, то только место работы.
Он действительно знает, как писать отличное программное обеспечение, и если ему дать достаточно времени, то сможет создать идеальную систему. Проблема в том, что он верит, что у него есть всё время в мире и полная свобода, хотя это далеко не так. Вместо того, чтобы найти компромисс, он сосредоточился на создании идеальной системы. Он считает, что это лучше для бизнеса.
Вот тут тонкий момент. Большинство людей, управляющих ИТ проектами, на моем опыте с легким сердцем ставят клеймо идеалиста на любом разработчике, которому не насрать на долгосрочную перспективу и который не хочет делать одну и ту же работу 10 раз. У них постоянно "заказчик хочет это вчера" и хоть трава не расти, а когда ты начинаешь объяснять, что кроме краткосрочной выгоды нас ждут тяжелые долгосрочные лишения, ты сразу идеалист и не понимаешь, как делать бизнес по-взрослому.
Иногда удается отвоевать немного времени на рефакторинг, но это как правило местечковое исправление некритичных участков, потому что времени дают всегда сильно меньше. Предсказуемо, это не дает сильного буста, потому что самые проблемные куски кода никуда не делись. Менеджмент же для себя делает вывод "Мы дали им время на рефакторинг, получили предсказуемый простой в развитии, но ощутимой выгоды нет". И с каждой следующей итерацией круг сужается — дают еще меньше времени, пользы еще меньше, а ты все больше идеалист, который всегда недоволен.
И они в свое время меня почти задавили числом, я был готов поверить. Но повезло, и я попал на проект, где "ежедневные коммиты" не были приоритетом. И все прошло как по учебнику: долгое планирование и компетентный архитектор обеспечили проект, где вообще не было форсмажоров. Внедрение нового разработчика в команду не было проблемой, равно как и его выход из команды.
Видел также прямо противоположную ситуацию: некомпитентный техлид и по совместительству интерфейс для заказчика за 3 месяца написания проекта с нуля породил легаси-монстра, как в плане архитектуры, так и в плане стабильности работы, я никогда не видел подобного. И каждый день на этом проекте проходил с девизом выкатить новую фичу как можно скорее, потому что заказчик ждет.
Самое смешное, что я случайно потом спалил, что этот техлид сам бежит впереди паровоза, и подгоняет кнутом, даже когда заказчик сказал, что понял риски и готов дать столько времени, сколько нужно.
До сих пор я так и не понял, как формализовать золотую середину между настоящим идеализмом и абсолютным отсутствием понимания долгосрочной перспективы, и уж тем более как продать потом эту середину менеджменту.
Но повезло, и я попал на проект, где «ежедневные коммиты» не были приоритетом. И все прошло как по учебнику: долгое планирование и компетентный архитектор обеспечили проект, где вообще не было форсмажоров. Внедрение нового разработчика в команду не было проблемой, равно как и его выход из команды.Немного смущает прошедшее время. Неужто проект оказался нежизнеспособен и сгинул в конкурентной борьбе?
Иногда удается отвоевать немного времени на рефакторинг, но это как правило местечковое исправление некритичных участков, потому что времени дают всегда сильно меньше.
Это всегда от ситуации зависит. Если проект заказной, заказчик часто не хочет или нет денег на это. Проект работает как-то, свои задачи выполняет, да и ладно. Или нет понимания, что «да там только пару полей добавить» тянет за собой еще шлейф изменений логики обработки. В таком случае за свои деньги переделывать проект для дяди никто не будет, возможна только косметика, как Вы пишите.
Если же проект свой и приносит хорошую прибыль, то можно реинвестировать и переработать.
Мне кажется ваш вариант не очень подходит. Если проект не нужно развивать, то да, заказчик не видит смысла платить за него деньги, но и перспективы на самом деле может и не быть. Если нужны новые фичи, то рефакторинг старых входит в стоимость новых. И нужно донести до заказчика что экономия сейчас хоть и возможна, но приведет к удорожанию в будущем причем совсем не линейному. Пару раз заказчик решит поэкономить, увидит что так и есть и согласится что можно и нормально делать. Ну это в идеале конечно, если менеджер не умеет донести эту мысль, то будет как описано.
Можно попробовать завоевать доверие менеджмента постепенно. Найти какие-либо easy win улучшения в проекте и попросить на них немного времени. Потом показать результат: «смотрите, как быстро мы запилили фичу X, а все потому, что мы заранее порефакторили вон там».
Постепенно, на каждой итерации можно выпрашивать побольше времени, пользуясь доверием, заработанным на прошлых этапах
Прямо карточную игру на основе таких типов можно сделать
Я вот на одном уровне сознания уважаю и люблю людей, независимо от того — программисты они или нет.
А на другом уровне считаю за полноценных коллег только программеров, остальные для меня — умственные инвалиды от уборщицы вплоть до директоров. Но я этому уровню не даю прорваться наружу… в 99.99% процентах случаев.
А на другом уровне считаю за полноценных коллег только программеров, остальные для меня — умственные инвалиды от уборщицы вплоть до директоров. Но я этому уровню не даю прорваться наружу… в 99.99% процентах случаев.
У меня все наоборот. Именно айтишников считаю умственными инвалидами и всегда пытаюсь отсесть от них по возможности подальше, а со всеми остальными людьми легко нахожу общий язык. При этом сам работаю программистом больше 15 лет.
Есть хорошая фраза «Глупо держать тех, кто вами управляет за дураков. Они как минимум не глупее вас».
Если директор твоей фирмы такой уж умственный инвалид — то почему тогда так получилось, что его зарплата отличается от твоей минимум на порядок, и что мешает тебе добиться в жизни того же самого?
Если директор твоей фирмы такой уж умственный инвалид — то почему тогда так получилось, что его зарплата отличается от твоей минимум на порядок, и что мешает тебе добиться в жизни того же самого?
Ну да, вот у Мизулиной зарплата в 100 раз больше, значит она в 100 раз умнее меня. Я так считаю.
Хороший вопрос. Размер зарплаты — вполне себе объективный показатель, который легко измерить и легко сравнить. Правда проститутка или наркодиллер примерно сравнимо с программистом зарабатывают, об этом вы видимо не успели подумать.
Если честно, мне пофиг, кто там умнее-глупее. Главное чтобы эти умственные инвалиды не лезли в вопросы, связанные с проектированием ПО. А они пытаются это делать — вот только из-за этого я этот вопрос обсуждаю вообще. Не хватает чёткого знака — «Дальше умственным инвалидам ходить опасно!».
Если честно, мне пофиг, кто там умнее-глупее. Главное чтобы эти умственные инвалиды не лезли в вопросы, связанные с проектированием ПО. А они пытаются это делать — вот только из-за этого я этот вопрос обсуждаю вообще. Не хватает чёткого знака — «Дальше умственным инвалидам ходить опасно!».
Уборщица тоже лезет в вопросы проектирования ПО чтоб вы её за инвалидку считали?
Вы — специалист в разработке, отлично, но при этом и на сам продукт, который вы разрабатываете вы смотрите со стороны творца, и можете не замечать насколько же он неудобный для конечного пользователя. Если на любые замечания вы реагируете высокомерным шипением «спасибо ваше мнение мне очень ценно, можете им подтереться, я лучше знаю как надо», то можете пропустить много интересного в жизни.
Как пример могу привести открытый софт линукса со всеми его «удобными» настройками всего лишь в десятке конфигурационных файлах разбросанных по системе и невнятным взаимодействием между разными компонентами против коммерчиского софта который зачастую ограничивает то, что пользователям позволяет настраивать. С точки зрения программистов получается очень странная картина — тот же почтовый сервер с календарем и резервацией комнат можно настроить своими силами на линуксе совершенно бесплатно, но большинство крупных и не только компаний покупают продукцию майкрософта, разработка которой велась не «программистами для программистов» и в проектированние которой влезали всякие «умственные инвалиды».
В общем — меньше снобизма, и жизнь будет лучше, и люди к вам потянутся.
Вы — специалист в разработке, отлично, но при этом и на сам продукт, который вы разрабатываете вы смотрите со стороны творца, и можете не замечать насколько же он неудобный для конечного пользователя. Если на любые замечания вы реагируете высокомерным шипением «спасибо ваше мнение мне очень ценно, можете им подтереться, я лучше знаю как надо», то можете пропустить много интересного в жизни.
Как пример могу привести открытый софт линукса со всеми его «удобными» настройками всего лишь в десятке конфигурационных файлах разбросанных по системе и невнятным взаимодействием между разными компонентами против коммерчиского софта который зачастую ограничивает то, что пользователям позволяет настраивать. С точки зрения программистов получается очень странная картина — тот же почтовый сервер с календарем и резервацией комнат можно настроить своими силами на линуксе совершенно бесплатно, но большинство крупных и не только компаний покупают продукцию майкрософта, разработка которой велась не «программистами для программистов» и в проектированние которой влезали всякие «умственные инвалиды».
В общем — меньше снобизма, и жизнь будет лучше, и люди к вам потянутся.
Мне кажется, речь велась не о том, «что» делать, а о том, «как» делать.
Уборщица тоже лезет в вопросы проектирования ПО чтоб вы её за инвалидку считали?
В разработку ПО она и не лезет, зато частенько лезет мыть пол в серверной (со знакомыми многим админам последствиями)
Я был свидетелем, когда верующая уборщица увидела у программиста на мониторе логотип FreeBSD (чертик с вилами) и начала утверждать, что мы все (программисты) попадем а Ад.
Зарплата здесь абсолютно непричем, так как в умственные инвалиды записаны все — от уборщицы до директора априори, равно как в сливки нации записаны все программеры априори. И чем это объяснить, кроме умственной отсталости самого представителя высшей расы программеров, я не знаю. Я работал на нескольких крупных предприятиях, я никогда не видел вокруг себя идиотов, их просто незачем держать в штате, потому что на большинство должностей все же есть определенный отбор и конкуренция. На айтишные должности почти нет, поэтому любой инвалид мозга с комплексом неполноценности может стать программером и считать себя выше других лишь на основании того, что у него иная форма черепа или иной цвет кожи есть знания как писать программный код.
А как быть, если согласен с «обоими лагерями»?
С одной стороны всплывает в самые различные моменты «ну и рукожопы», а с другой стороны понимаю, что «снобизм, как соль, хорош в минимальных дозировках».
И «стиль настройки линукса» бесит, но «реализация MS» напрягает местами еще больше.
Это моя проф.деформация?
UPD: Отвечу сразу — да, живется мне порой «ой как не просто».
С одной стороны всплывает в самые различные моменты «ну и рукожопы», а с другой стороны понимаю, что «снобизм, как соль, хорош в минимальных дозировках».
И «стиль настройки линукса» бесит, но «реализация MS» напрягает местами еще больше.
Это моя проф.деформация?
UPD: Отвечу сразу — да, живется мне порой «ой как не просто».
UFO just landed and posted this here
у них были причины сделать так
— Намеренное плохое UX в продуктах Atlassian путем принудительного сброса авторизации через N-часов (в разное время по разному, от 12 до 36) (толлерантное описание… но в голове одни маты). Был очень серьезный дискусс между представителями компании и сообществом, в результате которого таки удалось продавить «нашу» позицию. Но стоило это «тонны крови».
— Критические баги в google-драйвере (систематически)
— Ну очень плохой скайп
Это были отсылки к «миру IT-шников». Про «мир простых людей» я просто вообще не могу описывать ситуации — пригорает так сильно, что на луну ненароком улечу.
С гуглом вообще всё плохо, недавно была статья — про тот же gmail и изменения ради галочек, без реального смысла и внутренних исправлений.
и изменения ради галочек
Не, ну Вы скажете, тоже. Они ведь деньги за это получают. Кто будет платить им бабосики, если они просто оставят то, что и так хорошо работает, и будут плевать в потолок?
в том и дело что часто работает не очень. Но хоть как-то значит нафиг поддержку.
habr.com/post/429018
habr.com/post/429018
Размер зарплаты зависит не только от профессионализма, но ещё и от рисков. Например, наркодилеры и проститутки получают больше, потому что рискуют своим здоровьем и свободой.
В случае директора — он рискует принять неверное решение и пустить фирму ко дну. В отличие от программистов, директоров так массово не нанимают, поэтому найти новую работу будет сложно, особенно с историей провала в послужном списке.
Не понимаю, почему вас заминусовали.
Идея не держать начальника за идиота вполне себе разумная.
Идея не держать начальника за идиота вполне себе разумная.
Оспаривают применение «слишком сложных» технологий, инструментов и методов. НУ допустим «некомпетентный» знает как реализовать это на более простых технологиях быстро, коротко и эффективно, тогда зачем применять более сложные?
Вероятно имеется в виду «слишком сложные» технологии для него самого
Если есть более простая технология для решения проблемы, зачем использовать более сложную.
Яму можно вырыть лопатой, а можно экскаватором. Полагаю, что первый вариант значительно проще с точки зрения «технологичности». Но что, если яма нужна большого размера? А что, если их нужно N-штук? Или сроки сжаты? В таком случае более простая технология не подойдет.
А оспаривать более сложную технологию человек может, например, из-за того, что не умеет её готовить.
А оспаривать более сложную технологию человек может, например, из-за того, что не умеет её готовить.
В программировании есть циклы, и по большому счету машине все равно: копнуть миллиард раз лопатой или миллион экскаватором.
Есть вопрос в сложности алгоритма, ну например сортировка пузырьком, но будем честными современные технологии зачастую тяжелее.
Допустим человек может сделать все нативным sql запросом, а ему говорят используй ОРМ. Зачем если он может сделать все быстрее так, это будет работать быстрее и надежней?
Или он может сделать монолит, а ему говорят: микросервисы и кибернетес и блокчейн.
Есть вопрос в сложности алгоритма, ну например сортировка пузырьком, но будем честными современные технологии зачастую тяжелее.
Допустим человек может сделать все нативным sql запросом, а ему говорят используй ОРМ. Зачем если он может сделать все быстрее так, это будет работать быстрее и надежней?
Или он может сделать монолит, а ему говорят: микросервисы и кибернетес и блокчейн.
Не хочу хвастать, но в начале этого года, я меньше, чем за пару недель набросал форумный движок, на PHP без ООП, ORM и фреймворком, нарушая все современные методики и принципы. Но он, чёрт возьми, работает.
То же самое, несколько ранее, сделал движок казино.
Но на работе за деньги, я использую все эти ваши паттерны, SOLID, методологии и прочее-прочее. Кто платит — тот заказывает музыку.
То же самое, несколько ранее, сделал движок казино.
Но на работе за деньги, я использую все эти ваши паттерны, SOLID, методологии и прочее-прочее. Кто платит — тот заказывает музыку.
Если есть более простая технология для решения проблемы, зачем использовать более сложную.
Потому что простой и эффективной она может казаться только вам, и зачастую из-за недостатка опыта.
я скорее докопался до слова «сложных». Если б было применено слово «эффективные технологии» или «производительные технологии»
Там же в кавычках, имеется в виду, что это такие сотрудники так называют более эффективные технологии.
Допустим человек может сделать все нативным sql запросом, а ему говорят используй ОРМ. Зачем если он может сделать все быстрее так, это будет работать быстрее и надежней?
Вот значит где собака порылась) Начнем с того, что раз "говорят", значит не вы отвечаете за продукт и его поддержку. Поэтому тот, кто отвечает, вправе решать, какие технологии будут лучше в долгосрочной перспективе.
Далее. Нативный SQL-запрос в большинстве случаев гораздо не надежнее при изменениях кода, и часто не быстрее из-за возможности lazy loading в ORM. ORM не в последнюю очередь используют из-за буквы R, маппинга связей между объектами. Это очень упрощает код. Поэтому да, используй ORM.
Упрощает код (не всегда) и порой существенно замедляет его. Хотя бонусом обычно идёт безопасность запросов.
Да я чинил как-то трудноуловимую lazy Exception, спасибо что хибернейт это сделал, там где его не просили. А ну и чинил проблему, когда спринг выкачивал полбазы сотней запросов из-за того что lazy не было.
Ну еще раз, скажу — использовать надо то, что помогает тебе быстро и просто решить проблему, а не то что модно, молодежно, современно. У орм есть плюсы и минусы.
Я сам поклонник спринг дата, но тестить проще sql банальным копированием запросов в базу.
Ну еще раз, скажу — использовать надо то, что помогает тебе быстро и просто решить проблему, а не то что модно, молодежно, современно. У орм есть плюсы и минусы.
Я сам поклонник спринг дата, но тестить проще sql банальным копированием запросов в базу.
А для того, чтобы в середине сада выкопать ямку для посадки куста сирени будем загонять в сад экскаватор или обойдемся лопатой?
Если нужна ямка под кустик, то конечно не стоит заморачиваться экскаватором. А если нужно вырыть несколько котлованов под фундаменты для домов, и вам исполнитель заявляет, что будет рыть это лопатой, потому что экскаватор «слишком сложный», то мне кажется вы завалите все сроки по строительству, компания понесет убытки, люди не получат дома. А все из-за того, что кому-то в силу своей некомпетентности не хочется использовать экскаватор.
Так в том-то и дело, что иногда умение не использовать сложные механизмы это еще больший профессионализм чем везде их использовать. В примере с домом можно загнать экскаватор вырыть котлован на 2 подземных этажа потому, что только что научился им управлять, а потом на всем этом построить дачный летний домик. Т.к. по проекту его и нужно было построить.
Извините, я скорее докопался до слова «сложных». Если б было применено слово «эффективные технологии» или «производительные технологии» — это другое.
Вы экскаватор используете не ради его сложности, а потому что он производительный. Сложность — это его минус, с которой приходится мириться ради его производительности.
У вас почему-то сложность = производительность. Это отнюдь не так.
А представьте, что разработчик скажет: лопату к дрону присобачим, напишем машинное зрение, ИИ, блокчейн и подзарядку лазером на лету. Где сирень надо сажать?
Вы экскаватор используете не ради его сложности, а потому что он производительный. Сложность — это его минус, с которой приходится мириться ради его производительности.
У вас почему-то сложность = производительность. Это отнюдь не так.
А представьте, что разработчик скажет: лопату к дрону присобачим, напишем машинное зрение, ИИ, блокчейн и подзарядку лазером на лету. Где сирень надо сажать?
Я, наверно, неправильно выразился. Я против стрельбы из пушек по воробьям я лишь пытаюсь сказать, что если есть потребность в сложной технологии, которая будет эффективна в данном конкретном случае, то ее необходимо использовать.
Это, вероятно, и имел автор статьи. «Некомпетентный» разработчик — это не тот, кто против стрельбы из пушек по воробьям, но это тот, кто не используется более эффективные в каком-то конкретном случае инструменты, потому что для его понимания они «сложны».
Это, вероятно, и имел автор статьи. «Некомпетентный» разработчик — это не тот, кто против стрельбы из пушек по воробьям, но это тот, кто не используется более эффективные в каком-то конкретном случае инструменты, потому что для его понимания они «сложны».
Тоже заметил за собой несколько симптомов «некомпетентного» разработчика. Даже задумался, а не я они ли — он? :)
По мне так
Люди разные, и программисты разные. В команде разные типы программистов уравновешивают недостатки друг друга. Если распределять работу с учетом сильных сторон каждого, а не навешивать неподходящую человеку работу, то проблем будет гораздо меньше. Если в коллективе появляются такие «проблемные личности», то это может говорить не о недостатках конкретных людей, а о проблемах команды, неправильном распределении ролей, неудачных рабочих процессах и других проблемах.
Не всегда нужно исправлять человека, иногда нужно исправлять команду.
Не всегда нужно исправлять человека, иногда нужно исправлять команду.
Не встречал еще в своей жизни хорошего программиста и хорошего человека одновременно. Зачастую все так как описано или даже в совокупности несколько качеств и звезда, и идеалист, и оптимист. Хотя интеллект у таких людей зачастую сильно выше среднего, человеческие качества сильно проседают. В этом есть какой-то парадокс. Может он им наоборот мешает? Пока не понял.
А что входит в ваш критерий «хороший человек»?
Я принципиально не беру листовки/флаеры на улице, не даю денег попрошайкам, отказываюсь от всех доп-услуг, режу рекламу, не пускаю бомжей в подъезд, не помогаю «деньги на операцию еще одному миллионному котику/воробушку/собачке». Все, я уже «плохой человек»?
Я принципиально не беру листовки/флаеры на улице, не даю денег попрошайкам, отказываюсь от всех доп-услуг, режу рекламу, не пускаю бомжей в подъезд, не помогаю «деньги на операцию еще одному миллионному котику/воробушку/собачке». Все, я уже «плохой человек»?
Хотел еще пошутить вопросом про церковь и политические предпочтения, но вовремя понял что это выходит за пределы допустимого на Хабре)
Обычно люди «хорошими» называют людей которые такое же мировоззрение, как и они, используют. «свой» => «хороший».
Обычно люди «хорошими» называют людей которые такое же мировоззрение, как и они, используют. «свой» => «хороший».
Видимо да, слишком обобщил. Хороших же людей много, пока они никого не трогают, сидят себе тихонечко, копошатся там чего то, в таком смысле все хорошие. Я имел ввиду скорее отношение к другим людям в компании, участие или соучастие, эмпатия, войти в положение, выслушать, не истерить, не закапываться в перфекионизм, а реально оценить положение дел, предложить решение, взять на себя ответственность и подобное…
Вы сейчас воды налили два ведра, совершенно непонятно, что конкретно вы хотели сказать. Я встречал людей, которые использовали подобные термины, имея ввиду примерно следующее:
- Отказался перерабатывать нахаляву — плохо относится к компании.
- Не хочет больше подтирать за одним и тем же сотрудником — нет эмпатии/соучастия
- Требует законный отпуск, хотя просят не уходить — не может войти в положение, выслушать
- Устал от бесконечных костылей, говорит, что время инкрементального рефакторинга давно упущено, теперь только выбросить и переписать, а продолжать так жить больше нельзя — истерит и закапывается в перфекционизм, не может предложить решение
- Разработчик объясняет срыв сроков тем, что руководитель проекта постоянно меняет требования в последний момент — не может взять ответственность на себя
Иными словами, в их понимании "хороший человек" — это тот, кто с улыбкой всегда прогнется под компанию и, желательно, чтоб делал это задешево.
Да, кстати, вы прям в точку попали.
Пожалуй дополню типичным случаем вне работы — ситуация с меркатильной женщиной (это важно)… если дотошный и внимательный мужчина быстро въезжает в формирующуюся ловушку и успевает дать задний ход («давай, досвиданья»), то он, почему-то, сразу становится «козлом».
«Козлом» становятся и в уже сформированных отношениях, когда, внезапно, мужчина перестает давать «ездить на себе, свесив ножки».
И для этого вовсе не требуется быть «плохим».
Пожалуй дополню типичным случаем вне работы — ситуация с меркатильной женщиной (это важно)… если дотошный и внимательный мужчина быстро въезжает в формирующуюся ловушку и успевает дать задний ход («давай, досвиданья»), то он, почему-то, сразу становится «козлом».
«Козлом» становятся и в уже сформированных отношениях, когда, внезапно, мужчина перестает давать «ездить на себе, свесив ножки».
И для этого вовсе не требуется быть «плохим».
Да, это примерно так и работает. Когда с тебя можно что-то поиметь и ты позволяет это делать, ты – "хороший человек". Но стоит скинуть нахлебников со своей шеи – сразу становишься плохим. Иными словами "хороший"/"плохой" – это вообще не характеристика по сути, а способ манипуляции.
Скорее всего, встреченные вами программисты то же самое думают и про вас, так что всё довольно субъективно.
Мне много раз говорили, что как человек, я – говно. Я много над этим думал и пришёл к выводу, что мне говорят не совсем правду. Я слишком прямолинеен. И после того, как я указываю людям, что на самом деле говно – они, и даже обосновываю это, они обижаются и начинают считать говном меня… а потом своё дело делают расползающиеся слухи. И вот уже для окружающих я – говно, а все остальные двуличный твари, скрывающие свою настоящую личину – принцы на белых конях.
Поэтому при отклонении запроса на повышение у него остаётся только два варианта: встать в один ряд с другими разработчиками или уйти. В любом случае, ваша проблема решена.
Отрежьте пути выхода и ждите пока сотрудник станет послушным или будет вынужден уйти.
Пассаж про некомпетентных просто оскорбителен.
Читать такие советы печально, складывается впечатление, что со времен викторианских мануфактур менеджерский подход прогрессирует не очень сильно.
Рекрутёры будут звонить рок-звезде каждый день по несколько раз. Их репутация опережает их.
Телепатию уже изобрели, а я это пропустил…
Каким волшебным образом кто-то в другой компании узнает что «Я, три года тянущий проект на себе» — рок-звезда?
— Конференции? 9 из 10 рок-звезд не ездят на конференции, а работают над проектами.
— Руководство? Руководство рок-звезд делать больше нечего, как обсуждать с конкурентами своих программистов. Тем более что чаще руководство тупо ничего не знает о винтиках в своей организации. А рок-звезда — ровно такой же винтик. Просто большой и мощный.
— Коллеги? Ага, коллегки программисты идут бухать с руководителями соседних компаний и там рассказывают о человеке, который делает всё работу в их компании.
— Телепати! Вот как они узнают, не иначе.
Опенсорс, коллеги, еще что то. Например я хоть далеко и не рок-стар но меня пригласили на собеседование недавно именно после общения с бывшими коллегами моими. Плюс текущие коллеги имеют знакомых программистов в других местах и если их просят подсказать знакомого программиста они могут навести. Плюс тот же хабр и стековерфлоу. Вариантов немало.
То что вы описали — совсем не тоже самое, что «его все хотят».
я сам сейчас работаю по рекомендации предыдущего работодателя, а пред-предыдущее место получил от товарища по форуму.
Но это обычная текучка через знакомства. Совсем не война за голову, как описано в статье.
я сам сейчас работаю по рекомендации предыдущего работодателя, а пред-предыдущее место получил от товарища по форуму.
Но это обычная текучка через знакомства. Совсем не война за голову, как описано в статье.
Ну собственно кто то в глазах коллег выглядит обычным разрабом как я. А кто тл выглядит именно рок старом, и как раз о таких молва расходится больше. Или не о них самих а о проектах в которых они участвовали (а там уже по наводке выясняется кто именно участвовал в проекте и на каких ролях, с каким результатом).
Владелец одного из проектов прямым текстом мне сказал, что моего имени не будет в кредитсах проекта, пока на рынок полный релиз не выйдет.
С аргументацией, что «купить можно всех». Речь шла о том, что ко мне придут и купят меня и проект через меня.
Это я к тому, что на уровне руководства никто о ценных сотрудниках болтать не будет.
А на уровне рядовых разработчиков тем более — есть темы и поинтереснее чем «мой коллега Вася такой крутой спец!»
С аргументацией, что «купить можно всех». Речь шла о том, что ко мне придут и купят меня и проект через меня.
Это я к тому, что на уровне руководства никто о ценных сотрудниках болтать не будет.
А на уровне рядовых разработчиков тем более — есть темы и поинтереснее чем «мой коллега Вася такой крутой спец!»
Каким волшебным образом кто-то в другой компании узнает что «Я, три года тянущий проект на себе» — рок-звезда?Значит, Вы и не рок-звезда :) Рок-звезд хорошо знают
Рок-звезд хорошо знают
Через телепатию?
Нет, через их известность в мире IT
А известны они в мире IT через телепатию?
P.S.
Это я вам «тонко» намекаю на то, что не плохо было бы уже раскрыть, каким волшебным образом компании конкурентов узнают о существовании крутых спецов у своих противников.
P.S.
Это я вам «тонко» намекаю на то, что не плохо было бы уже раскрыть, каким волшебным образом компании конкурентов узнают о существовании крутых спецов у своих противников.
Странный вопрос. Известная личность на то и известная, чтобы быть известной. Конференции, книги, интервью, перебежчики из других компаний и т.д. и т.п.
А если про вас не знают — значит, вы и не знамениты :)
А если про вас не знают — значит, вы и не знамениты :)
UFO just landed and posted this here
О, я и не намекал на то что я рок-звезда, там речь шла не про переманивание разработчика, а про продажу проекта, увидите это если внимательно прочитаете.
А Кармак — он в первую очередь владелец, также как Гейтс, например. Лицо компании.
НУ и кстати, с Кармаком сделаи провальный Rage, а без Кармака выстрелевший Doom. Так что большой вопрос, является ли Кармак сейчас рок-звездой(в терминах разработки, а не известности).
P.S. Ну и в целом вы ерунду пишите, рок-звездность не связано с размером компании. Рок-звездность — это уровень квалификации и способностей. Такие люди работают в самых разных компаниях. Опять же — прочитайте внимательнее раздел про рок-звездв в статье.
А Кармак — он в первую очередь владелец, также как Гейтс, например. Лицо компании.
НУ и кстати, с Кармаком сделаи провальный Rage, а без Кармака выстрелевший Doom. Так что большой вопрос, является ли Кармак сейчас рок-звездой(в терминах разработки, а не известности).
P.S. Ну и в целом вы ерунду пишите, рок-звездность не связано с размером компании. Рок-звездность — это уровень квалификации и способностей. Такие люди работают в самых разных компаниях. Опять же — прочитайте внимательнее раздел про рок-звездв в статье.
UFO just landed and posted this here
Мне Кармак не нравится? Это вам он перестал нравится, когда я указал, что он, очевидно, не рок-звезда сейчас.
Я вот целиком определение привел, покажите там слово, в котором вы увидели «известность»:
Да, вот я вижу — рок звезда это тот кто тащит и кто известен.
Я вот целиком определение привел, покажите там слово, в котором вы увидели «известность»:
Разработчик настолько талантлив, настолько продуктивен, настолько важен, что если он уйдёт, весь проект рухнет.
простите что вмешиваюсь. а каких программистов работающих в близзард или валве вы знаете? вот так сходу без гугла получится назвать когото? и чем он запомнился (почему это рок-звезда)?
Вы отрицаете наличие репутации в принципе.
А она есть, пойдем от противного — Билл Гейтс, Павел Дуров,…
А она есть, пойдем от противного — Билл Гейтс, Павел Дуров,…
— Телепати! Вот как они узнают, не иначе.
Телепати — это вечеринка телепатов, что ли?
Ждем похожую статью про типы менеджеров и всякого рода управленцев среднего звена.
еще бы указать, сколько опыта за их килл дают…
Не хватает опроса в конце статьи — узнали ли вы себя в одном из этих типов?
… поскольку им приносит удовлетворение именно сам процесс, а не цель
Счастливые люди
В каждом из психотипов нашел частичку себя. Учту)
Зачастую, как впрочем было отмечено в статье, линию поведения разработчика вынуждает принять сама политика управления в компании. Тут подходит поговорка про рыбу которая гниёт с головы. Потому если случилась «болезнь» то уже поздно изучать поведенческие типы сотрудников. Только грамотный и авторитетный менеджмент способен избежать крайностей в коллективе. Потому если встретились с подобным, посмотрите сначала на руководство и многое станет понятным. Я бы писал статью лучше о том как политика компании заставляет меняться людей, причём выделять программистов я бы не стал, законы равны для всех.
Вот и в кибернетике мягко добрались до темы личностных «корон». Ура)
Кому вопрос интересен более развернуто — я подчерпнул много здесь: evo-lutio.livejournal.com
Кому вопрос интересен более развернуто — я подчерпнул много здесь: evo-lutio.livejournal.com
Без описания остальных участников картинки в начале поста, пост выглядит явно неполным.
Вот не пойму, автор оригинального текста, солдат-метящий в менеджеры, или некомпетентный-пессимист?
А будет подобная статья про менеджеров?
Например взгляд на менеджера со стороны разработчика?
Например лично я считаю что менеджеры только мешаются в разработке.
Например взгляд на менеджера со стороны разработчика?
Например лично я считаю что менеджеры только мешаются в разработке.
«Некомпетентный»
Блин, у меня и так проблемы с самооценкой и я прошу всегда мало денег. А тут ещё такое. Теперь я считаю, что вообще не достоин работать и получать даже то, что мне платят.
Этот пост вообще мою самооценку снизил. Ну за что же вы так. И что же мне делать теперь.
Блин, у меня и так проблемы с самооценкой и я прошу всегда мало денег. А тут ещё такое. Теперь я считаю, что вообще не достоин работать и получать даже то, что мне платят.
Этот пост вообще мою самооценку снизил. Ну за что же вы так. И что же мне делать теперь.
Считать себя рок-звездой
Блин, у меня и так проблемы с самооценкой и я прошу всегда мало денег.
Давай, каждый раз, перед тем, как просить денег, ты будешь звонить/писать мне. Я буду тебя подбадривать — ты будешь просить больше и ещё 10% сверху накидывать для меня.
проблемы с самооценкой и я прошу всегда мало денегСтандартная рекомендация — иметь два оффера. Пусть торгуются между собой, а не с вами.
менеджер по персоналу открыл для себя психологию?
программисты такие же люди как и все, со своими тараканами
программисты такие же люди как и все, со своими тараканами
Вот на картнке, приведённой в начале статьи, всё здорово. Бараны, овцы, змеи… дятла не нашёл, но думаю, он там должен быть.
К сожалению, так же как нельзя быть полуграмотным кардиохирургом или частично компетентным пилотом, никто не может быть лишь частично компетентным разработчиком программного обеспеченияКакие правильные слова — именно!
Думается это не совсем так.
aanechaev.livejournal.com/239663.html
Вчера я летел из Москвы в Берлин. На подлете капитан корабля порадовал нас, что в германской столице хорошая погода, но еще минут через 10 начали твориться чудеса. Вместо посадки самолет стал кружить над аэропортом, а командир сообщил, что мы не можем сесть по погодным условиям и должны ожидать посадки в воздухе. Пару раз пилот вроде пытался сесть, но потом с натужным ревом двигателей машина вновь взмывала в небо. Согласитесь, не самые приятные ощущения.
В итоге этих экспериментов капитан корабля уведомил нас, что сесть мы не сможем и полетим в Прагу, что и было проделано.
Дальше началось самое интересное. После посадки пассажиры с доступом к интернету без труда выяснили, что самолеты других авиакомпаний прекрасно приземлялись в том же аэропорту Шенефельд Берлина до и после наших попыток. В Праге нам заменили пилотов. При замене удалось перемолвиться с летчиками парой слов. И выяснилось, что летчики нашего экипажа просто плохо умеют пилотировать самолет. Ну, конечно, не совсем не умеют (хотя при посадки в Праге они так грохнули машину о полосу, что и подобное подозрение имело под собой основание). Просто на этой модели самолета они не имеют опыта садиться в тумане, который опустился на Берлин. Летчики других авиакомпаний имеют, а наши нет. Справедливости ради замечу, что новый экипаж в тот же туман в Берлине все-таки сел.
Что касается хирургов — про кардио не знаю, а вот в онкохирургии — весьма разные есть. А истинный уровень хирурга понятен только коллегам.
Вот кстати история про плохого хирурга — со всеми объяснениями:
www.anekdot.ru/id/977482
В общем… все люди — в каждой профессии, и никто не идеален.
aanechaev.livejournal.com/239663.html
Вчера я летел из Москвы в Берлин. На подлете капитан корабля порадовал нас, что в германской столице хорошая погода, но еще минут через 10 начали твориться чудеса. Вместо посадки самолет стал кружить над аэропортом, а командир сообщил, что мы не можем сесть по погодным условиям и должны ожидать посадки в воздухе. Пару раз пилот вроде пытался сесть, но потом с натужным ревом двигателей машина вновь взмывала в небо. Согласитесь, не самые приятные ощущения.
В итоге этих экспериментов капитан корабля уведомил нас, что сесть мы не сможем и полетим в Прагу, что и было проделано.
Дальше началось самое интересное. После посадки пассажиры с доступом к интернету без труда выяснили, что самолеты других авиакомпаний прекрасно приземлялись в том же аэропорту Шенефельд Берлина до и после наших попыток. В Праге нам заменили пилотов. При замене удалось перемолвиться с летчиками парой слов. И выяснилось, что летчики нашего экипажа просто плохо умеют пилотировать самолет. Ну, конечно, не совсем не умеют (хотя при посадки в Праге они так грохнули машину о полосу, что и подобное подозрение имело под собой основание). Просто на этой модели самолета они не имеют опыта садиться в тумане, который опустился на Берлин. Летчики других авиакомпаний имеют, а наши нет. Справедливости ради замечу, что новый экипаж в тот же туман в Берлине все-таки сел.
Что касается хирургов — про кардио не знаю, а вот в онкохирургии — весьма разные есть. А истинный уровень хирурга понятен только коллегам.
Вот кстати история про плохого хирурга — со всеми объяснениями:
www.anekdot.ru/id/977482
В общем… все люди — в каждой профессии, и никто не идеален.
И тем не менее и они лучше, чем 90% «вкатившихся» в 30 л за большой зп «программистов». Ну, по крайней мере их учили и проверяли, у них были экзамены и в вузе, и в компании. И цена их ошибки — не выговор, а человеческие жизни.
По поводу жесткого касания. В европейской школе пилотов учат как раз ощутимому касанию, т.к. оно надёжнее в плане трения и снимает часть кинетической энергии.
habr.com/company/tuturu/blog/425983
habr.com/company/tuturu/blog/425983
Да, тоже читал. Бывают кстати забавные полярности. Как-то уснул в самолете- и… посадка была настолько жесткой, что было ощущение, что мы действительно просто грохнулись об полосу и надо накладывать гипс на стойки шасси ))) ибо там несомненно переломы. А как раз на днях — аэрофлотовский самолет сел так так мягко, что я вообще не понял, что мы уже сели — догадался только по тряске и шуму, хотя не спал, просто не смотрел в окно.
UFO just landed and posted this here
Sign up to leave a comment.
Проблемные личности среди разработчиков