Интервью Стаса Фомина для ADD-2010

Короткая ссылка: Add-stas-interview

Ссылки сюда (1) →

Чтобы прояснить, какие люди замешаны в организации конференции Application Developer Days 2010, главный организатор конференции, Андрей Майоров взял интервью у председателя Программного Комитета Стаса Фомина.

Как ты считаешь, кто ты по призванию?

Ну в профиле моего круга я назвался «изобретателем-рационализатором», в действительности наверное чуть сложнее сложнее. Меня привлекают красивые и одновременно эффективные решения — в алгоритмах, программировании, тестировании и вообще во всей индустрии. Меня радует, когда задачу с условной рыночной стоимостью «$100» можно решить за «$1», возможно даже без или с минимумом программирования. Чем-то похоже на определение инженера, как «человека, решающего за десять центов проблему, которую любой может решить за доллар», только хочется еще больше эффективности, больше лайфхаков, меньше монотонности и ручного труда, меньше waste и потерь всех видов.

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

• все можно породить из своей головы и свитков с своими и чужими заклинаниями;
• все это трудно отнять, ибо основные средства производства — это люди и их связи, и в случае отъема вспомогательных средств (помещения-компьютеры-печатать), люди легко могут собраться в другом месте, что весьма полезно в нашей стране.

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

Только вместо кучи разнородных ресурсов («алюминий-чугуний-газ-энергия») тут остался один, но самый важный и основной ресурс — время. И затраты этого ресурса могут быть в сотни раз больше, чем у тех, кто узнал, как это делать правильно.

А понять как сделать правильно — непросто, недостаточно опираться на здравый смысл, ведь выигрышные решения обычно анти-интуитивны, опираются на нетривиальные алгоритмы, гиковые маргинальные языки и фреймворки, сложные инструменты.

Но эти суперэффективные решения, как правило, есть!

Очень часто встречаются заклинание Фредерика Брукса о неубиваемой сложности софтверной разработки — «No silver bullet!», и этим заклинанием менеджеры оправдывают то, что строят своих разработчиков в заводские/военные колонны, и пытаются ими управлять в директивном стиле, бросая на задачу ресурсы, как пехоту на минные поля. Ну «не подвезли же серебряных пуль», так что пойдем в штыковую, завалим мясомкодом.

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

На самом же деле, старинное филосовское размышление Брукса о том, что «нельзя легко запрограммировать ВСЕ возможные задачи», похож на тезис о существовании неразрешимых задач в теории сложности — это не мешает находить решения и увеличивать эффективность для все большего и большего класса задач. И сейчас кучи стандартных задач накрываются готовыми фреймворками/библиотеками и решаются за считанные дни не приходя в сознание.

Аналогично и с инструментарием — многие помнят опять таки «закон Брукса», о падении эффективности в команде из n человек, как . Вроде бы это доказывало принципиальную невозможность больших команд — однако хорошие системы групповой разработки (системы управления версиями, трекеры, вики) сделали возможными проекты из десятков тысяч участников. И разработчики должны знать и разбираться в этих инструментах лично (а не спихивать вопросы выбора на менеджеров) — ибо менеджеры мыслят финансово-экономическими категориями, и могут навязать, например, команде ClearCase, вместо Mercurial, а вбухав в это десяток килобаксов, добиться пересмотра решения будет очень непросто. Именно разработчики должны посматривать в сторону новых, странно выглядящих, может быть неказистых языков, не надеясь писать всю жизнь «на яве с экcэмэлем» и что железячники будут подгонять все более и более быстрые тачки — увы, закон Мура уже несколько лет как забуксовал.

Ладно, резюмирую: моя миссия — знать эти лучшие решения, чтобы разработчики были не замордованным строем смертников, а веселой ватагой охотников.

Многие знают тебя, как самобытного и интересного докладчика. Ты долго шел к своему стилю?

Да нет, на мой взгляд все выступления, начиная с самого первого, встречались с большим интересом. Правда я не знаю, что есть «мой стиль» — я могу его определить только одним прилагательным «нескучный». На самом деле, выступающему на конференциях нужно обязательно вкурить Смерть от Powerpoint-а, и осознать, что выступление — это не

