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

[recoder]

Ясно. У нас разное понимание слова творчество. Я его использую дословно, то бишь как процесс творения, создания чего-то нового. А в вашем мире получается, что «творчество» == «говнокод» и единственная альтернатива этому — это армейская дисциплина в стиле «я начальник — ты дурак». И мне кажется это именно следствие общего низкого уровня кадров.

Поймите, что творчество — это не анархия! Применение нужного алгоритма или паттерна (вместо copy-paste) в нужных ситуациях — это тоже творчество.

[plumqqz.livejournal.com]

Ясно. У нас разное понимание слова творчество. Я его использую дословно, то бишь как процесс творения, создания чего-то нового. А в вашем мире получается, что «творчество» == «говнокод» и единственная альтернатива этому — это армейская дисциплина в стиле «я начальник — ты дурак».

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

Поймите, что творчество — это не анархия! Применение нужного алгоритма или паттерна (вместо copy-paste) в нужных ситуациях — это тоже творчество.

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

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