(no subject)
Oct. 11th, 2006 11:48 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
abbraПосредством ЛОРа вышел на замечательную запись в журнале Ярослава Жешутко, в которой он описывает свой опыт общения с интересными и уважаемыми им программистами.
Их ответы, да и сам выбор людей, заставили меня задуматься -- а кого же я считаю своими учителями в Computer Science? Вопрос сложный, на самом деле, потому как, не переставая учиться у каждого программиста, каким бы он не был -- плохим или хорошим -- я в первую очередь учусь не CS, а тому, как работать и жить вместе. А взгляды, алгоритмы, методики программирования, педантичность и умение выдавать код "на гора" лишь способствуют этому.
Например, главным своим коллективным учителем я могу с уверенностью назвать две команды: Samba Team и ALT. Их нельзя рассматривать как единое целое с точки зрения выдаваемого продукта, но со всеми их проблемами, кризисами, разладами, достижениями и прорывами, это все же единые и целые учительские коллективы. Взять хотя бы Samba Team: из порядка двадцати человек, которые в него входят, лишь несколько человек имеют формальные степени (PhD, это прежде всего Dr. Andrew Tridgell), чтобы считать их формальными учителями в научной сфере. Однако примерно за половиной из них стоит история развития свободного программного обеспечения за последние 15 лет, а некоторые (такие, как Jeremy Allison и John Terpstra) непосредственно формировали внутреннее состояние POSIX-овой IT индустрии.
Линус Торвальдс, отвечая на вопросы Ярослава, заметил, что наиболее ценным качеством в программисте является вкус -- умение ценить чужую работу и умение оформить свою элегантно. Вкус является одним из основополагающих умений при работе в коллективе, он позволяет сосуществовать "единству непохожих" (Аристотель), продвигаться в своем развитии и развитии предмета исследования, каким бы он ни был. В Samba Team есть шуточная поговорка -- "членом команды становятся тогда, когда ответственному за тебя и твои патчи становится неудобно быть посредником, который ничего уже не может добавить к твоей работе".
Вкус крайне необходим и для того, чтобы это "единство непохожих" смогло расправить крылья и подняться над недостатками отдельных членов команды. Мы знаем, что часто одержимый идеей Tridge может выдать идею и код, которые совершают фундаментальный прорыв в своей области (как это случилось с тестированием CIFS), но потом вся команда на протяжении годов будет полировать и приводить в общее русло его черновые наброски, пока они не станут работать так, как этого ждут, например, заказчики Пола Грина из Stratus Technologies, у которых Samba обслуживает как биржу, так и мониторинг ядерных реакторов.
С другой стороны, требуется определенная терпимость, чтобы в таком "единстве непохожих" не разругаться и уйти до того, как твои идеи будут приняты. Многие из подходов, которые используются сегодня в Samba 4, предлагались 4-5 лет назад, но не были приняты. Потом они были "переоткрыты" другими членами команды и на их энтузиазме "въехали" в репозитарий как базовые подходы -- может быть немного в другом изложении, конечно.
Похожее было в ALT с наработками в области автоматической сборки приложений в изолированных средах. Потребовалось несколько лет, чтобы успешно применяемые реализации идей, будучи неиспользуемыми масштабно в рамках проекта, все-таки повлияли на создание следующего поколения автоматических собирателей, а теперь -- и системы совместной разработки. Правда, последнее стало возможным в том числе и благодаря конфликту между разработчиками, в котором появился git и, так уж вышло, создатель которого был в том конфликте не прав.
С другой стороны, я могу твердо назвать одним из своих учителей Юкихиро Мацумото, создателя Ruby. Его тезис о том, что язык программирования должен помогать беречь мысленную энергию программиста и то, что он должен быть естественным, а не простым, произвел со мной крайне серьезное преобразование. Результатом его стало не использование каких-то конкретных средств программирования (того же Ruby, например), но скорее образование какого-то целостного подхода к "станку", почти как у Мацуэ Басё:
Этот целостный взгляд на проект, индустрию в целом, кстати, позволяет прогнать ту юношескую горячность, которая сопровождает "быстре, выше, сильнее" в IT -- чтобы компьютеры были самые новые, программы -- самые свежие, технологии -- самые прогрессивные. Да, все это надо в определенной степени, но не более того. А иногда технологии и прорывы просто должны постоять и подождать на перекрестке, дождаться своего времени.
Возвращаясь к опроснику Ярослава, хотелось бы отметить еще замечание Дэйва Томаса о том, что же полезно для программиста -- знание формальной математики, физики или чего еще. Дэйв обратил внимание, что выдаюющиеся программисты часто обладают музыкальным слухом. Видимо, цепляются общие области мозга, а музицирование и сочинение в чем-то близки к программированию -- по крайней мере, и музыканты, и программисты большую часть своего внутреннего зрения тратят на напряженное балансирование на невидимых, но от того не менее реальных небесных струнах.
Их ответы, да и сам выбор людей, заставили меня задуматься -- а кого же я считаю своими учителями в Computer Science? Вопрос сложный, на самом деле, потому как, не переставая учиться у каждого программиста, каким бы он не был -- плохим или хорошим -- я в первую очередь учусь не CS, а тому, как работать и жить вместе. А взгляды, алгоритмы, методики программирования, педантичность и умение выдавать код "на гора" лишь способствуют этому.
Например, главным своим коллективным учителем я могу с уверенностью назвать две команды: Samba Team и ALT. Их нельзя рассматривать как единое целое с точки зрения выдаваемого продукта, но со всеми их проблемами, кризисами, разладами, достижениями и прорывами, это все же единые и целые учительские коллективы. Взять хотя бы Samba Team: из порядка двадцати человек, которые в него входят, лишь несколько человек имеют формальные степени (PhD, это прежде всего Dr. Andrew Tridgell), чтобы считать их формальными учителями в научной сфере. Однако примерно за половиной из них стоит история развития свободного программного обеспечения за последние 15 лет, а некоторые (такие, как Jeremy Allison и John Terpstra) непосредственно формировали внутреннее состояние POSIX-овой IT индустрии.
Линус Торвальдс, отвечая на вопросы Ярослава, заметил, что наиболее ценным качеством в программисте является вкус -- умение ценить чужую работу и умение оформить свою элегантно. Вкус является одним из основополагающих умений при работе в коллективе, он позволяет сосуществовать "единству непохожих" (Аристотель), продвигаться в своем развитии и развитии предмета исследования, каким бы он ни был. В Samba Team есть шуточная поговорка -- "членом команды становятся тогда, когда ответственному за тебя и твои патчи становится неудобно быть посредником, который ничего уже не может добавить к твоей работе".
Вкус крайне необходим и для того, чтобы это "единство непохожих" смогло расправить крылья и подняться над недостатками отдельных членов команды. Мы знаем, что часто одержимый идеей Tridge может выдать идею и код, которые совершают фундаментальный прорыв в своей области (как это случилось с тестированием CIFS), но потом вся команда на протяжении годов будет полировать и приводить в общее русло его черновые наброски, пока они не станут работать так, как этого ждут, например, заказчики Пола Грина из Stratus Technologies, у которых Samba обслуживает как биржу, так и мониторинг ядерных реакторов.
С другой стороны, требуется определенная терпимость, чтобы в таком "единстве непохожих" не разругаться и уйти до того, как твои идеи будут приняты. Многие из подходов, которые используются сегодня в Samba 4, предлагались 4-5 лет назад, но не были приняты. Потом они были "переоткрыты" другими членами команды и на их энтузиазме "въехали" в репозитарий как базовые подходы -- может быть немного в другом изложении, конечно.
Похожее было в ALT с наработками в области автоматической сборки приложений в изолированных средах. Потребовалось несколько лет, чтобы успешно применяемые реализации идей, будучи неиспользуемыми масштабно в рамках проекта, все-таки повлияли на создание следующего поколения автоматических собирателей, а теперь -- и системы совместной разработки. Правда, последнее стало возможным в том числе и благодаря конфликту между разработчиками, в котором появился git и, так уж вышло, создатель которого был в том конфликте не прав.
С другой стороны, я могу твердо назвать одним из своих учителей Юкихиро Мацумото, создателя Ruby. Его тезис о том, что язык программирования должен помогать беречь мысленную энергию программиста и то, что он должен быть естественным, а не простым, произвел со мной крайне серьезное преобразование. Результатом его стало не использование каких-то конкретных средств программирования (того же Ruby, например), но скорее образование какого-то целостного подхода к "станку", почти как у Мацуэ Басё:
Ирис на берегу.
А вот другой — до чего похож! —
Отраженье в воде.
Этот целостный взгляд на проект, индустрию в целом, кстати, позволяет прогнать ту юношескую горячность, которая сопровождает "быстре, выше, сильнее" в IT -- чтобы компьютеры были самые новые, программы -- самые свежие, технологии -- самые прогрессивные. Да, все это надо в определенной степени, но не более того. А иногда технологии и прорывы просто должны постоять и подождать на перекрестке, дождаться своего времени.
Возвращаясь к опроснику Ярослава, хотелось бы отметить еще замечание Дэйва Томаса о том, что же полезно для программиста -- знание формальной математики, физики или чего еще. Дэйв обратил внимание, что выдаюющиеся программисты часто обладают музыкальным слухом. Видимо, цепляются общие области мозга, а музицирование и сочинение в чем-то близки к программированию -- по крайней мере, и музыканты, и программисты большую часть своего внутреннего зрения тратят на напряженное балансирование на невидимых, но от того не менее реальных небесных струнах.
