Эффективность разработчиков программного обеспечения

Простыня текста ворнинг

Максимальная эффективность программиста — это если он весь рабочий день не отрываясь, херачит, как Лев Толстой. Сразу пишет всё правильно, не отвлекается, не тратит время на отладку и компиляцию. Такого, конечно, не бывает. Но понятно, что больше, чем можно написать за день, программист за день не напишет.

Физические возможности программистов расширяют всякие IDE — интегрированные среды разработки. Они подсказывают, какие параметры у функции, предлагают параметры автодополнения, проверяют синтаксис, и вообще обеспечивают поддержку разработки кучей всяких мелких приятных штучек. В идеальном случае пишут код практически сами, под диктовку.

Также скорость письма зависит от выбранного языка программирорания. Язык с развесистым синтаксисом, длинными функциями и операторами — медленный для письма. А в пределах одного языка скорость письма определяется выбранной парадигмой программирования. Продвинутое ООП со всеми фабриками и синглтонами порождает неимоверное количество лишнего объёма кода. Говнокод с глобальными функциями и переменными из двух-трёх символов пишется в несколько раз быстрее.

Интерпретируемые языки отлаживаются значительно быстрее, чем компилируемые. Вообще Java — это медленное монструозное говнище, странно, что оно не сдохло ещё в прошлом тысячелетии, а продолжает до сих пор развиваться, и джава-программисты получают огромные деньжищи.

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

Везде очень много развелось апологетов всяких разных методик — аджайл, фигайл. Они занимаются тем, что рассказывают тривиальные вещи, до которых каждый мог бы докопаться сам, и получают за это огромное бабло. Если их так кругом много, стало быть, на них есть спрос. Если найти причину формирования этого спроса, то, возможно, можно будет понять, каким образом повысить эффективность программистов и приблизить её к идеальному физическому максимуму. Потом можно будет написать книжицу с НЛП-щиной, организовать собственную методику, и тоже её всем продавать.

Причины возникновения спроса на методики, на самом деле, легко понятны. Рыночная экономика диктует правила: кто первый, тот и сыт, кто последний, тот лох. Менеджерьё это понимает и старается гнать всё быстрее и быстрее. Потом они понимают, что просто заявлениями о том, что надо всё делать быстрее, ничего не добиться, и привлекают специально обученных людей, которые со взглядом продавцов гербалайфа устраивают для сотрудников дорогостоящие тренинги. По понятным причинам наибольшего успеха добиваются те методологии, которые рассчитаны и на разработчиков, и на менеджеров, и не являются фуфлогонством. Вот, например, скрам. Там есть так называемый спринт. В течение спринта менеджерьё к разработчикам не лезет со своими идеями и предложениями. Понимаете? Утром на планёрке доложился, как у тебя идут дела, и сидишь себе преспокойно кодишь, и никто к тебе не подбегает «ой, заказчик хочет, чтоб было побольше красненького, можешь сделать?». Хочется побольше красненького — будет новая задача на следующий спринт. Скрам популярен настолько, что можно сказать заказчику «у нас скрам, подождите до конца недели», и заказчик подождёт, даже если никакого скрама и в помине нет. Огромное спасибо продавцам скрама за то, что хоть чуть-чуть приучили менеджерьё к мысли о том, что хотелки могут исполняться не сию секунду, а в конце спринта.

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

Поэтому введение мёртвых часов просто необходимо. В эти часы все надевают наушники, выходят в оффлайн в скайпе и прочих клиентах мгновенных сообщений, закрывают всю почту, и сидят работают. Если кто-то вздумает нарушить священную неприкосновенность разработчика в мёртвые часы, то он должен иметь очень веские для этого причины, чтоб не нарваться на скандал. Ещё очень неплохо свести к минимуму количество совещаний и обсуждений. Если разработчикам надо, они сами оторвутся и всё, что надо, обсудят — стихийно, стоя в дверном проёме с чашками кофе и мешая всем ходить, а то и вовсе в туалете.

Кстати, есть ещё очень простые, суборганизационные методики повышения производительности. Например, нельзя допускать того, чтоб программисты работали в одном помещении с какими-нибудь разгильдяями типа техподдержки или сервисдеска, которые постоянно смотрят тупые ролики в интренете и болтают. То же самое и с менеджерами. Менеджеры, может, не смотрят тупые ролики в интернете и болтают не очень много, но их близость может влиять деструктивно. Волей-неволей разработчики наблюдают за менеджерами и отмечают, что сегодня вот они ходили обедать почти на три часа, как и вчера, за что им только деньги платят, дармоедам, сидят целый день трещат по скайпу и болтают по телефону!

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