• зачитывание краткого краткого конспекта, в виде списка с буллетами.
• показ отчета/учебника/статьи в «натуральную величину» — болезнь «слайдоментов».

Вообще, когда-то да, конференции были максимально быстрым способом распространения знаний — подготовка книги к печати занимало пару лет, статьи — год, проще было подготовить за пару месяцев тезисы (даже без печатающий машинки!) и выступить перед аудиторией с лекционной доской, а дальше надеятся на networking.

Но сейчас информации и так полно, полно способов асинхронной коммуникации — можно:

• написать статью (ну или хотя бы пост в блог);
• надиктовать аудиоподкаст;
• и даже — записать видеолекцию.

Соответственно, на конференцию, нужно выйти так, чтобы не дублировать эти каналы!

• Не манкируйте видеочастью выступления. Некоторые утверждают — «слайды отвлекают людей от меня», «главное — моя лекция» и, на худой конец —"я покажу все мимикой и жестикуляцией". ИМХО, это просто неуважение к зрителю — подумайте, если ваше выступление зрителям легче прослушать в виде подкаста, используя свое транспортное время — это значит, вы совершенно не вытянули видеочасть, и ваше выступление неэффективно. Разумеется, возможны исключения — если вы харизматичный докладчик (редкость), мастер НЛП (еще большая редкость), или просто очень красивая девушка (совсем редкость).

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

Соответственно, используйте выступление на конференции, для того, что нельзя передать асинхронно и пассивно:

• можете использовать свою страсть/любовь, невербалику и прочую магию, все то, что без личного присутствия не работает;
• собирайте немедленный фидбек, причем в личном, face-to-face общении (а не через русские анонимные наезды, бессмысленные и беспощадные).

Как именно → это уже поле для творчества → думайте об этом, даже как о любительском театре или даже цирке. Рекомендую просто подумать, что у вас проще и быстрей удается (чтобы не мучится при подготовке выступления, чтобы это было быстро, с минимальными накладными расходами, и приносило радость), «прокачать этот навык» и получится «уникальный стиль».

• Умеете быстро кодить? — Покажите живой лайвкодинг.
• Фотолюбитель? — Снимайте фотосессию (слайды нарисуйте на стенах и досках, людей снимите живьем, и т. п.).
• Увлекатесь видеомонтажом? — Сделайте видео.
• Вы рассказываете о софтине с интерфейсом? — Покажите его живьем!
• Пытаетесь рисовать комиксы или мультфильмы? — Супер!
• Умеете жонглировать! — АААА1111!!!

Порекомендуй читателям пару своих выступлений, которые тебе особенно нравятся

«Какие из ваших детей вам особенно нравятся?» — Они мне все нравятся. Разный стиль, разные идеи, но в целом — ничто за прошедшее время не протухло. Порекомендую последние — они сделаны в стиле «квазиинфографического псевдомультфильма» и должны легко смотреться:

• Knowledge Management: От Склада к Потоку (Software People-2010)
• Свободные системы, спасающие разработчиков (РИТ-2010)

Большую часть остальных моих выступлений можно найти тут или тут (учтите, там не только мои!)

Где ты сейчас работаешь? Какие основные обязанности на работе?

«Сейчас работаешь…» Вопрос вроде как адекватный, но для меня звучит забавно — уже больше 12 лет я работаю в одной и той же компании (CustIS). Звучит несколько странно («столько не живут») — можно подумать, что я нелюбопытен, или вовсе «окуклился», но на самом деле, просто мне хватало всего

Ролей

я побыл и рядовым разработчиком, ПМом, архитектором, HR-ом, методологом процессов (все не перечислить),

Задач и технологий

в отличие от продуктовой разработки было куча совершенно разных задач, решавшихся на различных технологических стеках → С/C++, RAD (PowerBuilder, VisualBasic), JavaScript (we invent wheel AJAX in 1998), серверная логика на PL/SQL, Java-стек, .NET-стек, добработка и развитие вебсистем на LAMP (Perl-PHP-Python)…

