воскресенье, октября 19, 2008

Идеальный программист

«Каждый охотник желает знать, где сидят фазаны»
Считалочка (физика, оптика).

"Программист который познакомился с новой технологией похож на маниака получившего в подарок новенькую бензопилу. Ему не терпится ее опробовать"
(с) утерян.


Каждый менеджер хочет иметь в своей команде хороших программистов. Каждый программист хочет, чтобы его ценили, регулярно прибавляли ему зарплату и не заставляли работать в выходные.
Среди самих программистов есть мнение, что хороший программист – это продвинутый программист, тот который изучает последние технологии, методы и веяния. Сегодня актуально TDD, FDD, AOP, IoC/DI, и принципы ALT.NET. Что бы быть в струе, надо все это знать, все это юзать, и даже, если не лень, писать об этом в своем блоге. Это круто и необходимо для хорошей карьеры и зарплаты. Я должен вас разочаровать - но все это гламур, в самом уничижительном значении этого слова. Все это необходимый фундамент для хорошего программиста, но не более того.

Больше всего на рынке нынче ценится не "умный программист", и не "продвинутый программист", и даже не "опытный программист". Больше всего ценится "эффективный программист". Тем более это актуально для тим-лида. Любой менеджер проекта, отдаст пол своей проектной команды за одного такого. А уж найти «эффективного архитектора» который был бы и технически грамотным и не зацикленном на каком нибуть IoC-е, и вовсе проблема.

А кто такой «эффективный программист»? Почему недостаточно быть «умным» и «продвинутым»? Многие получают кайф от программирования как такового, с энтузиазмом изучают все новое, и вообще, считают это способом самовыражения. Спору нет, программирование процесс творческий, но не стоит забывать, что цель его достаточно прозаическая, а именно производство программного продукта и получение прибыли. И вот такие программисты "самовыраженцы", это просто головная боль для тех людей, которые занимаются организацией разработки. Умные, слов нет, все делают правильно и по понятиям, но проект завалят практически гарантировано. Просто будут сидеть и спорить, какой фрэймворк лучше прикрутить, и не заметят как дэдлайн прошел.

Вот недавно была история на одном проекте. Выпустили ребята первую версию продукта, были там недостатки определенные, но решили продукт развивать, набрали новых людей. Пришли ребята продвинутые, посмотрели на код первой версии (а надо сказать, что код там был дрянной) и решили, что нужен рефакторинг, компоненты выделить, архитектуру улучшить и все такое… Ну и занялись, заодно фрэймворк модный прикрутили, модульные тесты писать начали, для тестов весь дизайн пришлось переделывать. Оглянуться не успели - через два дня дэдлайн, надо показывать большому босу работающий прототип. Ну что делать, все в разобранном виде, к дэдлайну не успели. Устроили им разнос, прописали жесткие сроки, мэйлстуны. К новому сроку ребята поняли, что не успевают опять, сделали прототип на соплях с подпорками. Ну и дальше вся работа шла в жесточайшем таймауте и под прессингом руководства. Проект они закончили с задержкой на три месяца, качество было не очень, все были разочарованы, и измучены. Большая часть команды потом уволилась.

Вот такая печальная присказка. И ведь цели благие были: улучшить дизайн и код, чтобы сделать хороший продукт. Все верно. Только формулу надо было развернуть наоборот: сделать продукт с заданным качеством и функционалом и в срок, а для этого улучшить дизайн и код (среди прочего). Если бы разработчики думали именно так, то и проблем с проектом у них бы не было, ведь квалификации у них было достаточно.
Однако, вернемся к нашему «эффективному программисту». Нам понятно, знания и стремление к техническому совершенству это важно, но недостаточно для успеха. Не менее важна ориентация на результат, инициатива и надежность человека. Эти три качества превращают «умного» и «продвинутого» программиста в «программиста эффективного».

Эффективный программист понимает, что код, дизайн и архитектура это не цель его работы, а лишь средство достижения цели.
Эффективный программист движется к цели, минимизируя затраты усилий и риски неудач.
Эффективный программист умеет правильно оценить сложность задачи и выполнить ее в срок.
Эффективный программист, это ремесленник в лучшем смысле этого слова, который в совершенстве овладел своими инструментами и методами их использования. Продукты его ремесла, это настоящая «ручная работа», качественные, красивые, удобные.
Эффективный программист любим менеджерами и при желании быстро продвигается по карьерной лестнице.

В общем, ребята, налегайте на soft skills, если хотите карьерного роста.

22 комментария:

GiNeR комментирует...

Вот это в яблочко. Всё тоже самое касается не только программистов, но и системных администраторов.

Анонимный комментирует...

Спасибо, очень хорошая статья

Илья Казначеев комментирует...

В кои-то веки - возразить нечего.

Александр Кондуфоров комментирует...
Этот комментарий был удален автором.
Александр Кондуфоров комментирует...

