|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Интервью Стаса Фомина для ADD-2010Материал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Короткая ссылка: Add-stas-interview Чтобы прояснить, какие люди замешаны в организации конференции Application Developer Days 2010, главный организатор конференции, Андрей Майоров взял интервью у председателя Программного Комитета Стаса Фомина. 
Содержание
Как ты считаешь, кто ты по призванию?Ну в профиле моего круга я назвался «изобретателем-рационализатором»[1], в действительности наверное чуть сложнее сложнее. Меня привлекают красивые и одновременно эффективные решения — в алгоритмах, программировании, тестировании и вообще во всей индустрии. Т.е. меня радует, когда задачу с условной рыночной стоимостью «$100» можно решить за «$1» (возможно вообще без или с минимумом программирования). Чем-то похоже на определение инженера, как «человека, решающего за десять центов проблему, которую любой может решить за доллар», только хочется еще больше эффективности, больше лайфхаков, меньше монотонности и ручного труда (ненавижу!), меньше waste и потерь всех видов. Да, на первый взгляд, нам (разработчикам-программистам) повезло — мы не работаем с унылыми станками, с серым железом, в снулых цехах[2], занимаемся вроде как магией, ну по крайней мере алхимией:
И даже кажется, что это далеко от обычного «производственного мира», с их проблемами «потерь на производстве», «свойств материалов», «цепочек поставщиков», «удовлетворения клиентов», т.е. вроде как нечего тут делать «изобретателю и рационализатору», но на самом деле, все эти материальные проблемы есть, и даже в многократном размере. Только вместо кучи разнородных ресурсов («алюминий-чугуний-газ-энергия») тут остался один, но самый важный и основной ресурс — время. И затраты этого ресурса могут быть в сотни раз больше, чем у тех, кто узнал, как это делать правильно. А понять как сделать правильно — непросто, недостаточно опираться на здравый смысл, ведь выигрышные решения обычно анти-интуитивны, опираются на нетривиальные алгоритмы, гиковые маргинальные языки и фреймворки, сложные инструменты. Но эти суперэффективные решения, как правило, есть! Очень часто встречаются заклинание Фредерика Брукса о неубиваемой сложности софтверной разработки — «No silver bullet!», и этим заклинанием менеджеры оправдывают то, что строят своих разработчиков в заводские/военные колонны, и пытаются ими управлять в директивном стиле, бросая на задачу ресурсы, как пехоту на минные поля. Ну «не подвезли же серебряных пуль», так что пойдем в штыковую, завалим И даже сложно их за это судить — если у тебя в команде только пехота, вооруженная отстойными дульнозарядными ружьями, то да, задача менеджера сделать из этого сборища один худо-бедно работающий автомат, и все зависит от плана сражения (расставить приоритеты, атаковать важные точки или слабые места) и мотивации (кнутом и пряником, «жизнь за царя!», «перед релизом — аврал!»). Но если у пехоты есть современное автоматическое оружие, то она победит малым числом (а то и в одиночку), без пинков, мотивации, менеджеров, и сохранив жизнь («время для своих маленьких удовольствий»©). На самом же деле, старинное филосовское размышление Брукса[3] о том, что «нельзя легко запрограммировать ВСЕ возможные задачи», похож на тезис о существовании неразрешимых задач в теории сложности — это не мешает находить решения и увеличивать эффективность для все большего и большего класса задач. И сейчас кучи стандартных задач накрываются готовыми фреймворками/библиотеками и решаются за считанные дни не приходя в сознание. Аналогично и с инструментарием — многие помнят опять таки «закон Брукса», о падении эффективности в команде из n человек, как ». Вроде бы это доказывало принципиальную невозможность больших команд — однако хорошие системы групповой разработки (системы управления версиями, трекеры, вики) сделали возможными проекты из десятков тысяч участников. И разработчики должны знать и разбираться в этих инструментах лично (а не спихивать вопросы выбора на менеджеров) — ибо менеджеры мыслят финансово-экономическими категориями, и могут навязать, например, команде ClearCase, вместо Mercurial, а вбухав в это десяток килобаксов, добиться пересмотра решения будет очень непросто[4]. Именно разработчики должны посматривать в сторону новых, странно выглядящих, может быть неказистых языков, не надеясь писать всю жизнь «на яве с экэмэлем» и что железячники будут подгонять все более и более быстрые тачки — увы, закон Мура уже несколько лет как забуксовал. Ладно, резюмирую: моя миссия — знать эти лучшие решения, чтобы разработчики были не замордованным строем смертников, а веселой ватагой охотников. Многие знают тебя, как самобытного и интересного докладчика. Ты долго шел к своему стилю?Да нет, на мой взгляд все выступления, начиная с самого первого, встречались с большим интересом. Правда я не знаю, что есть «мой стиль» — я могу его определить только одним прилагательным «нескучный». На самом деле, выступающему на конференциях нужно обязательно вкурить Смерть от Powerpoint-а, и осознать, что выступление — это не
Вообще, когда-то да, конференции были максимально быстрым способом распространения знаний — подготовка книги к печати занимало пару лет, статьи — год, проще было подготовить за пару месяцев тезисы (даже без печатающий машинки!) и выступить перед аудиторией с лекционной доской, а дальше надеятся на networking. Но сейчас информации и так полно, полно способов асинхронной коммуникации — можно:
Соответственно, на конференцию, нужно выйти так, чтобы не дублировать эти каналы!
Соответственно, используйте выступление на конференции, для того, что нельзя передать асинхронно и пассивно:
Как именно → это уже поле для творчества → думайте об этом, даже как о любительском театре или даже цирке. Рекомендую просто подумать, что у вас проще и быстрей удается (чтобы не мучится при подготовке выступления, чтобы это было быстро, с минимальными накладными расходами, и приносило радость), «прокачать этот навык» и получится «уникальный стиль».
Порекомендуй читателям пару своих выступлений, которые тебе особенно нравятся«Какие из ваших детей вам особенно нравятся?» — Они мне все нравятся. Разный стиль, разные идеи, но в целом — ничто за прошедшее время не протухло. Порекомендую последние — они сделаны в стиле «квазиинфографического псевдомультфильма» и должны легко смотреться:
Большую часть остальных моих выступлений можно найти тут или тут (учтите, там не только мои!) Где ты сейчас работаешь? Какие основные обязанности на работе?«Сейчас работаешь…» Вопрос вроде как адекватный, но для меня звучит забавно — уже больше 12 лет я работаю в одной и той же компании (CustIS). Звучит несколько странно («столько не живут») — можно подумать, что я нелюбопытен, или вовсе «окуклился», но на самом деле, просто мне хватало всего
Ну и до сих пор, у меня на работе широкий спектр задач, связанный с исследованием перспективных технологий, инструментов и систем, внедрением их и постановкой оптимальных процессов разработки, обучением сотрудников. В общем, все, на для чего в компании нет настоящего, узкого профессионала-специалиста, падает на меня, выступающего в амплуа «знаю ничего обо всем», ну и как ни странно, проблемы более-менее успешно решаются. Параллельно я занимаюсь преподаванием теории сложности и алгоритмов для студентов МФТИ, эта миссия у меня тоже давно, она приносит мне нетривиальные задачи и, возможно, карму. Похвастайся каким-нибудь особенно интересным проектом, который ты делалС этим хуже. «Наша служба и опасна и трудна, и на первый взгляд как-будто не видна, на второй как будто тоже не видна, и на третий тоже…» Ибо большинство заказных проектов если не секретны, то по крайней мере закрыты и неизвестны широкой публике[7]. Широкой публике эти системы становятся заметны, только когда там что-то ломается[8] Хотя мне все эти проекты нравятся — мне вообще нравится идея решения уникальных задач. Правда при добротной реализации системы получаются даже излишне долгоживущими, что столкнувшись с ними через десяток лет, несколько стыдно за технологическую часть (вот вчера, обнаружил что живет и здравствует моя софтина на Visual Basic). А сейчас, когда стал заниматься инструментарием для разработчиков, и вовсе, чтобы не изобретать велосипед очень редко, когда приходится писать что-то свое, в основном доработки-расширения существующих систем. К тому же сейчас на мне много оргрутины, и не часто удается покодировать. Но если хотите попинать мой код, то можно посмотреть веселую (и полезную разработчикам поделку) ShowTeamWork. Плюс мы собираемся публиковать в open-source кучу наших доработок/расширений над такими системами как Bugzilla, MediaWiki, FeedOnFeeds и т. п. — следите за объявлениями в нашем блоге. Хочешь поагитировать читателей за какой-нибудь язык?Гм. Да. Агитировать за современные коммерческие «коболы» — Java и C#, не буду — профессиональному программисту так или иначе придется в одном из них разобраться, также, как вебразработчику придется ознакомится с PHP, безосновательно качеств этого языка. А агитировать я буду за Python, язык продвигающий очень правильные и близкие мне ценности. Тенденции таковы, что ясность, понятность, скорость разработки и гибкость кода — это ценности, все более становящиеся актуальными. Т.е. Python — это универсальный язык, который поможет вам от мелкой автоматизации (за минуту написать что-то, что будет экономить вам по минуте ежедневно, т.е. та область, где жили shell scripts) до крупных проектов (вебсистемы, RIA, просто клиентские приложения). Т.е. вне зависимости, на чем вам придется программировать — для Python все равно найдется место (он займет место bash/…sh/PowerShell/perl), либо можно использовать для исследовательских задач и прототипов, ну и можно сделать его основным языком разработки. Ты пишешь кучу текстов, делаешь видео, выступаешь. Когда ты все это успеваешь?«Как же вы выжили в этой мясорубке? — А мы и не выжили…» Ну с точки зрения количества публикации в интернете — их теперь у меня очень мало, просто в последний год я сконцентрировался на оживлении корпоративного интанета — там да, я пишу много статей во внутренную вики-систему (которая является по совместительству и блог-хостингом и форумом), и иногда, некоторые из них реплицирую на внешнюю вики-систему, т.е. пока моя внешняя продуктивность несравнима с стандартным блоггером-копипейстером. Но вообще, да, я стараюсь активно писать, и думаю, вскорости внешних публикаций прибавится.
Что касается переводов — признаюсь, я, увы, скажем так, неидеально знаю английский язык. Т.е. да, читаю, но при наличие перевода я буду читать на русском, несмотря на возможные огрехи — это быстрее. Поэтому, столкнувшись с интересной статьей на английском, мне интересно ее перевести
Например, изучая тему современного спектра систем управления версий — я перевел несколько статей, представляющих весьма диаметральные точки зрения, расширил свой кругозор, отрефлексировал ситуацию. Плюс, запись своими (хоть и переведенными) словами — лучший способ запомнить. А если забыл — вспоминать тему лучше своим текстом. Может это конечно моя личная возрастная проблема — но со знаниями, увы, сейчас «приходится бежать вдвое быстрее, только чтобы оставаться на одном месте»©, куча всего становится неактуальным, многое забывается. И собственные статьи, или даже заметки в блоге — это отличный способ внешнего хранения/extended mind, гораздо лучше всяких эвернотов. Что касается подготовки к выступлениям — я стараюсь экономить, найти технологию, которая позволит подготовить материалы за несколько часов. Например, слайды я не вымучиваю в PowerPointе, а программно генерирую, используя Python, Graphviz, LaTeX, Inkscape и т.п. Ты уже когда-нибудь был председателем программного комитета конференции? Каковы функции председателя?Нет, никогда не был. Хотя был в программном комитете. На мой взгляд, председатель программного комитета — это главный программист конференции, по крайней мере
ответственный за ее Программу.
Поэтому он должен быть «в теме» — обладать достаточной эрудицией во всей области, и знать, какие есть эксперты и в каких областях.
Так же, чтобы программа вышла Соответственно, он должен решить с программным комитетом, каких экспертов, имеет смысл пригласить заранее — это должны быть
Затем он должен быть достаточно контактным/убедительным/умоляющим, чтобы уговорить этих экспертов поучаствовать. В случае заявок, присылаемых от неизвестных авторов, Председатель должен уметь распознать полный бред (например, сгенерированный программой SciGen, или автором, не приходящим в сознание), жуткую банальщину («детский сад»), ну и более-менее (гугл ему в помощь), мочь быстро понять идею заявки любого доклада — чтобы оценить востребованность, и может, чтобы дать идеи автору, как скорректировать подачу, чтобы добиться лучшего результата. Далее он должен сверстать (или оттестировать «верстку», т.е. «расписание»), чтобы разнести разные темы на разные треки, и минимизировать вероятность моментов, когда либо «не на что пойти», либо «нельзя разорваться — везде интересные мне темы!». Отвественности должен добавить принцип — если программа получается незаполненной — он должен обязан заполнить дыры своими силами! Ну и разумеется, он должен быть commited, чтобы провести конференцию любой ценой — даже за свой счет (либо лично искать спонсоров). Ты был на огромном количестве конференций. Чем ADD отличается от других?Ну пока ADD не началась, нельзя говорить о ней в настоящем времени. Про другие конференция да, говорить можно. Собственно я уже давно публиковал спичи о правильной организации современных IT-конференций — и вот, выдался случай попробовать сделать все правильно с технической точки зрения. Да, мы заказали съемку профессиональным операторам, видеомонтажем «экран+выступающий» и публикацией в HD-качестве займусь я лично. Вообще, там по ссылке «многобукф», повторять я их не буду, поговорю лучше о моментах связанных с географией и контингентом аудитории. На большинство конференций по разработке (ну содержащих в названии слово Software), выступают кто угодно, кроме разработчиков — аналитики, тестировщики, менеджеры, маркетологи, психологи и т.п. Ну да, типичный программист обычно считается интровертом, практически аутистом[10], на фоне коммуникаторов-профессионалов (менеджеров, аналитиков-тестировщиков, маркетологов) полностью тушуются: («Докладчики отличались по поведению в зависимости от специализации: там были бизнесмены, программисты и преподаватели из вузов. Бизнесмены держались уверенно, напористо и складно говорили, преподаватели также были уверены, но без напора, программисты же с видимым усилием боролись с желанием спрятаться под стол»). Плюс проблема специализации — легко собрать конференцию по тестированию или IT—менеджменту — и тестирование, и менеджмент — это не rocket science, там все прекрасно друг друга понимают, более-менее общие проблемы, схожие решения. Тестирование — оно и в африке тестирование. Тестировщик может быстро сменить область — например, с вебразработки на тестирование мобильных приложений. Единственная наверное область, где требуются специальные тестировщики, куда не подходят обычные — это игры, где проще брать прокаченных хардкорных игроков и за пару недель объяснить им, что такое тестирование, чем брать тестировщиков и учить их играть. Аналогично с IT-менеджментом — у меня четкое ощущение, что большая часть менеджеров пришла из тестирования, бизнес- и и системной- аналитики, и «специализированная компетенция в программизме» им больше не нужна, а нужны общие области — психология/мотивация, коммуникация/манипуляция, здравый смысл, умение одеваться, и немного математики. С настоящими же разработчиками сложно — специализации так сильно отличаются, что программист медицинских девайсов на ассемблере совершенно не поймет проблем вебразработчика, замученный малтитредовой отладкой игродел вообще не поймет, почему банковский программист получает на порядок больше денег. Впрочем, есть баянистая, но прекрасная поясняющая картинка:  Собственно, чисто программистких конференций (исключая вендорские) в последнее время я и не припомню.
Нет, бывают конечно микроконференции типа MarginCon, но это очень небольшие и локальные события, по достаточно узким темам. Но я уверен, что есть о чем поговорить разработчикам из разных ветвей:
Ну и просто ознакомится с проблемами «соседей», например, чтобы заинтересоваться и поменять работу, или наоборот, окончательно наступить на горло детской мечте. Еще момент — география. Большая часть конференций проходит в транспортном узле страны — Москве, но, на мой взгляд, условия для иногородних становятся все хуже и хуже — ОЧЕНЬ ДОРОГО: трехдневная конференция за 20 тыр, плюс очень дорогие гостиницы (да и все остальное — от транспорта до кабаков). Такие деньги не то, что лично платить, даже на фирму вешать совесть заест. С точки зрения архитектурных красот, прекрасной экологии, удобного транспорта, дружелюбных горожан — тут ловить нечего. Елки-палки, в случае интернациональной, да что там, даже разногородней тусовки — проще выехать и провести конференцию на каком-нибудь курорте, совместив полезное с очень приятным, и все это будет сильно дешевле. Так, например, путевка на 8 дней в Египет («5 звезд, все включено с перелетом»), где в феврале я участвовал в миниконференции SEG-2010, обошлась в 16 тыр. Выход — проводить однодневные конференции (как, например, AgileDays-2009), тогда иногородним не нужно тратиться на гостиницы. А для москвичей, вообще разумно проводить серию 2-3-4 часовых семинаров после работы (как мы, собственно и делаем). Ну а для настоящей, многодневной конференции «аутсорсинг в регионы» — штука интересная и перспективная. Время и место выбрано удачно, я лично еще ни разу не был в Ярославле, но если когда и стоит в нем побывать — это после торжественного празднования тысячелетия, когда все что можно отремонтировано, вычищено и вылизано. Именно после — когда огромные толпы туристов с официальными лицами уже схлынули, но все еще не развалилось. С точки зрения удобства приезда, то
Все ждет участников и докладчиков, кстати — взгляните на некоторых выступающих — это крутые специалисты и харизматичные докладчики. Ну чем еще отличается ADD? Наверное тем, что эта конференция — новая, нет известности (обычную конференцию начинают рекламировать-бомбить-спамом еще за полгода-год до…), нет толпы богатых спонсоров, и нет ни целей (ни шансов) на ней заработать. Скорее всего понадобятся хорошие вливания средств со стороны компаний организаторов. Но хватит о грустном. Уверен, все получится. Я знаю, у тебя есть аутентичный жилет Онотоле и всякие гаджеты. Расскажи про какой-нибудь особенно интересный«Гаджеты — это когда показываешь их жене, а она говорит — ну и гад же ты». Ладно, расскажу только про пару гаджетов, полезных на конференции. Для участника конференций совершенно обычное состояние — полная нечитаемость слайдов и видео докладчика. Организаторы обычно забивают огромные, длинные залы (аки пенал), а экраны для проекторов обычно остаются копеечного размера. Поэтому хитрые участники стараются заранее занимать первые ряды, жертвуют временем и мобильностью взамен лучшего места (и кстати, иногда даже с первых рядов ничего не видно). Но умный участник возьмет очки-бинокли и будет совершенно независим — можно смотреть выступление с прохода, можно бродить между залами и выбирать интересное выступление, можно рассматривать не докладчика, а красивых девушек в зале (и не только), в общем, почти сплошной PROFIT. А выступающему часто полезно сопровождать выступление звуком — пустить видеоролик, мультфильм, чье-то выступление (может даже свое). Но в ноутбуках динамики традиционно абсолютно никакие, а таскать с собой полноценные колонки (пусть даже маленькие) — это подвиг, на который обычно не идут. Помочь могут микроколонки «SVEN Boogie Ball», при их совершенно копеечном размере они (к моему удивлению) смогли «озвучить» залы на сотню человек. Ладно, надо завершатся, ибо уже получилось «многобукф».
Андрей, спасибо за вопросы!
Читателю — спасибо, что дочитал —
Репликация: База Знаний «Заказных Информ Систем» → «Интервью Стаса Фомина для ADD-2010» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
 |
||||||
 |
 |