Ну и до сих пор, у меня на работе широкий спектр задач, связанный с исследованием перспективных технологий, инструментов и систем, внедрением их и постановкой оптимальных процессов разработки, обучением сотрудников. В общем, все, на для чего в компании нет настоящего, узкого профессионала-специалиста, падает на меня, выступающего в амплуа «знаю ничего обо всем», ну и как ни странно, проблемы более-менее успешно решаются.

Параллельно я занимаюсь преподаванием теории сложности и алгоритмов для студентов МФТИ, эта миссия у меня тоже давно, она приносит мне нетривиальные задачи и, возможно, карму.

Похвастайся каким-нибудь особенно интересным проектом, который ты делал

С этим хуже. «Наша служба и опасна и трудна, и на первый взгляд как-будто не видна, на второй как будто тоже не видна, и на третий тоже…» Ибо большинство заказных проектов если не секретны, то по крайней мере закрыты и неизвестны широкой публике. Широкой публике эти системы становятся заметны, только когда там что-то ломается

Хотя мне все эти проекты нравятся — мне вообще нравится идея решения уникальных задач. Правда при добротной реализации системы получаются даже излишне долгоживущими, что столкнувшись с ними через десяток лет, несколько стыдно за технологическую часть (вот вчера, обнаружил что живет и здравствует моя софтина на Visual Basic).

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

Но если хотите попинать мой код, то можно посмотреть веселую и полезную для разработчиков поделку — ShowTeamWork. Плюс мы собираемся публиковать в open-source кучу наших доработок/расширений над такими системами как Bugzilla, MediaWiki, FeedOnFeeds, SVNSearcher и т. п. — следите за объявлениями в нашем блоге.

А если честно — самые интересные и удачные мои проект — это мои дети. Наверное, то что я делаю руками, не самое лучшее, на что я способен.

Хочешь поагитировать читателей за какой-нибудь язык?

Гм. Да. Агитировать за современные коммерческие «коболы» — Java и C#, не буду — профессиональному программисту так или иначе придется в одном из них разобраться, также, как вебразработчику придется ознакомится с PHP, безосновательно качеств этого языка.

А агитировать я буду за Python, язык продвигающий очень правильные и близкие мне ценности.

Тенденции таковы, что ясность, понятность, скорость разработки и гибкость кода — это ценности, все более становящиеся актуальными. То есть Python — это универсальный язык, который поможет вам от мелкой автоматизации (за минуту написать что-то, что будет экономить вам по минуте ежедневно, то есть та область, где жили shell scripts) до крупных проектов (вебсистемы, RIA, просто клиентские приложения).

То есть вне зависимости, на чем вам придется программировать — для Python все равно найдется место (он займет место bash/…sh/PowerShell/perl), либо можно использовать для исследовательских задач и прототипов, ну и можно сделать его основным языком разработки.

Ну и еще присмотреться к Javascript. Он явно перерос свое изначальное предназначение и имеет хорошую перспективу.

Ты пишешь кучу текстов, делаешь видео, выступаешь. Когда ты все это успеваешь?

«Как же вы выжили в этом кошмаре? — А мы и не выжили…»

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

Кстати, открою секрет: самое важное — научится слепой печати. Вы сразу перестанете быть «немым» — ведь вы сможете записывать свои мысли практически со скоростью оных.

Что касается переводов — признаюсь, я, увы, скажем так, неидеально знаю английский язык. То есть да, читаю, но при наличие перевода я буду читать на русском, несмотря на возможные огрехи — это быстрее.

Поэтому, столкнувшись с интересной статьей на английском, мне интересно ее перевести

• «Перевод для других» заставляет более глубоко и внимательно анализировать суть написанного, тормозит поверхностность, включает рефлексию.
• Накладных расходов именно на запись-верстку-публикацию — немного. Я уже говорил про слепую печать, всем остальное доверю вики-системе.

Например, изучая тему современного спектра систем управления версий — я перевел несколько статей, представляющих весьма диаметральные точки зрения, расширил свой кругозор, отрефлексировал ситуацию.