Согласен с выводами, но не с примером. Да, программисты - люди увлечённые, поэтому иногда их нужно вовремя останавливать. Но в то же время часто эффективность может быть следствием использования человеком TDD, AOP, IoC и других страшных слов. Да, любая технология должна использоваться не потому что это сейчас модно и все мои друзья мне уже все уши об этом прожужжали, а только исходя из соображений своей эффективности и полезности в данное время и в данном месте. А здесь уже все средства хороши, "гламурные" или нет, лишь бы проект был сдан в срок и соответствующего качества. Здравый смысл и прагматизм здесь превыше всего.

Chabster комментирует...

> но решили продукт развивать, набрали новых людей
Кто решил, программисты?
> Пришли ребята продвинутые, посмотрели на код первой версии (а надо сказать, что код там был дрянной) и решили
Вот так вот пришли и решили. Как фирма называется? Я прийду и решу себе зарплату в 1000000$ поставить. Можно?
> Большая часть команды потом уволилась.
А уволить нужно было менеджера. Вот такая печальная присказка.

Анонимный комментирует...

Полный отстой!
Сразу видно писал менеджер, для которого цель в жизни надуть в уши клиента что его команда может спроектировать и построить Боинг с расходом топлива как у мотороллера за пол года, а потом если что не получиться свалить все на "программистов".
...А если всеже удастся выходя на работу в выходные и ночуя там постороить этот Боинг, используя клей ПВА вместо сварки "под его ответсвенность", то будет бить себя в грудь и кричать: "какой я молодец!".
...Если Боинг всеже развалится в процессе эксплуатации, то скажет: "Я молодец, я смог закончить проект в срок, а программисты мудаки чего-то там сделали не в соответсвии со спецификацией"

Big 40wt Svetlyak комментирует...

Анонимусов ф топку.

Статья хорошая. Прямо вижу, что лично мне еще есть, к чему стремиться :)

Анонимный комментирует...

Все по делу. Так оно и есть.

Livce комментирует...

Как всех зацепило...
У автора, похоже, наболело; у читателей, похоже, тоже...
Смотритека как можно рассматривать "посыл", с одной стороны (программеров) и с другой стороны (менеждеров). Те и другие, друг на друга обижены. Ну така ситуация, скорее, в командах с не здоровой атмосферой. Ну передёрнул автор немного для красного словца. Так проблема ж всё равно описана точно, оттого и торкнуло многих. Зрите в корень.

Sergey Rozovik комментирует...

>Анонимный пишет...
>Полный отстой!

>Анонимный пишет...
>Все по делу. Так оно и есть.

Аноним анониму рознь :))

Igor комментирует...

Всем срочно перечитывать "Программиста-прагматика" :)

Warvick комментирует...

Это 5! :)
Но как, черт побери, иногда руки чешуться опробовать что-нибудь свеженькое в текущем проекте :).

Анонимный комментирует...

Многое очень верно подмечено, но как уже выше указали, вина за слив такого (а сам добавлю –_любого_) проекта лежит исключительно на менеджменте. Программист – это фактически инструмент. Может копать, может не копать. Кто-то копает быстро, кто-то красиво, кто-то медленно и криво. Но все копают. А куда копать, что копать и когда надо выкопать – решать и контролировать исключительно бригадиру, т.к. спрос будет только с него.
Еще в описании чувствуется видимо специфика работы в аутсорсинговых проектах. Как человек, проработавший 8 лет в аутсорсинге, и 4 года непосредственно у конечных заказчиков, хочу заметить, что это 2 разных мира.
В аутсорсинге сроки и прибыль всегда стоят на 1-м месте. Даже такими грязными методами, как приписывание мертвых душ на проект и т.д.
Во многих западных компаниях качество продукта более приоритетно. Эти фирмы, типа того же Майкрософта, сами определяют правила игры. Если решат перенести релиз, то перенесут. И все покупатели будут тупо ждать.
Потому что разгребать проблемы с багами на стороне клиента на 2 порядка дороже, чем у себя. Особенно если эти баги были отлиты в железе (вспомним последнюю историю с NVidia)

Andrew комментирует...

Согласен с Chabster на 100%.
Увлоьнять надо было менеджера.

А вообще мне кажеться, что в этой истории менеджера вообще не было. Ну а чаще всего, там где его нет, - грех жаловаться.

А вообще идея "эффективного программиста" мне нравится. Сам таким был. :-)

irium комментирует...

Да, статья абсолютно правильная, хотя согласен с теми, кто считает, что в приведенном примере виноват прежде всего менеджер. Именно поэтому очень важно иметь "эффективного" тим-лида (не важно, архитектор он или ведущий программер) - который с одной стороны ориентирован на результат, и понимает, что "рюшечки" - инструмент, а не самоцель, а с другой - видит ситуацию "изнутри", понимает, что происходит и чем это грозит (в плане сроков итп).

