You Weren't Meant to Have a Boss

[recoder]

Прошлым летом я почему-то не уделил должного внимания очередному крайне увлекательному эссе Пола Грэма "You Weren't Meant to Have a Boss". А на исходе года опять перечитал и много обдумывал, отрабатывая в офисе christmas bogus с 5 января.

Пишет Пол о различиях между большими и маленькими компаниями. И хотя, насколько я знаю, сам Пол в настоящих мега-корпорациях не работал, суть процессов в них он подмечает очень верно. Тенденцию роста компаний он сравнивает с вытеснением junk food'ом нормальной еду - то есть технологической заменой естественных процессов упрощёнными и часто вредными, но простых в производстве и управлении.

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

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

Для нас, программистов, эти ограничения сказываются особенно тяжело, потому что они идут вразрез с самой творческой, созидательной сутью программирования. И чем больше иерархия наверху, тем больше она сопротивляется нововведениям. Дальше тенденция закрепляется: чем меньше нового получается сделать - тем меньше учишься, и чем меньше учишься - тем меньше новых идей приходит в голову. И начинает проявляться Эффект Мёртвого Моря: из компании вымываются инициативные и активные работники, а любители монотонного труда - продвигаются и укрепляют свои позиции. Компания начинает движение к Последней Стадии.

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

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

Из всего этого Пол заключает, что работа маленькими группами - самая естественная среда для настоящего программиста. И оптимальная стратегия поиска работы для амбициозного программиста - именно поиск небольших компаний. (Ну и приглашает приходить к нему в Y!Combinator со своими стартапами.)

---

Интересно, что молодёжь на Y!combinator'e оказались в основном в поддержку такой позиции, а более серьёзные дядьки на Reddit'e оказались гораздо более критичны. Видимо, с определёнными навыками можно неплохо устроиться и в большой конторе.

В общем, есть о чём подумать холодными зимними вечерами...

Comments

Re: Ой как всё запущено...

[il-duco.livejournal.com]

побазарим?
тут либо терминологическое недопонимание либо принципиальное

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

2. допустим у вас большая команда и есть архитектор (look how lucky you are!)
ну сваяли вы архитектуру в общих чертах - пора бы передавать отдельные модули на разработку конкретным людям
способов реализовать тот или иной модуль бывает несколько (в начале проекта-то)
а у вас быдлокодеры и у них вопросы. много.
они заглянули в "большой и малый тдыщ" но в глоссарии нет пункта "стандартные подходы для инвентаризации банков телефонных номеров"
и архитектурное чутье молчит (по определению)
значит или не дай бог сдалаем как-нибудь побыстрее
или будем писать вопросы. много. без предложений и ярких идей.
можно написать этим балбесам уйму документов (по времени иногода сравнимо с реализацией самому)
и убить кучу своего времени и времени тольковых разработчиков (lead'ов)
и это работает (хотя опыт показывает что за всем усладить невозможно)
но мне не кажется такой подход оптимальным
наиболее сильно минусы такой команды:
- трудности в начале проекта когда нет отточеной строевой
- тонна сверху станартного набора документов для реализации
- невозможность оперативно решать проблемы особенно если команда распределенная
- проблемы когда ключевые люди уходят в отпуск
- наконец это очень скучно. нет правда, в этом нет драйва а значит нет мотивации а это источник новых проблем

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