You Weren't Meant to Have a Boss
Jan. 12th, 2009 08:58 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
recoderПрошлым летом я почему-то не уделил должного внимания очередному крайне увлекательному эссе Пола Грэма "You Weren't Meant to Have a Boss". А на исходе года опять перечитал и много обдумывал, отрабатывая в офисе christmas bogus с 5 января.
Пишет Пол о различиях между большими и маленькими компаниями. И хотя, насколько я знаю, сам Пол в настоящих мега-корпорациях не работал, суть процессов в них он подмечает очень верно. Тенденцию роста компаний он сравнивает с вытеснением junk food'ом нормальной еду - то есть технологической заменой естественных процессов упрощёнными и часто вредными, но простых в производстве и управлении.
Исторически, у каждого вида животных складывались оптимальные размеры групп в зависимости от стиля жизни. Для охотников-собирателей вида Homo Sapiens такой размер - порядка дюжины; уже два десятка человек сложно координировать, а больше - и подавно. Поэтому любая большая компания традиционно вводит иерархическую структуру и вводит новую роль "босса" (менеджера).
Таким образом получается, что что боссу на своём уровне приходится представлять всю свою группу как один "виртуальный" человек. В результате, чтобы всем участникам группы вписаться в этот образ, им приходится ограничивать свою свободу внутри неё. И чем выше дерево иерархии, тем больше ограничений спускается вниз. Впрочем, ограничение свободы проявляется и у самого босса - ему приходится делегировать часть своих задач вместо того, чтобы выполнять их.
Для нас, программистов, эти ограничения сказываются особенно тяжело, потому что они идут вразрез с самой творческой, созидательной сутью программирования. И чем больше иерархия наверху, тем больше она сопротивляется нововведениям. Дальше тенденция закрепляется: чем меньше нового получается сделать - тем меньше учишься, и чем меньше учишься - тем меньше новых идей приходит в голову. И начинает проявляться Эффект Мёртвого Моря: из компании вымываются инициативные и активные работники, а любители монотонного труда - продвигаются и укрепляют свои позиции. Компания начинает движение к Последней Стадии.
Выход из этого болота Пол видит в отказе от древовидной иерархии. К примеру - декомпозиция всей иерархии с выделением отдельных групп в независимые единицы, взаимодействующие но не подчинённые друг другу. Однако такой процесс сложен и не гарантирует большого выигрыша в эффективности.
Более простой выход для компании - это просто не расти (а точнее - оставаться как можно меньшими). Правда в этом варианте компании будут нужны самые лучшие работники. Наём слабых кадров бьёт сразу по двум направлениям - они делают меньше и хуже, и этим самым вынуждают раздувать штат для выполнения тех же объёмов работ. Рост штата среди прочего опасен и тем, что компетентные люди вымываются вверх по иерархии в менеджеры, воплощая принцип Питера в жизнь.
Из всего этого Пол заключает, что работа маленькими группами - самая естественная среда для настоящего программиста. И оптимальная стратегия поиска работы для амбициозного программиста - именно поиск небольших компаний. (Ну и приглашает приходить к нему в Y!Combinator со своими стартапами.)
Интересно, что молодёжь на Y!combinator'e оказались в основном в поддержку такой позиции, а более серьёзные дядьки на Reddit'e оказались гораздо более критичны. Видимо, с определёнными навыками можно неплохо устроиться и в большой конторе.
В общем, есть о чём подумать холодными зимними вечерами...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-01-12 08:32 am (UTC)Вы знаете, для меня единственным допустимым творчеством в программировании является искоренение вскякого творчества. Прогаммист работу работает, а не собственные амбиции за чужой счет удовлетворяет.
Остальные утверждения если не столь вызывающи, то не менее спорны, например "И чем выше дерево иерархии, тем больше ограничений спускается вниз" - это абсолютно голословное утверждение.
В общем, несогласный я с ними.
no subject
Date: 2009-01-12 08:46 am (UTC)no subject
Date: 2009-01-12 09:00 am (UTC)В наиболее плохом случае (1 дурак и 10 баранов) имеем километры говнокода и всеобщий консенсус, что гораздо лучше, если у нас 10 творцов: в последнем случае имеем километры творческого говнокода и полный раздрай вплоть до мордобития. Если первое обычно как-то работает и в нем более-менее реально разобраться, то второе не работает, осмыслению не поддается и все это происходит на фоне перманентного всеобщего столкновения творческих личностей.
Нет, творчество допустимо только в contemporary art. Во всех остальных областях человеческой деятельности - ну его нах.
no subject
Date: 2009-01-12 09:19 am (UTC)Поймите, что творчество — это не анархия! Применение нужного алгоритма или паттерна (вместо copy-paste) в нужных ситуациях — это тоже творчество.
no subject
Date: 2009-01-12 09:35 am (UTC)В моем понимании не армейская дисциплина, как Вы ее понимаете, а армейская дисциплина "каждый солдат знает свой маневр". Все решаемые программистом задачи должны быть ему знакомы и решаться стандартным, общепринятым в данной команде способом. Если программист самостоятельно обнаруживает нестандартную задачу - это недоработка руководителя: при выдаче задания руководитель должен либо сказать "все, как обычно", либо "обрати внимание на то-то и то-то: делать так и только так", либо "а давайте все вместе подумаем, как с этой байдой разобраться". Последнее должно встречаться чрезвычайно редко.
Поймите, что творчество — это не анархия! Применение нужного алгоритма или паттерна (вместо copy-paste) в нужных ситуациях — это тоже творчество.
Я и говорю - не должно быть таких ситуаций. Действительно нетривиальные задачи встречаются весьма и весьма нечасто, раз в год, примерно.
Впрочем, если с самого начала творить, то такие задачи будут пачками каждый день.
no subject
Date: 2009-01-12 01:23 pm (UTC)no subject
Date: 2009-01-12 01:36 pm (UTC)Петя гулял в лесу и нашел под кустом ежика. Он пpинес его домой и ежик стал жить у Пети. Днем ежик спал, а ночью смешно топал по кваpтиpе. Он
любил пить молоко и гpызть соленые оpешки. Петины дpузья и
одноклассники заходили посмотpеть на ежика. Он им тоже очень нpавился.
Летом петина семья поехала на дачу. Ежика тоже взяли с собой. Hа даче
ежик стал жить в саду. Там он охотился на гусениц, жуков и чеpвяков.
Ежик пpиносил пользу саду и огоpоду, там пеpестали водиться кpоты. Еще
ежик очень любил купаться в тазу с водой. Пpи этом он смешно фыpчал и
плескался. К концу лета у ежика выpосли очень длинные колючки, лапки
покpылись чешуйками. Еще у ежика выpосли два pога, один спеpеди, дpугой
сзади. Глаза стали очень большие и фасетчатые. Ежик больше не купался в
тазу с водой.
И тогда все поняли, что Петя пpинес из лесу не ежика, а х?й знает что.
Когда проектирование ПО научатся так же четко регламентировать, как обтачивание болванок - тогда и в программировании творчество исчезнет.
Задача руководителя именно в этом и состоит.
no subject
Date: 2009-01-12 01:47 pm (UTC)no subject
Date: 2009-01-12 02:19 pm (UTC)no subject
Date: 2009-01-12 02:30 pm (UTC)no subject
Date: 2009-01-12 02:39 pm (UTC)Проще перековывать унылых студентов в унылых качественных кодеров
Это не так просто, как кажется. Унылый качественный быдлокодер - товар штучный, его надо холить и лелеять. Он и границы своей компетентности осознает, и в своих границах действует аккуратно, ровно и с минимальным количеством ошибок. Он может подряд несколько недель двигать и вертеть какой нибудь блок так-сяк и туда-сюда, в порядке следования противоречивым указаниям менеджмента, а потом его на месте отрихтовать попиксельно, и статистику какую-нибудь готов пересчитать, и высунуться с хорошей, на его взгляд, идеей - но высунуться, а не забить на все и с головой броситься ее реализовывать наживую - и нередко идеи оказываются великолепные, и подверстать что срочно и по мелочи. Унылый качественный кодер - это очень, очень ценный кадр.
а тонких чувствительных творцов - в тонких чувствительных руководителей
Как же ж его перековать в руководителя, если он сам собой уруководить не в состоянии?
Ой как всё запущено...
Date: 2009-01-12 01:59 pm (UTC)Когда из программирования исчезнет творчество - программиста надо будет заменить компилятором. Или другим инструментом, как токарь заменяется умным станком.
Задача руководителя именно в этом и состоит.
Ни фига. Такая задача стоит у архитектора или технического менеджера.
Re: Ой как всё запущено...
Date: 2009-01-12 02:16 pm (UTC)Творить, как я погляжу, тянет неудержимо? :-)
У нас разные понятия о хорошем программисте. У Вас он - Творец, Демиург новых миров, Начало и Конец, Альфа и Омега... У меня - качественный быдлокодер. Знаете, это чисто практический подход - мне приятнее, когда стоматолог или автомеханик говорят "а, это...", а не орут "Вась, гряди, какая странная хреновина!". Почему-то мне кажется, что так разумнее, что ли.
Любопытно, кстати, что качественные быдлокодеры встречаются совсем нечасто. В основном, конечно, прут Демиурги. Или вообще какие-то случайные люди. Последние, правда, лучше тем, что им творить лень.
Ни фига. Такая задача стоит у архитектора или технического менеджера.
Ну пусть так.
Re: Ой как всё запущено...
Date: 2009-01-12 02:31 pm (UTC)И, кстати, быдлокодер-медик не говорит «а, это…», он говорит «выпейте аспиринчику, следующий». Разницу чуете?
Ну или Вы специально проповедуете тут False Dichotomy.
Re: Ой как всё запущено...
Date: 2009-01-12 02:47 pm (UTC)Вы знаете, как говорили римляне, audiatur et altera pars, так что о случае по ссылке я судить не берусь. В порядке дискуссии хотелось бы заметить, что "подчиска последствий" продолжается все время жизни проекта. По одному некогда популярному веб-проекту, проходившему через мои руки, таски ставили чуть ли не до дня его смерти. Работа необходимая, хотя совершенно нетворческая, и это очень здорово - она предсказуема по срокам и результатам, в отличие от творческой.
И, кстати, быдлокодер-медик не говорит «а, это…», он говорит «выпейте аспиринчику, следующий». Разницу чуете?
Да хотя бы и аспирину, а не "близорукость? мы вам ща глаза новые пришьем, экспериметнальную партию из морга прислали".
Re: Ой как всё запущено...
Date: 2009-01-13 10:29 pm (UTC)тут либо терминологическое недопонимание либо принципиальное
1. вот у вас небольшой проект в начальной стадии
вы подумали над архитектурой в общих чертах
не заглянули в книгу "как проектиировать большой и малый тдыщ"
а подумали - творческий процесс, угу?
вы не трех-головый и поэтому с этой задачей в одиночку бороться не комильфо
если команда небольшая то весьма вероятно что вам в этом будут помогать толковые разработчики
(назовите их lead'ами или еще хрен знает как
но в небольшой команде это будут какие-то разработчики
и заниматься они будут творчеством)
2. допустим у вас большая команда и есть архитектор (look how lucky you are!)
ну сваяли вы архитектуру в общих чертах - пора бы передавать отдельные модули на разработку конкретным людям
способов реализовать тот или иной модуль бывает несколько (в начале проекта-то)
а у вас быдлокодеры и у них вопросы. много.
они заглянули в "большой и малый тдыщ" но в глоссарии нет пункта "стандартные подходы для инвентаризации банков телефонных номеров"
и архитектурное чутье молчит (по определению)
значит или не дай бог сдалаем как-нибудь побыстрее
или будем писать вопросы. много. без предложений и ярких идей.
можно написать этим балбесам уйму документов (по времени иногода сравнимо с реализацией самому)
и убить кучу своего времени и времени тольковых разработчиков (lead'ов)
и это работает (хотя опыт показывает что за всем усладить невозможно)
но мне не кажется такой подход оптимальным
наиболее сильно минусы такой команды:
- трудности в начале проекта когда нет отточеной строевой
- тонна сверху станартного набора документов для реализации
- невозможность оперативно решать проблемы особенно если команда распределенная
- проблемы когда ключевые люди уходят в отпуск
- наконец это очень скучно. нет правда, в этом нет драйва а значит нет мотивации а это источник новых проблем
p.s.
проблемы творческого программирования озвученные вами
("километры творческого говнокода и полный раздрай вплоть до мордобития" и проч)
ни сколько не доказывают недееспособность этого подхода
скорее рождают вопросы по организации работы
- есть design review, code review и много других полезных вещей
которые призваны идентифицировать подобные проблемы заранее
Re: Ой как всё запущено...
Date: 2009-01-12 02:27 pm (UTC)Re: Ой как всё запущено...
Date: 2009-01-12 02:40 pm (UTC)no subject
Date: 2009-01-12 01:12 pm (UTC)no subject
Date: 2009-01-12 02:00 pm (UTC)А вообще они говорят, как мне казалось, вещи довольно очевидные, хотя и требующие громадной силы воли для воплощения в жизнь.
no subject
Date: 2009-01-13 02:14 am (UTC)Задача руководителя подтолкнуть подчиненных на эту идею. Люди очень сильно внушаемы и поддаются "гипнозу". И изначально каждый имеет очень огромный талант и скрытые возможности.
Есть недостаток знаний, на приобретение которых для разных людей надо разное время.
no subject
Date: 2009-01-13 09:41 am (UTC)no subject
Date: 2009-05-12 02:01 pm (UTC)* .. нормальной _еду_ ..
* .. заменой .. процессов .. упрощёнными .. , но _простых_ в производстве и управлении.
А в целом, солидарен :)
no subject
Date: 2009-05-12 02:04 pm (UTC)