Voice комментирует...

Как скомканый кусок глины не является скульптурой, так беспорядочный набор кода не является программой.
(с)

Анонимный комментирует...

Только не понятно зачем эффективному программисту работодатель.

Sergey Rozovik комментирует...

> Только не понятно зачем эффективному программисту работодатель.

Чтобы быть сам себе работодателем, нужен совсем другой набор качеств.

mt комментирует...

Я тоже поддерживаю мнение о неефективном менеджменте - давайте посмотрим на рассказанную историю:

- вначале людям дали свободу и они делали, что хотели;
- потом, они не вписались в дедлайн и им устроили разнос и поставили новый дедлайн;
- они опять не вписались и тогда их начали насиловать каждый день, чтобы они вписались в сроки.

Вопрос в том, что делал менеджер до первых двух дедлайнов? Похоже, самоустранился.
А что делал потом? По-военному: купил вазелин и пошел "управлять"

Теперь посмотрим с точки зрения разных людей:
- програмист: "как только начали переделывать по нормальному, пришли уроды-менеджеры и все испортили"
- менеджер: "эти умники завалили весь проект"
- HR: "нашли им нормальных програмистов, а они их через полгода выгнали"

И кто выиграл? Никто.

Не бывает "эфективных" програмистов, бывают програмисты, которые эфективно выполняют какую-то работу и Задача Менеджера поставить человека туда, где он будет работать максимально полезно.

p.s. Мне очень понравился комментарий про лопату: лопатой можно копать, а можно забивать гвозди, но проще все таки копать, а забивать молотком.

Анонимный комментирует...

Sergey Rozovik, очень надеюсь, что вы на меня не очень обидитесь, равно как и многие, оставлявшие тут восторженные комментарии.

Вы просто находитесь на не очень высоком уровне понимания, что ли...

И очень похоже на то, что пагубную роль в этом сыграли шаблоны, насаженные пресловутым MBA.

Видите ли, понятия ЭФФЕКТИВНОСТИ и РЕЗУЛЬТАТИВНОСТИ, во-первых, НЕ СВОДЯТСЯ к экономическим категориям. То, что современные "манагеры" склонны именно этим все и всех мерять, и вот такие манагеры нами во многом и правят - не побоюсь сказать, трагедия современного человечества.

Так что цель производственных коллективов вообще и программистских в частности - вовсе не только извлечение прибыли. Попытайтесь это понять.

Кроме того, даже в рамках вашей парадигмы вы чересчур ограничиваете свой "горизонт". Конкретный срок сдачи конкретной версии продукта не должен быть самоцелью, рассматриваемой в отрыве от контекста, например - стратегических целей и интересов заказчика (а тут как раз могут сработать более качественные решения в плане платформы), и уж ни в коем случае - не подлежит некоему обожествлению.

Sergey Rozovik комментирует...

Ни в коем случае :) Очень интересно послушать альтернативные мнения.

> Вы просто находитесь на не очень высоком уровне понимания, что ли...

И очень похоже на то, что пагубную роль в этом сыграли шаблоны, насаженные пресловутым MBA.


Во-первых, я никогда не обучался на MBA. Я вообще не менеджер (на данный момент по крайней мере). А понимание того в чем состоит эффективность, действительно сильно зависит от точки с которой мы смотрим на проблему. В зависимости от точки зрения, "горизонт" о котором вы говорите, будет расширяться или наоборот, сужаться.
У программиста будет один взгляд на эффективность. Эффективность для обычного программиста это скорее эффективный код и эффективный инструмент. А на уровне команды эффективность для программиста - это хорошая зарплата и вменяемый менеджер, который решает все проблемы и не мешает работать.
Если встать на ступеньку повыше, то "горизонт" расширится и понятия эффективности сместятся. Мало того, на этом уровне "программистская эффективность" вступает в противоречие в "менеджерской эффективностью". Если мы поднимемся еще на ступеньку вверх, на уровень владельца бизнеса, то тут опять свой "горизонт" и свое понятие об эффективности, которое опять же может не совпадать с "эффективностью линейного менеджера". Можно сделать шаг в сторону с этой пирамиды и говорить о совершенно других понятиях эффективности, например, с позиций самоактуализации, высказанных Абрахамом Маслоу.
И мой пост был о том, что программисту достаточно немного приподнять голову, и взглянуть на вещи, которыми он занимается немного с другой стороны, чтобы получить очень неплохие бенефиты для себя, и принести больше пользы бизнесу, в котором он принимает участие.
В вашем же выступлении много пафоса, но совершенно нет конкретики. Я готов согласиться, что "понятия ЭФФЕКТИВНОСТИ и РЕЗУЛЬТАТИВНОСТИ, во-первых, НЕ СВОДЯТСЯ к экономическим категориям", но потрудитесь пояснить к чему же по вашему сводится понятие эффективности.