Комментарии 41
Вы хотели бы лечиться (не приведи что) у хорошего врача или вполне достаточно нормального?
Если диагноз ставит зав. отделением, то прописать глюкозу поколоть может и «нормальный».
Всевозможные завы в первую очередь менеджеры. У них все хорошо с коммуникацией, твердостью в управлении и другими управленскими качествами. Если зав сидит в кабинете и только бумажки подписывает, то уж лучше к нормальному врачу, который каждый день практикует.
я конечно не так часто посещаю больницу (тьфу-тьфу-тьфу), но у меня опыт когда зав. отделением практикующий специалист и именно как лучший в своем отделении.
Никто не спорит. Хороший врач лечит хорошо :) Но если укол может сделать врач средней квалификации и тот же самый укол может сделать самый умный врач в мире, то зачем идти к самому лучшему врачу? Он же с вас денег больше возьмет, да и зачем тревожить гения по пустякам :) Нужно идти к врачу согасно «критичности» вашего заболевания.
один и тот же укол можно сделать как более так и менее больно (тут картинка с Трусом, Балбесом и Бывалым из «пленницы»).
у сына кровь на анализы брали пару раз по 4 ампулы. одна медсестра в вену в районе локтя иглу всадила и «полчаса» потом цедила, а другая иглу чуть глубже всадила там же и за несколько секунд те же 4 ампулы заполнила. Боль от самого укола была ± той же (по ощущениям сына).
у сына кровь на анализы брали пару раз по 4 ампулы. одна медсестра в вену в районе локтя иглу всадила и «полчаса» потом цедила, а другая иглу чуть глубже всадила там же и за несколько секунд те же 4 ампулы заполнила. Боль от самого укола была ± той же (по ощущениям сына).
Ну это уже плохой врач, а может и не врач вовсе. :)
Надо в статье дописать прецеденты использования плохих программистов.
Надо в статье дописать прецеденты использования плохих программистов.
Я как раз пытался в статье сказать, что под задачу нужно выбирать специалиста с приемлимым уровнем квалификации — если вам нужно сдать анализ за полчаса, то идем к врачу Пете, а если нужно за 5 мин и чтобы не было больно, то идем к врачу Васе. В софтвер проекте обычно хватает и трудных и сложных задач, поэтому я как раз и придерживаюсь мысли, что нужно иметь разношерстную команду по уровню подготовки.
> Всевозможные завы в первую очередь менеджеры. У них все хорошо с коммуникацией
С точностью до наоборот. По нехорошей советской традиции начальником врачей становится лучший из врачей (и так не только в медицине). В результате организация теряет (полностью или частично) хорошего специалиста и получает хренового управленца. При этом считается, что учить управлять не надо, «разберётся».
Похожая ситуация с образованием, когда людей учит классный специалист, но учить совершенно не умеющий.
С точностью до наоборот. По нехорошей советской традиции начальником врачей становится лучший из врачей (и так не только в медицине). В результате организация теряет (полностью или частично) хорошего специалиста и получает хренового управленца. При этом считается, что учить управлять не надо, «разберётся».
Похожая ситуация с образованием, когда людей учит классный специалист, но учить совершенно не умеющий.
Заву отделения ваш насморк может быть совсем неинтересен. В результате вы можете получить даже худший сервис, чем у самого обычного терапевта.
Капитанская статейка.
Жаль что очень и очень мало информации, как успешно делать проекты используя «нормальных программистов» или даже «средненьких программистов», т.е. тех кого больше всего и именно тех, которые вам достались в команду.
Жаль что очень и очень мало информации, как успешно делать проекты используя «нормальных программистов» или даже «средненьких программистов», т.е. тех кого больше всего и именно тех, которые вам достались в команду.
Тут нет уникальный советов, в статье не описать подобное. Можно описать личный опыт, но он будет неприменим в других случаях, слишком много факторов.
Представьте, что вы играете в компьютерную стратегию типа RTS, у вас есть разношерстные юниты, которых вы со временем можете апгрейдить. Но если обычного юнита из легкой кавалерии превратить в тяжелого рыцаря, то уже особо не устроить зерг-раш(просто потому, что таких юнитов меньше, и у них немного иные задачи). Короче говоря — менеджмент это не планирование, нельзя сказать, что «найму вот столько таких то, и это на пять лет весь план.». Менеджмент — это именно умение управлять юнитами так, чтобы им и скучно не было, и чтобы оверхеда дикого не было за 500 баксов (такого, чтоб они прям бежали от вас).
Представьте, что вы играете в компьютерную стратегию типа RTS, у вас есть разношерстные юниты, которых вы со временем можете апгрейдить. Но если обычного юнита из легкой кавалерии превратить в тяжелого рыцаря, то уже особо не устроить зерг-раш(просто потому, что таких юнитов меньше, и у них немного иные задачи). Короче говоря — менеджмент это не планирование, нельзя сказать, что «найму вот столько таких то, и это на пять лет весь план.». Менеджмент — это именно умение управлять юнитами так, чтобы им и скучно не было, и чтобы оверхеда дикого не было за 500 баксов (такого, чтоб они прям бежали от вас).
Менеджмент — это именно умение управлять юнитами так, чтобы им и скучно не былоЭто обычно выделяют в отдельную дисциплину — «управление персоналом».
Тут нет уникальный советов, в статье не описать подобное.Нет, я не конкретно про эту статью, а вообще про учебную литературу или статьи по управлению. Максимум что в них рассматривается — это вопрос мотивации. При этом предполагается что ваши юниты довольно круты, добросвестны, молчаливы и исполнительны. Но ведь IRL это совсем абсолютно не так.
При этом предполагается что ваши юниты довольно круты, добросвестны, молчаливы и исполнительны. Но ведь IRL это совсем абсолютно не так.
Это потому, что автор абстрагируется от взаимоотношений и концентрирует внимание на других аспектах. А взаимоотношения это совсем другая тема, скорее ближе к психологии нежели к управлению. Никто и не скрывает, что все сотрудники будут разношерстны. Но на самом деле я бы начал затрагивал эту тему в контексте другого вопроса — например найма, или еще раньше — планирования проекта/отдела/команды. Команду компануют, планируют, думают кто нужен. Дальше при найме смотрят подойдет соискатель или нет, будет ли он дополнять команду и будет ли вообще в команде. И само собой надо понимать, что лидер должен быть способен управлять конкретной данной командой.
Короче говоря — этот вопрос решается изначально в контексте других шагов. А вся литература по управлению дают советы общего характера, иногда они применимы, а иногда нет. Вы сами должны оценить применимость методик, и реализовать их в вашей команде, возможно где-то улучшив под себя.
Дальше при найме смотрят подойдет соискатель или нет, будет ли он дополнять команду и будет ли вообще в командеЭто при безбрежном рынке трудовых ресурсов и превышающей рыночную ставку зарплате для вакансии. На практике вы месяцами ищите нужного человека на выделенные деньги, и берете компромиссный вариант, как правило.
А вся литература по управлению дают советы общего характера, иногда они применимы, а иногда нетНу как сказать, Agile, например, хорошо работает только если проникнуться его духом до последней практики. Иначе получается культ карго.
А взаимоотношения это совсем другая тема, скорее ближе к психологии нежели к управлениюВот. Может это сугубо мой необычный опыт, но могу сказать что начинать надо с людей и их психологии. А практики управления процессом уже должны это все дополнять. А не наоборот.
Это при безбрежном рынке трудовых ресурсов и превышающей рыночную ставку зарплате для вакансии. На практике вы месяцами ищите нужного человека на выделенные деньги, и берете компромиссный вариант, как правило.Никто и не спорит. Однако это не значит, что надо нанимать кого попало. Всегда стоит понимать, что чем то нужно будет пожертвовать (в требованиях к соискателю) и с учетом этих отступлений планировать команду.
Ну как сказать, Agile, например, хорошо работает только если проникнуться его духом до последней практики. Иначе получается культ карго.Впрочем как и любая другая методика, просто не везде это будет так явно заметно.
Вот. Может это сугубо мой необычный опыт, но могу сказать что начинать надо с людей и их психологии. А практики управления процессом уже должны это все дополнять. А не наоборот.Да, по-этому выше я не отделял «управление персоналом» в отдельную дисциплину. Я имею ввиду как раз то, что это комплекс скиллов, а не отдельно взятые прокачанные на полную. Картину надо воспринимать в общем, и применять тот или иной подход в зависимости от ситуации. Иногда может понадобится сперва практика, а потом психология.
Статья-то капитанская, я согласен. Но я ее написал потому, что устал смотреть на то, как управленцы действительно думают, что программистов можно складывать и вычитать, как яблоки.
По поводу что же делать — то я попробовал описать свои предложения в разделе о профите. И товарищ Rivethead правильно заметил, что все зависит от конкретных ситуаций. Пожалуй единственный общий пункт — это заботиться о производительности своих подчиненных — самый последний пункт в моей статье. И этот пункт на самом деле значит много. Программист может быть в 2 и в 3 раза продуктивнее в зависимости от обстоятельств.
По поводу что же делать — то я попробовал описать свои предложения в разделе о профите. И товарищ Rivethead правильно заметил, что все зависит от конкретных ситуаций. Пожалуй единственный общий пункт — это заботиться о производительности своих подчиненных — самый последний пункт в моей статье. И этот пункт на самом деле значит много. Программист может быть в 2 и в 3 раза продуктивнее в зависимости от обстоятельств.
Такие менеджеры любят ругать за скорость и что стараешься продумывать идею, прежде чем кодить. Т.е., как описано в статье, например, изначально заложить гибкость и модифицируемость решения без костылей. В итоге через годы в проекте странная структура закостыленная + порой плохо читаемые участки кода. И речь не столько об ошибках или говнокодинге, сколько именно о непродуманности верхнеуровневых вещей. Я уже устал это объяснять и смысла особо таким людям объяснять нет — это тупо признак херового управленца. Они и процессами не управляют, а пытаются в ручном режиме людьми командовать. Тут либо искать хороших, либо самому идти в управленцы и делать как надо.
1 образованный математик сможет доказать теорему Пифагора за час
Надо чтобы кто нибудь написал про 10 отличий между хорошим и нормальным менеджерами, которые хотя бы абстрактно понимают принципы работы кода и знают доказательство теоремы Пифагора
<irony>Хорошие менеджеры?</irony>
Ага, менеджеров не любят… Частенько материл нашего за то, что вместо программирования занимаюсь написанием ТЗ и генерю отчеты из Жиры. Но сейчас вдруг пришла в голову мысль, может быть он хороший раз умудрился заставить меня делать работу, которой никто заниматься не хочет и которая один фиг должна быть сделана
Менеджеры только из-за своего статуса менеджера не становятся плохими или хорошими :) Есть хороший менеджер. И есть плохой менеджер, и как повезет на того и попадешь :)
Возможно, вашему менеджеру нужно было объяснить вам почему эти отчетики из Жиры нужны и чем они полезны для проекта (см. «Интерес к поставленой задаче» из моей статьи). Ну а если эти отчетики из Жиры были пустой бюрократией, то может быть вашему менеджеру стоило бы проллобировать наверху решение об их отмене, т.к. они впустую лишь сжигают человекочасы.
Возможно, вашему менеджеру нужно было объяснить вам почему эти отчетики из Жиры нужны и чем они полезны для проекта (см. «Интерес к поставленой задаче» из моей статьи). Ну а если эти отчетики из Жиры были пустой бюрократией, то может быть вашему менеджеру стоило бы проллобировать наверху решение об их отмене, т.к. они впустую лишь сжигают человекочасы.
Спасибо за статью. Одно замечание: вы вначале статьи выделяете хороших и нормальных программистов, а в заключении категории поменялись на нормальных и умных, при том обе категории вы называете хорошими программистами.
Хехе, да, терминология вся перемешалась. Мне кажется тут есть 2 плоскости: профессионализм (умный/глупый/нормальный) и еще есть общая доброжелательность («хорошесть») — ведь умный профессиональный программист может сделать пакость или расхлябано относиться к работе. Так же и глупый программист может относиться расхлябано.
Я в статье как бы взял на веру, что все подопытные программисты работают на советь и не относятся халатно к своей работе. Таким образом «умный», «нормальный», «хороший» были эпитетами, которые характеризовали профессиональную подготовку программиста. К примеру: «этот умнее» или «вот этот лучше» :)
Я в статье как бы взял на веру, что все подопытные программисты работают на советь и не относятся халатно к своей работе. Таким образом «умный», «нормальный», «хороший» были эпитетами, которые характеризовали профессиональную подготовку программиста. К примеру: «этот умнее» или «вот этот лучше» :)
Тут вы как-то смешали в кучу интеллектуальные способности и проффессионализм. Бывают очень умные, но неопытные, а потому не очень профессиональные программисты. А также бывают посредственные, но более опытные и профессиональные. Интеллектуальные способности определяют скорость достижения определённого уровня профессионализма с опытом, и потолок профессионализма. Но вообще профессионализм и ум — вещи разные.
Это у одного меня дэжавю с Бруксом «Мифический человеко-месяц»?
Ни-и-ичего нового.
Гораздо интереснее было читать «Как техничка, должна управлять программистами» или что то такое, схожее по смыслу. Где идея заключалась в том, что бы ставить над программистами человека, который ничего в программировании не понимает и давались рекомендации как ими управлять. А самое интересное, что мне удалось побывать в гостях в таком отделе (т.к. с многими программистами в дружеских отношениях). Так в том отделе, все руководство сводилось к чисто формальным пунктам: приход/уход на работу, количество перекуров, выполнения заданий в срок (сроки озвучивает сам программист). Их руководитель отдела был простым оператором ПК, которого поставили начальником и который кроме отчетов «о проделанной работе» ничего не мог, не то что бы отличить квалификацию специалиста. Правда на работу принимал другой человек, выше уровнем, вот тот мог отличить хороший программист или посредственный + очень много брали молодняка, после практики из учебных заведений.
Резюме: В карму стукнуть не могу, тут скажу. Скучно, ничего нового.
Ни-и-ичего нового.
Гораздо интереснее было читать «Как техничка, должна управлять программистами» или что то такое, схожее по смыслу. Где идея заключалась в том, что бы ставить над программистами человека, который ничего в программировании не понимает и давались рекомендации как ими управлять. А самое интересное, что мне удалось побывать в гостях в таком отделе (т.к. с многими программистами в дружеских отношениях). Так в том отделе, все руководство сводилось к чисто формальным пунктам: приход/уход на работу, количество перекуров, выполнения заданий в срок (сроки озвучивает сам программист). Их руководитель отдела был простым оператором ПК, которого поставили начальником и который кроме отчетов «о проделанной работе» ничего не мог, не то что бы отличить квалификацию специалиста. Правда на работу принимал другой человек, выше уровнем, вот тот мог отличить хороший программист или посредственный + очень много брали молодняка, после практики из учебных заведений.
Резюме: В карму стукнуть не могу, тут скажу. Скучно, ничего нового.
Несколько сомневаюсь я, что принципы менеджмента можно вот так внаглую и вслепую натянуть на какой-то, например, «отдел разработки ПО». В случае классического управления вышестоящий менеджер (назовём его «шеф») знает, что данный вопрос должен решить конкретный отдел, т.е. задача 100% отправляется туда, но к какому специалисту? смотрим должностной регламент, и выясняем: №1 только стучит по клаве, №2 стучит и мычит, №3 тянет весь отдел. Тут понятно, кому достанется задача. НО.
Возвращаемся к тексту статьи. Под программистом понимается «специалист, обладающий некими знаниями и навыками в производстве ПО». Таким образом, задачу по «производству ПО» выполняет любой «программист» по принципу «тыжпрограммист». Таким образом может взяться любой — тот кто свободен, а не тот «который находится на должном уровне для написания этого чудесного ПО». С точки зрения шефа — что изменить текст в шапке, что написать драйвер на 64битную ОС для какого-нибудь стримера — одинаковые «чудеса». Так что тут ни разу не менеджмент, а просто передача задания и всё.
Дальше претензии к «выводам», думаю понятны.
И отдельно понравился вот этот момент. «Лучше брать качеством, чем количеством.»
Это даже не смешно. Вы хотите сказать, что если вы уволите phpшника, сисадмина, технаря, 1сника, MS_office_гуру, и взамен возьмёте одного эникейщика и отправите его на курсы, это будет эффективнее?..
Возвращаемся к тексту статьи. Под программистом понимается «специалист, обладающий некими знаниями и навыками в производстве ПО». Таким образом, задачу по «производству ПО» выполняет любой «программист» по принципу «тыжпрограммист». Таким образом может взяться любой — тот кто свободен, а не тот «который находится на должном уровне для написания этого чудесного ПО». С точки зрения шефа — что изменить текст в шапке, что написать драйвер на 64битную ОС для какого-нибудь стримера — одинаковые «чудеса». Так что тут ни разу не менеджмент, а просто передача задания и всё.
Дальше претензии к «выводам», думаю понятны.
И отдельно понравился вот этот момент. «Лучше брать качеством, чем количеством.»
Это даже не смешно. Вы хотите сказать, что если вы уволите phpшника, сисадмина, технаря, 1сника, MS_office_гуру, и взамен возьмёте одного эникейщика и отправите его на курсы, это будет эффективнее?..
один эникейщик с ролями «phpшника, сисадмина, технаря, 1сника, MS_office_гуру» будет нифига не качественным, да и сравнение некорректное. Тут скорее имеется в виду, что «лучше взять одного толкового phpшника, чем двух мало толковых»
Ну я опустил все эти нюансы, что программист может быть специалистом в одной области и неучем в другой области программирования. Я посчитал, что это само собой разумеется. Если менджер не знает, что внутри программирования есть специализации, то ему, пожалуй, рано читать эту статью.
По поводу «брать качеством, а не количеством» — естественно вы берете какой-то маржинальный пример. Все нужно применять в разумных пределах.
По поводу «брать качеством, а не количеством» — естественно вы берете какой-то маржинальный пример. Все нужно применять в разумных пределах.
Про «перегнул» — согласен, каюсь)
Но я всё-таки так активно язвил немного по другому поводу. Не то чтобы я настолько не верил в менеджмент, но в большинстве случаев кадровые решения о ИТ-спецах принимаются людьми мало что понимающими в ИТ, в отличие от многих других сфер среднестатистической фирмы\компании. А коль так, то и оценка эффективности далека от объективности :( Поэтому, увы, попытка разделить имеющихся ИТ-спецов на «хороших» и «нормальных», на самом деле разделит их скорее на «более ленивых» и «менее ленивых»)
А вспоминая поговорку о том, что ленивый человек делает всё с первого раза, чтобы потом не переделывать, не факт, что «более ленивые» — программируют хуже)
Но я всё-таки так активно язвил немного по другому поводу. Не то чтобы я настолько не верил в менеджмент, но в большинстве случаев кадровые решения о ИТ-спецах принимаются людьми мало что понимающими в ИТ, в отличие от многих других сфер среднестатистической фирмы\компании. А коль так, то и оценка эффективности далека от объективности :( Поэтому, увы, попытка разделить имеющихся ИТ-спецов на «хороших» и «нормальных», на самом деле разделит их скорее на «более ленивых» и «менее ленивых»)
А вспоминая поговорку о том, что ленивый человек делает всё с первого раза, чтобы потом не переделывать, не факт, что «более ленивые» — программируют хуже)
Прекрасно понимаю вас, когда вы говорите о проблеме менеджеров, которые руководят программистами не понимая специфики дела. Больная тема для 99% программистов, наверное. Мне кажется единственный выход — это правильная организация иерархии. Есть директор фирмы (абстрактный начальник над отделом программистов). Есть зав отдела программистов. Есть программисты. Директор не обладает знаниями о программировании; зав отдела обладает. Тогда директор должен общаться с зав отделом не-программерсикими терминами («нам нужно, чтобы вот здесь кнопка была красного цвета»). И тогда уже зав отдела должен провести программерский анализ задачи («ага. для того, чтобы поменять цвет, нам нужно вот тут расширить архитектуру и вот зайдествовать такую-то отрасль программирования. У нас Петя — герой по архитектурам, и Вася — ветеран труда по вопросам создания красного цвета в Джава».) И директор не имеет права принимать кадровые решения внутри отдела. Пускай зав отдела нанимает/увольняет программистов согласно своему виденью. Если прошел указаный срок, а красная кнопка так и не появилась, то директор может лишь уволить зав отдела, т.к. зав отдела не справился с задачей. Директор должен понимать, что он не обладает достаточным количеством знаний для того, чтобы сказать, что это Петя не успел вовремя расширить архитектуру под красную кнопку.
А вот тут уже вступает в силу новый этап танцев с бубном.
С одной стороны, получается, что зав.отдела делегируется карт бланш на кадровую политику отдела. И казалось бы — в этом есть логика. Да только вот всё тормозится на первом «умном лентяе», который не захочет писать «по собственному». Ведь, чтобы просто так взять кого-то и уволить, нужно либо компенсировать (а лишним тратам шеф рад не будет), либо искать причины «увольнения по статье» или «нарушения трудового контракта». И вот тут-то возникает замкнутый круг:
Если у специалиста в труд.контракте или в должностном регламенте ЧЁТКО указаны обязанности, то делегирование прав увольнения/добора у зав.отдела — излишне, так как «строго написанное», можно строго же и спросить даже при минимальном знании не то, что «ИТ», а даже «ПК». Если написано — «создавать 99.99% аптайм серверов», то проверяющему не нужны знания — бери секундомер и замеряй аптайм ;)
А если же чего-то чёткого не написано, то значит, что передача задач от спеца к спецу (для оптимизации процесса по мнению зав.отдела) — возможна, а вот увольнение за несоблюдение абстрактных требований — уже нет.
И, это я к чему… Первый умник, который начнёт качать свои права и говорить, что не уйдёт по собственному, а что делать — мне никто не «намекал» — а в результате страдает результативность отдела — вылетает с должности зав.отдела.
Вот, если этот замкнутый круг как-то можно было бы исключить, тогда я целиком и полностью поддерживаю Вашу модель ИТ-сектора в фирме/компании как «автономии».
С одной стороны, получается, что зав.отдела делегируется карт бланш на кадровую политику отдела. И казалось бы — в этом есть логика. Да только вот всё тормозится на первом «умном лентяе», который не захочет писать «по собственному». Ведь, чтобы просто так взять кого-то и уволить, нужно либо компенсировать (а лишним тратам шеф рад не будет), либо искать причины «увольнения по статье» или «нарушения трудового контракта». И вот тут-то возникает замкнутый круг:
Если у специалиста в труд.контракте или в должностном регламенте ЧЁТКО указаны обязанности, то делегирование прав увольнения/добора у зав.отдела — излишне, так как «строго написанное», можно строго же и спросить даже при минимальном знании не то, что «ИТ», а даже «ПК». Если написано — «создавать 99.99% аптайм серверов», то проверяющему не нужны знания — бери секундомер и замеряй аптайм ;)
А если же чего-то чёткого не написано, то значит, что передача задач от спеца к спецу (для оптимизации процесса по мнению зав.отдела) — возможна, а вот увольнение за несоблюдение абстрактных требований — уже нет.
И, это я к чему… Первый умник, который начнёт качать свои права и говорить, что не уйдёт по собственному, а что делать — мне никто не «намекал» — а в результате страдает результативность отдела — вылетает с должности зав.отдела.
Вот, если этот замкнутый круг как-то можно было бы исключить, тогда я целиком и полностью поддерживаю Вашу модель ИТ-сектора в фирме/компании как «автономии».
Хороший программист пишет код где-то с такой же скоростью, как и нормальный…
После этого даже читать не хочется…
www.youtube.com/watch?v=wCVwdvufTds&feature=share
После этого даже читать не хочется…
www.youtube.com/watch?v=wCVwdvufTds&feature=share
Детский лепет :-)
Идея в общем понятная, что хороший программист лучше плохого программиста, но практика бывает такая что умный программист ничего сделать не может, потому что ему мешает его ум и самомнение. А средний программист, тихо и простой палкой копалкой может сделать хороший продукт.
Идея в общем понятная, что хороший программист лучше плохого программиста, но практика бывает такая что умный программист ничего сделать не может, потому что ему мешает его ум и самомнение. А средний программист, тихо и простой палкой копалкой может сделать хороший продукт.
НЛО прилетело и опубликовало эту надпись здесь
Точно. Я работал в коллективе где много рассуждали, кто какой код пишет, у кого код крутой, а кто «ремесленник».
А по реальным показателям, крутой код был еще более глючный и не всем хотелось с ним работать, потому что слишком сложно написано. Хрен знает.
А по реальным показателям, крутой код был еще более глючный и не всем хотелось с ним работать, потому что слишком сложно написано. Хрен знает.
Моя субъективная позиция по считанию количества фич/строк кода/любой другой измерительной метрики — это плохая практика. Мне кажется, что программирование невозможно выразить в какой-то плоской одномерной метрике. Ведь есть еще качество кода. Кто-то быстро шлепает фичи, которые поддерживать в будущем будет очень трудно. Кто-то уделяет больше времени вопросам архитектуры, которые в «фичах» не особо и померяешь, т.к. фичи зачастую это какие-то конкретные полезные плюшки для конечного потребителя программы. А еще есть просто программист-хороший-парень, который поддерживает сплоченность коллектива и уделяет много внимания «прокачиванию» малоопытных членов команды. Мне кажется, хороший менеджер должен уметь «чувствовать» все эти вещи.
Отнюдь… я не пытался сказать, что хороший программист лучше плохого программиста. Я думал это очевидно по моим выводам. Я руками и ногами за то, чтобы профессионализм внутри команды был сбалансированным.
По поводу среднего программиста, который палкой-копалкой может сделать продукт — я понимаю вашу мысль, очень часто наблюдал похожии ситуации. Только у нее есть и другая сторона медали. Не скажу, что это случается всегда, но иногда может быть так, что через год-два после сопания кода средненьким программистом, оказывается что проект очень запутанный и сложный в своей архитектуре. И может быть «творческий кризис» супер-программиста в самом начале пути как раз и был нацелен на упреждение этой проблемы. А иногда да, они просто безосновательно маются от «творческого кризиса» :) Моя любимая статья на эту тему: www.joelonsoftware.com/items/2009/09/23.html :)
По поводу среднего программиста, который палкой-копалкой может сделать продукт — я понимаю вашу мысль, очень часто наблюдал похожии ситуации. Только у нее есть и другая сторона медали. Не скажу, что это случается всегда, но иногда может быть так, что через год-два после сопания кода средненьким программистом, оказывается что проект очень запутанный и сложный в своей архитектуре. И может быть «творческий кризис» супер-программиста в самом начале пути как раз и был нацелен на упреждение этой проблемы. А иногда да, они просто безосновательно маются от «творческого кризиса» :) Моя любимая статья на эту тему: www.joelonsoftware.com/items/2009/09/23.html :)
10 отличий между хорошим и нормальным программистомНасчитал 5.
Судя по другой статье, вы программист, однако в этой статье рассуждения какие-то бессистемные что ли. Намешано в кучу все: зарплата, опыт, ум, трудолюбие и т.д. Слог неплохой, но я не понял, зачем я это прочел и что я должен был усвоить из этой статьи. Нанимать только хороших программистов? Спасибо, кэп.
Может быть стоило сосредоточиться на чем-то одном, например на том, что обещано в заголовке? Ну или заголовок подправить, к примеру, «Пространные рассуждения о хорошем программисте».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 отличий между хорошим и нормальным программистом