Плюс, запись своими (хоть и переведенными) словами — лучший способ запомнить. А если забыл — вспоминать тему лучше своим текстом. Может это конечно моя личная возрастная проблема — но со знаниями, увы, сейчас «приходится бежать вдвое быстрее, только чтобы оставаться на одном месте»©, куча всего становится неактуальным, многое забывается. И собственные статьи, или даже заметки в блоге — это отличный способ внешнего хранения/extended mind, гораздо лучше всяких эвернотов.

Что касается подготовки к выступлениям — я стараюсь экономить, найти технологию, которая позволит подготовить материалы за несколько часов. Например, слайды я не вымучиваю в PowerPointе, а программно генерирую, используя Python, Graphviz, LaTeX, Inkscape и т. п.

Ты уже когда-нибудь был председателем программного комитета конференции? Каковы функции председателя?

Нет, председателем не был, хотя в программном комитете был.

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

Соответственно, он должен решить с программным комитетом, каких экспертов, имеет смысл пригласить заранее — это должны быть

• настоящие эксперты,
• зажигательно выступающие,
• еще не надоевшие.

Затем он должен быть достаточно контактным/убедительным/умоляющим, чтобы уговорить этих экспертов поучаствовать.

В случае заявок, присылаемых от неизвестных авторов, Председатель должен уметь распознать полный бред (например, сгенерированный программой SciGen, или автором, не приходящим в сознание), жуткую банальщину («детский сад»), ну и более-менее (гугл ему в помощь), мочь быстро понять идею заявки любого доклада — чтобы оценить востребованность, и может, чтобы дать идеи автору, как скорректировать подачу, чтобы добиться лучшего результата.

Далее он должен сверстать (или оттестировать «верстку», то есть «расписание»), чтобы разнести разные темы на разные треки, и минимизировать вероятность моментов, когда либо «не на что пойти», либо «нельзя разорваться — везде интересные мне темы!».

Отвественности должен добавить принцип — если программа получается незаполненной — он должен обязан заполнить дыры своими силами! Ну и разумеется, он должен быть commited, чтобы провести конференцию любой ценой — даже за свой счет (либо лично искать спонсоров).

Ты был на огромном количестве конференций. Чем ADD отличается от других?

Ну пока ADD не началась, нельзя говорить о ней в настоящем времени.

Про другие конференция да, говорить можно. Собственно я уже давно публиковал спичи о правильной организации современных IT-конференций — и вот, выдался случай попробовать сделать все правильно с технической точки зрения. Да, мы заказали съемку профессиональным операторам, видеомонтажем «экран+выступающий» и публикацией в HD-качестве займусь я лично. Вообще, там по ссылке «многобукф», повторять я их не буду, поговорю лучше о моментах связанных с географией и контингентом аудитории.

На большинство конференций по разработке (ну содержащих в названии слово Software), выступают кто угодно, кроме разработчиков — аналитики, тестировщики, менеджеры, маркетологи, психологи и т. п.

Ну да, типичный программист обычно считается интровертом, практически аутистом, на фоне коммуникаторов-профессионалов (менеджеров, аналитиков-тестировщиков, маркетологов) полностью тушуются: («Докладчики отличались по поведению в зависимости от специализации: там были бизнесмены, программисты и преподаватели из вузов. Бизнесмены держались уверенно, напористо и складно говорили, преподаватели также были уверены, но без напора, программисты же с видимым усилием боролись с желанием спрятаться под стол»).

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

Тестирование — оно и в африке тестирование. Тестировщик может быстро сменить область — например, с вебразработки на тестирование мобильных приложений. И тестировщики легко образуют сообщества, с большим интересом посещают свои конференции, вне зависимости от географии — есть серия успешных конференций SQADays, проводимых в разных городах и странах СНГ.

Аналогично с IT-менеджментом — очень большая часть менеджеров пришла из тестирования, бизнес- и и системной- аналитики, и «специализированная компетенция в программизме» им больше не нужна, а нужны общие области — психология/мотивация, коммуникация/манипуляция, здравый смысл, умение одеваться, и немного математики.

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

Собственно, чисто программистких конференций (исключая вендорские) в последнее время я и не припомню.

• DevConf и серия РИТ (хайлоад, клиентсайд и т. п.) — это вебразработка с менеджментом,
• КРИ — это игроделы с менеджментом;
• SECR — менеджмент, тестирование, немного архитектуры.
• AgileDays — менеджмент, тестирование, разработка, но все под соусом Agile.
• Whalerider, SoftwarePeople — чисто менеджмент;

