Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
(no subject)
Speaker Rabbit
abbra
Френды обсуждают статью Эрика Синка о том, кому нужны Great Hackers Пола Грэхема. Вот основной цитируемый фрагмент:
"For the purpose of this article, a "programmer" is someone who does nothing but code new features and [if you're lucky] fix bugs. They don't write specs. They don't write automated test cases. They don't help keep the automated build system up to date. They don't help customers work out tough problems. They don't help write documentation. They don't help with testing. They don't even read code. All they do is write new code. In a small ISV, you don't want any of these people in your company."

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

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

Так что если и компании, и отдельных экспертов (great hackers) рассматривать как равноправные взаимодействующие субъекты в одной отрасли, то ничего нового или странного в поведении, описанном Эриком Синком, нет. Непонимание возникает именно от ложных посылок обеих сторон -- компании чаще хотят подчиненных, а не партнеров, а эксперты -- самостоятельность и инвестиции в себя.

Так что основной вопрос -- как добиться баланса. Где-то вот так.

  • 1
Очень точно.

С моей точки зрения, спецификации программист писать должен. Или хотя бы постфактум общую архитектуру описывать - reverse engeneering в случае открытого кода, конечно, существенно проще, но тоже не сахар.

Новую функциональность писать тоже должен. Баги затыкать - ну наверное, хотя тут возможны варианты.

Автоматические тесты, ИМХО, писать должен кто-то другой. Скорее всего - кодер, на это достаточно в норме более низкой квалификации - после того, как создан (программистом) Framework для этих тестов. Сценарий тестов должен вытекать из вышеупомянутой спецификации. Плюс проверки на граничные условия.

С этим никто не спорит. Я немного о другом писал :-)

А с тем, что ты написал, я согласен полностью.

Как имеющий практический опыт :)
Приглашая great hacker, ты должен понимать, нахрена ты это делаешь. И свое понимание четко отразить в договоре.
И приглашенный должен понимать, для чего его позвали. Что он будет делать - напишет новую фичу, проведет аудит кода, выступит в роли архитектора проекта.
Причем условия не должны менятся в процессе взаимоотношений.
Наиболее часто проблемы возникают тогда, когда хакера начинают использовать в роли тыбика.
Тогда и по сусалам можно получить.

Ага. Именно так. Все проблемы -- от взаимного непонимания и неустановленности отношений.

"...и неуставных отношений" =)
а вы (большие голубые) "приглашаете" great hackers? =)

Судя по тому, с кем работать приходится -- таковые есть. Тот же Andrew Tridgell или Ted T'so

ну с Tridgell несколько не тот случай, помоему. он же только своей самбой занимается, насколько я понимаю? и занимался ей до всяких ibm'ов. и продолжал бы ей заниматься без всяких ibm'ов.

Не только. У него достаточно много проектов -- тот же git получился ровно из-за того, что он начал писать программу для экспорта данных из BK, а Ларри на него за это обиделся. Да и Rsync ты его используешь, и ccache, и distcc...

Внутри IBM он тоже довольно много специфических вещей делает, как для заказчиков, так и внутренние разработки.

git, rsync, ccache и distcc - это инструменты, помогающие более продуктивно заниматься основным проектом, так что тоже не считается =)

ты попробуй, напиши эти инструменты, а потом говори об основных проектах :-)
К тому же, IBM производит как раз инструментарий, а не ПО для конечных пользователей :-)

  • 1
?

Log in

No account? Create an account