Мысль из сегодня обсуждения… Плюс навеяно обсуждением книги Good to Great.
Предположим у нас есть программист, который хорошо работает, делает задачи, пишет документацию, обучает и слегка менеджит других программистов, достаточно инициативный — продвигает улучшения, хорошо ведет отчетность и т.п. В целом хороший программист, а может (если он еще и достаточно продуктивный) — даже отличный программист. Но гениальным вряд ли его назовут.
А теперь представим другого программиста — никого не обучает, документацию не пишет, не менеджит других, да и сам плохо менеджится, улучшения в компании не продвигает, отчетности от него никакой, он запирается у себя дома и через 3 недели появляется с решением какой-то большой и важной проблемы. Еще нужно подчеркнуть, что если бы не то, что он решал эти крупные проблемы — то его бы выгнали мгновенно за остальные пункты, а так его будут считать гениальным (не хорошим и даже не отличным), а именно гениальным программистом.
Слава богу, за свой опыт я не слишком часто с такими сталкивался 🙂
Так вот, о чем я задумался, это о том насколько они гениальны такие программисты, на самом деле.
Подведем простой математический расчет. Естественно все цифры взятые с потолка, если вам они не нравятся, подставьте свои.
а) Не ходить на работу и пользовать это время на программирование. (+10% дополнительного времени).
б) не писать документации (+5% дополнительного времени).
в) не обучать других программистов (+10% дополнительного времени)
г) не менеджить других программистов (+15% дополнительного времени)
д) отсутствие отчетности отчетности (+5% времени)
е) отсутствие необходимости согласовывать решения (+5% времени)
е) не присутствовать на всех митингах (+10% дополнительного времени)
д) отсутствие переключения между задачи (+30% эффективности).
е) отсутствие прерываний работы другими людьми (+30% эффективности)
Итого уже накапало 50% дополнительного времени и 60% увеличение эффективности. То бишь, продуктивность возросла в 2.4 раза. Думаю, если покопаться и выписать более полный список того, что НЕ делает гениальный программист, то вполне разность продуктивности может получаться и в 3-4 раза (отсюда и выходит, что хороший программист делает 3 месяца, а гениальный вадает за 4 недели).
А теперь на секунду остановитесь и задумайтесь. Хорошо ли для компании такое увеличение продуктивности в 4 раза? Если вы ответили «Да», то вам двойка в четверти по бизнесоведению 🙂
Ладно, для мелких-мелких компаний, которые только стартуют — это может быть решением, но для средних, а тем более крупных компаний — это выстрел себе в ногу.
Есть такая штука «technical debt». Это когда написал код на скорую руку и решил, что потом его приведешь в божеский вид, но потом как-то не наступило и код продолжает пользоваться/изменяться/дополняться. С каждым днем его становится все сложнее поменять и все больше времени уходит на его поддержание. То есть мы сделали что-то быстрее взяв в долг, но долг не выплатили и него начали расти проценты.
Аналогично, можно, ввести понятие «process debt», когда что-то делается без учета уже действующих правил (а-ля документирование, обучения людей и т.п.). Взять такой долг на короткое время вполне можно, но постепенно он накапливается (остальные разработчики не знаю тех частей, которые написаны гениальным программистом, не возможно предсказать даты выпуска продукта, так как нету никакой отчетности, время поддержки кода растет из-за отсутствия документации, обсуждений по ходу разработки и т.п).
В целом, Гениальных программистов в Бабруйск, даешь хороших программистов.
P.S. В нескольких комментариях отметил, что я не хотел сравнивать производительность людей с разным умением и опытом (плохих и хороших программистов). То, что я в статье пытался сделать – это показать, что программист с одними и теме же знаниями и опытом, в случае если он повышает эффективность компании в целом – будет называться хорошим, если он уменьшает эффективность компании (путем посылания нафиг всего кроме написания кода) – будет называться гениальным.
P.P.S. В еще нескольких комментариях началось обсуждение, как называют этих программистов. Предложенные варианты «Гики», «Хакеры». В целом, пусть хоть горшками (не чайниками) называют. Важно то, что с точки зрения множество людей в компании эти гении/гики/хакеры более (или по крайней мере не менее) полезны чем хорошие программисты выполняющие гораздо больший спектр задач.
ИМХО плохой это термин technical debt. Под него слишком много попадает.
Локальная «неопрятность» ничем не грозит в будущем, приспичило, зашел, пофиксли, запустил тесты и все. А вот архитектурные косяки, это да. Грозят в будущем очень неприятными последствиями.
Допустим локальная неопрятность заключается в том, что вы недопокрыли код тестами. Тогда другой человек из вашей команды в будущем запуская тесты не будет ничего гарантировать в случае их прохождения. Кстати, он возможно даже не будет об этом догадываться.
То есть взятое в долг время (непотраченное на написание тестов) оборачивается большими процентами (незаметное обесценивание набора автотестов) в будущем.
>> локальная неопрятность заключается в том, что вы недопокрыли код тестами
Взял и допокрыл, когда приспичило код переделать (основы рефакторинга знать надо). Не вижу где тут проблема критичная для будущего развития продукта.
Наличие тестов проверяется кстати очень просто, если не вставать в позу и не кричать что, всё код гавно, мы все умрем. а просто поставить breakpoint/отладочный вывод/raise exception и запустить тесты.
>> незаметное обесценивание набора автотестов
Не понял, с чего это вдруг существующие тесты обесценились?
Под debt должно попадать только то, что постепенно требует interest.
Условно говоря
а) Изначально выбрана не слишком удачная технология
б) Из-за того, что технология неудачная поверх нее накрутили много левого кода, просто для того, чтобы по ходу залатывать найденные проблемы.
в) Все это плохо документировалось и НЕ покрывалось тестами
г) Поверх этого наростили слой на другой технологии дописав еще код по их связи
д) Все это делалось достаточно долго, чтобы не было человека полностью понимающего эту часть.
Результат — система достаточно нестабильна. Для ее приведения в нормальный вид нужны серьезные изменения
а) Нужно разобраться как оно работает
б) Нужно создать тесты
в) Нужно заменить крупную часть с одной технологии на другую
и т.п.
Тут уже пахнет не «приспичило, зашел, пофиксил», а скорее либо годичным проектом по постепенному приведению это в порядок, либо ударным переписыванием за 3 месяца (а потом разгребанием новых глюков).
Все перечисленное под пунктами а-д, это проблемы архитектуры и дизайна.
А не локальные косяки
Проблема состоит в том, что локальные косяки перерастают в архитектурные проблемы.
Все таки архитектура — это достаточно размытое понятие.
Сегодня у нас есть локальный кусочек кода и функция, завтра поверх нее навернули еще одну функцию (вроде пока локально), потом присоседили класс который их пользует, потом этот класс оказался центральным для какой-то подсистемы. Вот и получается — сегодня функциональность локальна, а завтра она часть архитектуры.
И как раз в тот момент, когда происходит этот переход важно таки вычищать косяки, которые были локальными, а стали глобальными.
P.S. Безусловно я согласен, что разные мелкие нечистости в совсем уж локальной функциональности можно таки не вычищать.
Опечатка вкралась — «который хорошо работает, делает задачи, пишет документация» -> «который хорошо работает, делает задачи, пишет документацию»
спасибо. поправил.
Реально производительность программистов может отличаться на порядок. Т.е не в 2.5 раза а в 10-12 раз. И тот программист, что работает в 10 раз быстрее будет в любом случае более выгоден на проекте, если только у него нет каких либо психических отклонений, вроде ярко выраженного аутизма.
Другое дело, что многие программисты сконцентрированы чисто на написании совершенного кода, но в отрыве от всего остального. И это сильно снижает общий эффект производительности. Иногда до нуля, когда получается продукт с прекрасным кодом, но никому не нужный.
Я как-то рассуждал на тему в своем блоге
Насчет 10-12 раз, это уже чуть другое. Это отличие умелых и опытных от неумелых и неопытных.
Я тут скорее пытался сравнить двоих программистов, с одинаковыми умениями и знаниями, просто с разным стилем поведения.
>Другое дело, что многие программисты сконцентрированы чисто на написании >совершенного кода, но в отрыве от всего остального. И это сильно снижает общий >эффект производительности.
Именно это я и имел в виду. На самом деле, он показывает высокую производительность, благодаря тому, что уменьшает производительность остальных на длительном промежутке времени.
А теперь на секунду остановитесь и задумайтесь. Хорошо ли для компании такое увеличение продуктивности в 4 раза? Если вы ответили “Да”, то вам двойка в четверти по бизнесоведению 🙂
Это офигенно. Компания, как правило, работает не в вакууме, а в жесткой конкурентной среде. Если ты можешь выкатить фичу на два месяца раньше конкурентов, ты собираешь сливки и как приятный бонус экономишь кучу бабла на программистов. Если ты опоздал, значит тебе придется вырывать у конкурентов пользователей по крупицам, а программисты будут сосать твой бюджет как алкаши водку. Поэтому если вам каким-то чудом достался гениальный программист, что бывает, на самом деле, крайне редко, куда разумнее придать ему пару стажеров, чтобы подчищали за ним хвосты, тестировали и писали документацию. По деньгам немного, но время-то сэкономите.
Аналогично, можно, ввести понятие “process debt”, когда что-то делается без учета уже действующих правил (а-ля документирование, обучения людей и т.п.). Взять такой долг на короткое время вполне можно, но постепенно он накапливается (остальные разработчики не знаю тех частей, которые написаны гениальным программистом, не возможно предсказать даты выпуска продукта, так как нету никакой отчетности, время поддержки кода растет из-за отсутствия документации, обсуждений по ходу разработки и т.п).
Разработчики и так не знают кода друг друга. И не хотят знать. Они хотят послать автора в тайгу к медведям, переписать код с нуля и точно также сидеть на нем задницей до тех пор пока их самих не пошлют к медведям. Потому что обладателей сакрального знания о том как это все работает не увольняют а апгрейдят до архитектора/менеджера/аналитика.
Сроки это такая же фикция. Продукт будет готов, когда он будет готов и ни днем раньше. Если менеджеру говорят какую-то цифру, это просто цифра с потолка. С вероятность 95% она будет сдвинута вправо. Чем больше эта цифра, тем сильнее она будет сдвинута. Просто дата на календаре.
Почему растет время поддержки? Уж точно не из-за гениального программиста. Оно растет из-за крепких середнячков, которые не понимают код, написанный лучше чем бы написали они. Если человек не понимает указателей, для него половина Сишных трюков будет черной магией. Если он не понимает регулярных выражений для него они будут нечитаемой ересью которую нужно переписать. Если он не понимает автоматного программирования он будет порываться отрефакторить state machine в цепочку понятных ему if/switch. Потому, код стремится к термодинамическому равновесию, а коллективное владение кодом приводит к тому, что его качество определяется худшим из тех, кто к нему прикасался.
Время поддержки вообще всегда растет с увеличением объема кода. Набивают код как чулан фичами и никогда их оттуда не выбрасывают. Дескать, «обратная совместимость», «потом пригодится», «ну кто-то же ее просил». Парадокс, никто уже не помнит что эта фича делает, а в коде она до сих пор есть. В результате код, написанный крепкими середнячками, пухнет даже еще сильнее. Потому что они даже в своем коде не разбираются, ведь их время занято митингами, обучениями, документацией, обсуждениями и прочей непроизводительной байдой.
>Это офигенно. Компания, как правило, работает не в вакууме, а в жесткой >конкурентной среде. Если ты можешь выкатить фичу на два месяца раньше конкурентов, >ты собираешь сливки и как приятный бонус экономишь кучу бабла на программистов.
Во первых, не каждая фича выкаченная на 2 месяца раньше прямо озолачивает компанию.
Как вы точно сказали — конкуренция жестокая, а это значит, что у вас одна фича раньше, а у них другая. Продажи зависят НЕ только от фич.
Второе, это то, что можно провернуть это раз, два или три, а на четвертом разу обнаружится, что программист который все педалил ночами, свалили — документации нет, остальные программисты его кода вообще не знаю, сделан он на какой-нибудь абсолютно левой технологии, которую неясно как вообще дальше развивать и т.п.
>Разработчики и так не знают кода друг друга. И не хотят знать. Они хотят послать >автора в тайгу к медведям, переписать код с нуля и точно также сидеть на нем >задницей до тех пор пока их самих не пошлют к медведям. Потому что обладателей >сакрального знания о том как это все работает не увольняют а апгрейдят до >архитектора/менеджера/аналитика.
Разные есть разработчики. И цель умного владельца или менеджера, как раза
разорвать этот цикл бессмысленных переписываний и хранения сакральных знаний.
>Время поддержки вообще всегда растет с увеличением объема кода.
Безусловно. Только вопрос какова функция роста времени поддержки от размера кода.
Естественно большое количество слабых программистов делают эту функцию быстрее возрастающей. Но также ее делает быстрее возрастающей гениальный программист работающий в отрыве от всех остальных.
Не каждая. Но если известно, что фича не принесет денег, любой вменяемый менеджер задвинет ее в самую задницу фичалиста и отложит ее реализацию на вечные времена. Ясен пень, прибыль зависит от кучи вещей, вот только фичи на первом месте. Без них прибыли не будет, просто нечего будет продать клиентам. Выпусать фичи раньше конкурнтов это волна. С каждым релизом растет отрыв. Если это удалось четыре раза подряд, на пятый будет время сменить технологию, команду, а то и вовсе волну. Проблемы начинаются не когда уходит разработчик, который «все знает», а когда к власти приходят косные менеджеры, не понимающие сути волны. Им кажется, что клиенты платят деньги потому, что заключили договора и так будет всегда. Сама мысль о том, чтобы выкинуть все в топку и пойти в другую сторону вызывает у них праведный ужас.
>Разные есть разработчики. И цель умного владельца или менеджера, как раза
разорвать этот цикл бессмысленных переписываний и хранения сакральных знаний.
Его цель заработать максимум денег минимальными затратами. Странно если его цель другая. Круг переписываний как раз разорвать легко. Достаточно ввести индивидуальное владение кодом и процедуру передачи кода новому владельцу.
>Только вопрос какова функция роста времени поддержки от размера кода.
Экспонента, конечно. Простейший анализ истории VCS и багрекера любого проекта это подтвердит.
>Но если известно, что фича не принесет денег, любой вменяемый менеджер >задвинет ее в самую задницу фичалиста и отложит ее реализацию на вечные >времена.
Заранее достаточно редко известно, какая фича будет золотая.
>Его цель заработать максимум денег минимальными затратами.
Согласен. Это я уже загрался словами 🙂
В целом я согласен с вашей идеей, что быть впереди конкурентов — это выигрышный путь.
С другой стороны из моего опыта. Я уже знаком с несколькими компаниями которые загрузли в количеств фич. То есть они их клипали, клипали (как и их конкуренты), а потом оказалось, что есть тьма кода, которая не понятно что делает (нет документации), написанная на кучи разных технологий (всегда была погоня за кратковременным выигрышем) и все время разработки уходит на support. И дело тут не в костных менеджерах, а в том, что когда все сконцентрировано на краткосрочную выгоду, то зачастую (не всегда) долгосрочное начинает страдать.
>Заранее достаточно редко известно, какая фича будет золотая.
Поэтому потенциальные «золотые» нужно делать в первую очередь и как можно быстрее.
>Я уже знаком с несколькими компаниями которые загрузли в количеств фич.
Если бы они не клепали фичи, скорее всего, сейчас их бы уже не было.
Фирмам выдавали инвестиции, так что, шанс уйти на дно совсем у них был не супер большой.
>Потому что они даже в своем коде не разбираются, ведь их время занято митингами, >обучениями, документацией, обсуждениями и прочей непроизводительной байдой.
Вот тут мне кажется у вас и кроется ошибка.
Только с точки программистов — написание кода — это единственное производительная операция в всем IT.
На самом деле это не так. Код — это только часть. Есть тестирование, документация, требования, поддержка, продажи, маркетинг и т.п.
Даже для программиста — написание кода, это только часть задачи.
С точки зрения бизнеса тоже. Только фичи конвертируются в деньги. Не будет фич, нечего будет поддерживать, не о чем писать документацию, нечего продавать и непонятно как рекламировать. Понятно, что без всего остального фичи не продать. Но если отвлекать программистов на бесполезную возню, выхлоп сильно уменьшится.
>Только фичи конвертируются в деньги.
М… Не совсем согласен. Согласен, что фичи — это основа. Но, в сильно конкурирующем рынке есть еще параметры как
— качество программы (текстовый редактор с 1000 фич, но который падает каждые 2 минуты никому не нужен)
— usability
— поддержка
— скорость обновлений (исправлений известных ошибок)
— взаимодействие фич (насколько они хорошо к друг друго подогнаны создают целостную программу)
— полезность и инновационность (зачастую одна новая интересная фича, может быть эффективней чем 10 фич у конкурентов)
Ответьте мне на один вопрос. Если фичи единственная нужная вещь и только написание кода приносит прибыль, почему компании имею
а) документацию по архитектуре
б) автоматизированные тесты
в) документацию по требования
г) митинги (или другие методы обсуждения) функциональности
д) обучение программистов
и т.п.
Неужели, они все ошибаются и только Вася Пупкин из под Муромска, который колбасит код день и ночью все делает правильно?
Короткий ответ: потому что в крупной компании получение прибыли и работа находятся так далеко друг от друга, что становится выгодным не делать а лишь иммитировать полезную деятельность.
Длинный ответ: Если фича не работает это означает что ее нет и продать ее нельзя. Поэтому если для разработки фичи нужно собрать требования, никуда не денешься их придется собрать. Если нужно спроектировать архитектуру, придется проектировать. Если нужно протестировать, придется тестировать. Но если не нужно, гибкая компании может забить, а корпорация не может. Вася Пупкин, независимо от того, педалит он код днем или ночью, может быть как гибким, так и не очень. Дофига, на самом деле программистов, которые трудолюбивы, но не гибки.
Ответ на длинный ответ. Все это хорошо звучит постфактум.
Если нужно спроектировать — значит спроектировать, если нужно продукументировать — значит продокументировать. Опять же, проблема, что заранее обычно это не известно.
Пример из личного опыта. Сейчас добиваю продукт. Когда он начинался, мне казалось, что его можно сделать достаточно просто. Нанял программиста, который над ним работал. Потом пришлось перейти к работе с другим программистом. Тут обнаружилось, что минимальная документация по архитектуре (которую можно было бы сделать в течении дня, была бы очень неплоха). Потом оказалось, что вообще и требования былоа бы не плохо собирать, так как в результате фичи, получались не совсем те, которые планировались и т.п.
Хорошо если задачу легко сделать в тот момент, когда она понадобилась, гораздо хуже, когда сложность выполнения задачи растет экспоненциально.
На старте это тоже неплохо звучит. Достаточно сказать себе: «я собираюсь сделать ставку на самых дешевых фрилансеров, которых только смогу найти. Для того чтобы сделать риск работы со фрилансерами приемлимым мне нужно…»
Не согласен.
Постановка вопроса относительно самых дешевых фрилансеров эквивалента этой.
«Я собираюсь открыть кондитерскую фабрику. И собираюсь делать конфеты из самого дешевого материала (говна). Для того чтобы сделать риск того, что они будут вонять говном мне нужно…»
Некоторые задачи НЕ подлежат решению потом. Они подлежат решению только в начале.
Другой пример лечение бешенства. В тот момент, когда у человека развились основные симптомы — лечить уже поздно.
интересно
Я учился в физмат школе и рано начал программировать. Поэтому немного пересекался с гениями в программировании (победителями всяких олимпиад, людьми, бросавшими университеты, чтобы не тратить время и заниматься интересными им вещами и т.д. и т.п.).
Я не согласен с утверждением, что разница между середняком-профессионалом и гением в производительности в разы, она качественная.
Главная особенность гения это то, что его ведет не желание материальных благ или социальной реализации, а любопытство и интерес. Совмещенное с талантом, это приводит к наличию у них глубоких знаний в разных областях IT. Знаниях в далеко не мейнстримных технологиях и платформах, которыми профессионал не будет заниматься в силу отсутствия у него времени и тем, что это не связано напрямую с его мат. достатком и социальным положением. Все эти хаскелы, схемы, смолтолки, кто-то продвинулся дальше «экая непонятная загогулина»?
Как результат (широких знаний в разных областях + производительность), талант за считанные дни может создать то, на что команде профессионалов может потребоваться месяцы. Другой вопрос, что с точки зрения значимости для социума цена их работы может стремиться к нулю. Ну слабо они разделяют коллективные ценности, ничего здесь не поделаешь.
Не место им в корпорациях, их дело это стартапы, инновации, исследования и т.п.
Ван Гога посадить работать в рекламное агенство. В творческом порыве отрежет себе ухо, потом офис от крови месяц не отмоешь.
Резюмируя, гениям — генальное, а хорошим — хорошее.
Полностью согласен с вами.
Но пару замечаний. Есть действительно гениальные программист — с невероятно широкими познаниями, опытом, необычным мышлением и т.п.
То, что я в статье пытался сделать — это показать, что программист с одними и теме же знаниями и опытом, в случае если он повышает эффективность компании в целом — будет называться хорошим, если он уменьшает эффективность компании (путем посылания нафиг всего кроме написания кода) — будет называться гениальным.
То есть, я подчеркивал, то что сейчас понятие «гениальности» выдают не совсем той категории.
С вашим пониманием процесса разработки софта в корпорации я тоже согласен. «Гениальности» там не место, важна вписанность в общий формальный процесс производства и нормальные коммуникативные навыки, работаем же в коллективе.
Но, обычно, классические гении в корпорациях не задерживаются, им там скучно.
А по твоим наблюдениям кто больше зарабатывает: хорошие, или гениальные? Если первый вариант, то лучше делать бизнесс
Хм… Сложно сказать.
В маленьких компаниях, где такой вид гениальности компании на руку, обычно зарабатывают больше гениальные. В средних — зарплаты выравниваются. В больших таких людей зачастую выгоняют, так как они в политические игры не умеют играть.
я не веду документацию, но ставлю редка-изредка комменты, для не тривиальных функций.
я считаю, что пишу достаточно понятный код, но людям приходится иногда в нем долго разбираться, а на самом деле — что написал — так и будет.
предпочитаю не писать больших функций, максимум экстракт метод рефакторинга.
дома занимаюсь всякой херней, вот уже с лета читаю всякие блоги, дабы от мира сего е отделятся, но при этом, все мои новшества или новые пути решения каких-то банальных или необычных, или постоянных проблем (с коими всегда встречаемя и на них забиваю) — их не воспринимают как обязательная ступень для включения в архитектуру или просто использованию, хотя всегда могу доказать эффективность найденного решения, а ну и пофиг
в итоге пишу для себя, сплю мало, но высыпаюсь — факт.
на работе оч часто бывает прерывают, или спрашивают, или перебрамываюсь на другие задачи, для более быстрого разрешения, предпочитаю их решать в не офиса, чтобы никого не было, чтобы один.
по немногу дома увлекаюсь сторонними технологиями, от одной даже уже зависимость, млин 🙂
по рассуждениям я — профи, скорее всего, но на самом деле — просто дурак, нет бы все делать по правильному, слушать манагеров, писать отчеты, вести доки, не думать о построении архитектуры и не заморачиваться об «а что если в будущем…», а я — пишу тупо код, спорю, т.к. большинство не моих обязанностей иногда переваливается ко мне, и каждый час достают с проверкой состояния работ или вопросом: «За какой срок сделаешь то-то» или «Как быстро исправишь в чужом коде …», или — «Нужно мделать ферму порталов за столько-то времени»
я готов вести документацию, но если допустим, мне с утра скажут — вот вам 6 часов раб времени на решение таких-то задач, если не успеете, то на завтра (хотя иначе то и ни как), и 2 часа на составление документации и отчетов о работеи если напишите доку дома, то можете после 6-ти часов работы уходить, млин, и был же опыт! я тупо во время дороги составлял отчеты, т.е. отчеты я не вечером, а с утра сдавал, на дорогу — час-полтора, отчет навоять — часик, 1 час дороги получается все-равно что на работе, и уходил раньше и на свои дела казалось-бы времени больше (а своими делами в дороге за час особо не сильно успеешь позаниматься), и поспать даже больше на час получалось! и производительность выросла!
потом решили поступить др. образом: чтобы и вместо планерки мне задания в письменном виде давали, естессно сверяясь с моими отчетами, но это бы горьки опыт — задания писальсь ужастно, т.е. типа — «хочу машину» и все, а что от нее хочет — хз, приходилось бегать и спрашивать, в итоге — планерки посещаю, если над проектом работает боее 3-х человек, но на планерках говорить манагеру мы запретили — имхо много техречи, а они перебивают,.. но, видимо, работа такая.
главное, — не быть хорошим, и — не быть гением, а — чтобы сам хотел, имхо, если в рабочей области наскучивает, то уже начинаю искать что-то новое…
сорри за оффтоп, редко постю что-либо
Если честно не знаю, что сказать 🙂
Единственное, что очень уважаю, когда человек дает себе отчет в том, что он делает, что ему нравиться и что ему не нравиться. И когда он видет и положительные и отрицательные стороны этого.
Вроде у вас как раз такой случай 🙂
>главное, – не быть хорошим, и – не быть гением, а – чтобы сам хотел, имхо, если в >рабочей области наскучивает, то уже начинаю искать что-то новое…
Это вы о внутренних потребностях говорите. А я писал о внешней оценке ;))
ты описал evil genius, а не гениального программиста 🙂
вообще, в моём понимании гений от программирования не тот, кто делает в 10 раз больше. ведь это нереально писать 10К строк кода в день, просто клавиатура рассыплется…
гений на то и гений, что его 100 срок делают _столько же_ как 500 строк у середняка. и производительность, которая отличается на порядок, меряется в функционале, который просто достигается меньшим кол-вом кода -> меньшим кол-вом ошибок -> меньшей стоимостью поддержки.
гении выгодны. как ни крути.
http://2.bp.blogspot.com/_NavBKjzQKqY/RyegBTZ7GWI/AAAAAAAAAFY/tDeqXp3yzDA/s1600-h/dilbert2036666071016.gif
:))) Дилберт — это вещь 😉
Та, я же и не говорил, что нужно в 10 раз больше строк писать. Я говорил об общей эффективности. То бишь решать в X раз больше задач.
Увы, все таки, то я отписал — это не evil genius, а просто технарь, который не хочет ни чем заниматься кроме программирования.
так отож — просто технарь, но не гений вовсе. 🙂
ну, все таки, я говорил о восприятии программиста другими, а не о его реальной сущности 🙂
так другие воспримут того, кого ты описал, как «гика», а не как «гения».
Добавил P.P.S.
добавил, но тему не раскрыл.
ну это как обычно — мы в разных конторах работаем и с разными людями общаемся… но в моём кругу общения, человека, код которого трудно поддерживать, гением не назовут.
Я думаю, дело в том, что я скорее с этим столкнулся в США.
У нас в exUSSR много людей, которые любят возиться с кодом и поэтому скорее хорошо воспринимаются те, кто что-то помимо этого умеют делать.
В штатах, людей которые зацикленны на коде гораздо меньше. Может быть поэтому к ним отношение гораздо более положительное.
Описанный вами «Гениальный программист» это и не программист вовсе 🙂 Для таких личностей давно придуман термин — «Хакер». Хотя в вашем круге общения возможно другая терминология принята. А «Гениальный программист» это просто программист более высокого качества 🙂
А вообще для общего развития рекомендую почитать книгу «Программистский камень». Там есть ряд полезных мыслей для понимания что такое программист 🙂
Добавил P.P.S. Там ответ.
Мой ответ — если бы таких «гениальных» в конторе не держали, она бы не получала сверх-прибылей, потому что все бы были заняты «отчетностями, документацией,обучением, управлением и т.п. и т.д.». И в конце концов некому было бы решить пиковые проблемы. Кароче говоря, нужны и мозговики и управленцы, которые будут пользоваться плодами их деятельности, т.е. использовать их деятельность чтобы мы, просты потребители могли их деятельностью воспользоваться.
Главное научиться их вкусно вместе «приготовить». 🙂
не согласен.
Идет противопоставление
а) гениальный программист пишет код
б) остальные только и занимаются отчетность и управление и документацией.
Все таки, побочные задачи съедают ну 50% времени, но не больше того.
Да и сверхприбыли получают вовсе не от безумных прораммистов, колбасящих по ночам, а от кого-нибудь вверху управленческой цепочки придумывает, как монетаризировать миллион пользователей или как добавив пять фич и отрекламировав себя в другом сегменте, получить новых пользователей.
>Да и сверхприбыли получают вовсе не от безумных прораммистов, колбасящих по ночам, >а от кого-нибудь вверху управленческой цепочки придумывает, как монетаризировать >миллион пользователей или как добавив пять фич и отрекламировав себя в другом >сегменте, получить новых пользователей.
Ой не скажи. Как бы ты гавно не рекламировал, а сверх прибылей ты за него не получишь. максимум — отобьешь вложения и чуток заработаешь. Я наверное повторюсь, но «Кароче говоря, нужны и мозговики и управленцы, которые будут пользоваться плодами их деятельности».
Согласен, что нужны и исполнители (умные) и управленцы.
Но возвращаясь к контексту статьи. Что я хотел сказать, что хороший программист, который работает в команде в долгосрочной перспективе более выгоден, чем гениальный программист, который сконцентрирован только на написании кода.