Нет, бывают конечно микроконференции типа MarginCon, но это очень небольшие и локальные события, по достаточно узким темам.

Но я уверен, что есть о чем поговорить разработчикам из разных ветвей:

• Инструменты: системы контроля версий, трекеры, вики, системы сборки, тестирования и непрерывной интеграции.
• Ключевые технологические фреймворки — системы хранения, SQL и NOSQL СУБД.
• Архитектурные практики
• Алгоритмы
• Прорывные технологии, новые языки и парадигмы (функциональное программирование дающее массовый параллелизм и надежность, NoSQL-хранилища, операционные системы оригинальных концепций);
• Open-source — хорошо или плохо? (и кому хорошо или плохо). Чем отличаются лицензиии, как кошерно опубликовать свои наработки?

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

---

Еще момент — география. Большая часть конференций проходит в транспортном узле страны — Москве, но, на мой взгляд, условия для иногородних становятся все хуже и хуже — ОЧЕНЬ ДОРОГО: трехдневная конференция за 20 тыр, плюс очень дорогие гостиницы (да и все остальное — от транспорта до кабаков). Такие деньги не то, что лично платить, даже на фирму вешать совесть заест.

С точки зрения архитектурных красот, прекрасной экологии, удобного транспорта, дружелюбных горожан — тут ловить нечего ну не шибко. Елки-палки, в случае интернациональной, да что там, даже разногородней тусовки, проще выехать и провести конференцию на каком-нибудь курорте, совместив полезное с очень приятным, и все это будет сильно дешевле! Так, например, путевка на 8 дней в Египет («5 звезд, все включено с перелетом»), где в феврале я участвовал в миниконференции SEG-2010, обошлась в 16 тыр.

Выход — проводить однодневные конференции (как, например, AgileDays-2009), тогда иногородним не нужно тратиться на гостиницы. А для москвичей, вообще разумно проводить серию 2-3-4 часовых семинаров после работы (как мы, собственно и делаем в нашей компании).

Ну а для настоящей, многодневной конференции «аутсорсинг в регионы» — штука интересная и перспективная.

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

С точки зрения удобства приезда, то

• Из Санкт-Петербурга есть удобный ночной поезд,
• Из Москвы полно поездов, правда приходящих ночью, что не очень удобно. Москвичам наверное проще доехать за за пару часов на машине.
• Прямые поезда есть с некоторых других северных городов (например, из Архангельска), в остальных случая — пересадка через Москву.

• На месте есть приличная гостиница с WiFi.

Все ждет участников и докладчиков, кстати — взгляните на некоторых выступающих — это крутые специалисты и харизматичные докладчики.

---

Ну чем еще отличается ADD? Наверное тем, что эта конференция — новая, нет известности (обычную конференцию начинают рекламировать-бомбить-спамом еще за полгода-год до…), нет толпы богатых спонсоров, и нет ни целей (ни шансов) на ней заработать. Скорее всего понадобятся хорошие вливания средств со стороны компаний организаторов. Но хватит о грустном. Уверен, все получится.

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

«Гаджеты — это когда показываешь их жене, а она говорит — ну и гад же ты». Ладно, расскажу только про пару гаджетов, полезных на конференции.

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

А выступающему часто полезно сопровождать выступление звуком — пустить видеоролик, мультфильм, чье-то выступление (может даже свое). Но в ноутбуках динамики традиционно абсолютно никакие, а таскать с собой полноценные колонки (пусть даже маленькие) — это подвиг, на который обычно не идут. Помочь могут микроколонки «SVEN Boogie Ball», при их совершенно копеечном размере они (к моему удивлению) смогли «озвучить» залы на сотню человек.

---

Ладно, надо завершатся, ибо уже получилось «многобукф». Андрей, спасибо за вопросы! Читателю — спасибо, что дочитал — иди в ад приходи на конференцию ADD-2010! А кстати, если у тебя есть интересная тема, о которой ты хочешь рассказать — присылай!

---

---

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