Hackenjoy - как это было

В прошлой публикации я поделился анонсом мероприятия, который мы проводили  уже дважды. В этом будет отчет. 

Первым был offline ивент, когда я еще в GoIT развивал джаву в далеком 2015-08.

Вот коллажик из фоток

А вот более подробно о формате и заявленных игрушках ребят

В результате ребята получили бесценный опыт работы в парах (pair programming) а Codenjoy увидел около 15 новых игрушек. Не все их них были дописаны в тот день, но средняя готовность многих была около 90%. Реябтам судя по их отзывам очень понравилось. И я этому рад. 

В этом году, буквально две недели назад мы стартовали online hackenjoy на площадке Juja. Формат изначально заточенный под offline экспериментально попробовали провести в online. И получилось! Конечно выхлоп не такой, как в случае, когда мы заперли участников физически в одном помещении на двое суток и не выпускали без реализованной игрушки, но все же очень здорово. И да мне самому удалось написать игрушку, которая вскоре появится на demo сервере. 

Вот как это происходило в моем пространстве-время в трех частях.

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

Первая игра называется Quadro (GitHub).


Остальные в процессе...

Мастеркласс по Test Driven Development

Вчера проходил мастеркласс по Test Driven Development во Львове. Планировался как мастеркласс, но в результате получилась дискуссия, что так же очень замечательно. Я кайфонул! Пока видео готовится, предложу твоему вниманию подборку ссылок на предыдущие посты в блоге, которыми поделюсь с участниками мастеркласса. Все на тему TDD и PP. 

А вот книги, которые помогут стать на рельсы эффективной разработки. Там и про ООП, и про юнит тестирование и про легаси код, и про Рефакторинг и про code quality и про шаблоны проектирования и про ТДД... Сборная солянка.

Вот видео ~10 часов разработки модельки игры змейки по TDD. Видео старенькое, кой-че я бы делал уже иначе, но в целом все остается как там. 

В чем разница - тесты до или тесты после? Собственно, в чем разница TDD или покрытие кода тестами. 

Как играть в TDD пинг-понг? Мы с напарником Сергеем на конференции java.io показываем как это, решать простенькую задачку в TDD Ping Pong 

Как вообще работать в паре (парное программирование)? Собрал сюда все мысли по этому поводу. Сидеть за одним компом вместе - это не парное программирование. Парное - это когда есть роли, правила и дисциплина. 

Что делать если тест изначально зеленый? Ага.. Лжет ли? И что вообще с тестами и их цветами. 

Ну и подробное описание нашего двухдневного тренинга по TDD. Тренинг-ликбез. Так, стать на рельсы. Магии не произойдет - ломать голову и привычки потом придется в любом случае. Но на тренинге получишь массу ответов на накопленные вопросы. 

Наскальные рисунки

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

Так что продолжение следует...

Парное программирование - мысли вслух...

Основные наблюдения: 

- парное программирование - это весело, с улыбками

- парное программирование - это шумно

- парное программирование - это концентрация на задаче

Если чего-то из этого не получается - повод задуматься. Что-то пошло не так.

В паре есть две роли. Тот кто у руля и тот, кто с test list (дальше, тестлистом). У каждой роли свои четкие обязанности. 

Тот кто с тесилистом - молчать должен, и стараться не критиковать вообще того кто у руля. Говорит тот, у кого клавиатура. Говорит о том, как он решет текущую задачу. Тот кто с тестилистом внимательно следит и смотрит за несоответсвием того кто у руля в том что он говорит и пишет. Говорю <= пишу >=, говорю -1 пишу 1. И так далее. Ловить баги.

Что делать с критикой? Выписать ее в тестлист, и когда произойдет обмен клавиатурой, предложить устранить запах, который вызвал протест. 

Если так делать случается магия. Сеньйор, который сидит у тестлиста вдруг начинает учиться у джуника, который у руля. Как это возможно? Джуник просто накануне прочитал умную стать. Но если сеньйор будет постоянно его поучать "сделай так" "сделай эдак", то и сам нового не узнает и джуника ничему не научит. Дело в том, что тебя, о Сеньйор, никто не слушает, пока в голове есть своя идея как это можно было бы реализовать. Даже если ты знаешь, почему она не сработает - тебя не услышат, пока не получат граблями по бошке.  

А вот за чем ты должн следить с тестлистом на руках, так это за временем. Не больше 10 минут на каждую итерацию. Дай время напарнику облажаться, а потом забери клавиатуру если у него не получилось, сделай так как считаешь нужно. У тебя-то получится. Хотя практика показывает, что не всегда. 

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

Как джуник может помочь сеньйору? А сеньйор делает те же самые очепятки что и джуник, приблизительно с той же скоростью. За ними следи. Так же у сеньйора не получается что-то, что он думает, что получится. Магия в том, что в этот момент пока сеньор напряженно думает у руля, у джуника может появится идея и стоит только подождать немного пока сеньйор не сдастся (лимитировав его конечно по времени) а потом взять клавиатуру (снова поменяться ролями) и попробовать свое. Вышло? Поздравляю! Не вышло. Думайте дальше... 

Если долго у обоих ничего не получается - самое время сделать перерыв. Парное программирование очень истощающий ресурсы способ делать что-то вместе. Половину времени ты говоришь о том, что делаешь (а это непривычно). Половину времени ты слушаешь и смотришь за тем, что делает коллега, задаешь ему вопросы, потому как он не спешит делиться с тобой тем что делает. Вы спорите. Это требует энергии. Отдыхайте.

Что касается спора. Все вопросы, которые возникают у вас обоих во время делания текущей задачи должны выписываться в тестлист тем, кто его сейчас держит в руках. Никаких клевых идей! Сейчас надо закончить то, что начали 2 минуты назад - потом уже все рефакторинги, пересомтры архитектуры и так далее... Все через тест лист. Спорить так же не сильно стоит. В момент когда текущая задача решена, просто выберите из списка то, что можно сделать быстро в течении следующих 5 минут. Если такой задачи сейчас нет - разбробите ту что есть на помельче. Выхлоп (коммит) и смена ролей должна происходить каждый 5-10-15 минут. 

Если вы не будете меняться регулярно, то вскоре тому кто с тестилистом будет скучно. Он начнет зевать. Тот кто у руля может это заметить и передать клавиатуру добровольно напарнику, иначе он его потеряет. Зевок - первый сигнал, что у вас уже не парное программирование, а просто один кодит, а второй слушает свое внутреннее радио. Следующий этап, когда тестлист откладывается на стол, а его держатель откижывается на спинку кресла. Ввсе, он выпал из процесса. Вернуть его можно дав ему клавиатуру. Если он не согласен с текущим путем решения задачи - отривертить пару минут последних изменений и дать клавиатуру и сказать - делай как ты считаешь нужным. Это как впрыск адреналина, сразу же его включит... 

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

Еще на каждом коммите полезно предлагать другу "дать пять". Это эмоциональный якорек успеха. И других ребят подбадривает...

Что еще? 

Вот что. Забудь что есть сеньйор или джун. В паре вскоре оказывается, что каждый сеньорный в чем-то своем, тогда как напарник при это джуник. Не пытайся "научить джуника" жить (кодить) правильно. Предлагай изменения через тестлист, и берись за них в тот момент, когда он готов будет услышать. Сам же не зацикливайся на том, что знаешь - послушай своего коллегу. Чаще спрашивай: а как ты это сделал? а почему? И увидишь, что он тоже знает оченьо многое.  

Зачем парное программирование? 

Для меня причине несколько. Более эффективное делание чего-то. Я не тужусь над проблемой сам, меня напарник подменяет. У пары сил обычно больше, чем у двоих ребят по отдельности, иначе не было понятия синергия.  В паре не страшно делать что-то потому как с ответственность делится с другом. Кроме того где ему страшно, не страшно напарнику и наоборот. В паре весело - это то, что запомнится на долго. В паре одет обмен опытом более эффективно, чем на митингах - просто потому, что он идет постоянно и неосознанно. Мы просто перенимаем хорошие привычки друг друга. 

Пара вытаскивает проблемы отношений в команде, потому как пару часов к ряду сидеть с коллегой плечо к плечу - будь готов, что будет притирка, неприятная обоим. Но после нее вы станете крепкими друзьями. Этому помогут совместные перекуры/чаепития и разговоры на отвлеченные темы. Этому поможет общий успех. Например на дейли теперь вы не будете рипортить тимлиду виновато глядя в пол, вы будете отстаивать друг друга. Это здорово! 

Что еще? 

Вдвоем, после преодоления внутренних барьеров включается режим игры. Вы не воюете с кодом, как бы делали по отдельности, вы играетесь в него. Кроме того в паре существуют игры, например TDD-пинг понг. Игру можете придумать и сами. Хорошо если к самому процессу парного программирования будете относиться как к игре. 

Скорость с которой вы педалите просто зашкаливает. И у сработанной пары на много превышает затраты на то, что двое решают одну задачу - для менеджера на одну задачу двое больше времени уходит (вдвое дороже), а пара поймет вскоре, что при этом они становятся в X раз эффективнее. И x >> 2. Но не сразу - помни про внутренний барьер, желание переучить напарника - эффективность произойдет тогда, когда ты это преодолеешь.

На чем экономится время? Баналльно на всяких мессенджерах, соцсетях. Вероятность того, что твой напарник будет заинтересован посмотреть твою стенку на Facebook в то же время что и тебе и так же как тебе обычно стремится к 0. Ему интересно что-то другое, чем бы он занялся, если бы рядом не было тебя. Может он так отвлекается, отдыхает. Но когда вы в паре, вам надо найти другое развлечение, совместное, например чаепитие... 

Итак если сотрудник лоботряс (опять же по мнению менеджера), и половину рабочего времени тусит в соцсетях, то лечится это парным программированием. Два лоботряса сажаешь друг с дружкой в пару, вот они уже работают не 4 + 4 часа по отдельности, а 8+8 но вместе. Немного утрирую, но как-то так оно и происходит. 

Напарник с тестлистом не дает тебе отвлечься на клевую идею как-то все порефакторить (или прикрутить либу), которая у тебя вдруг возникла. Если кодишь сам - все бросаешь и берешься за клевую идею. Она ведь у меня в голове появилась. Значит она клевая. Но прикол в том, что если ее отложить на час в тестлист, а потом вернуться к ней спустя некоторое время, то окажется что никакая она не клевая, а вообще фукака... Напарник помагает тебе не сорваться на ее выполнение со словами "я выпишу это в тестлист" он предлагает продолжить начатое, ведь у нас есть 10 минут до коммита... С этим экономится масса времени.

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

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

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

Есть конечно же ограничения. Не работать больше 6-8 часов, 5 дней в неделю. Потому как иначе будет на износ. 

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

Как быть если ты энтузиаст и хочешь, чтобы у вас в команде было парное программирование? Не принуждай, скорее всего ты получишь отпор команды. И это естественно. Покупают обычно не то, что предлагают в переходе, а то что сам решил купить (или думаешь, что решил). Так вот сядь и выжидай, когда же к тебе обратится за помощью коллега. Обратился? Что-то спрашивает? Не говори НЕТ я занят, не предлагай ему устного решения, предложи так - "у меня есть сейчас пол часа времени, давай сядем вместе и разберемся что у тебя там". Это вскоре приведет к тому, что парного программирования станет чаще и происходить оно будет не только с тобой. Начни с себя! 

И помни, парное программирование как наркотик. Если вдруг привык а потом приходится работать не в паре, кажется что удалили пол мозга. Но и тут есть решения. Например эффект мишки тедди, когда напарником можешь поставить себе плюшевого медвежонка и ему все рассказывать вслух. TDD, когда за твоими ошибками следят тесты. Тестлист можно вести самому и ко всем идеям, что возникают относиться скептически. Частые коммиты и много других прикольных практик можно  выполнять самому. Было бы желание.

 

Учиться напоказ или как мы хакатонили знания по андроиду

Люблю открывать новое для людей

Я

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

Как научить ребят Андроиду при этом самому в нем не разбираясь? Тренер он жеж должен знать предмет. А я не особо. Ответ пришел - учить не надо, надо учиться. Сесть рядом с ребятами и показать, как я учусь в подобных ситуациях. Ну а вот в этом я опытный наверняка. Сразу же вспомнились хакатоны, на которых я побывал - где не знаешь то, как будешь решать проблему, но делаешь это потому что тут все пришли и все что-то делают (чего пока не умеют), а картинка "как должно быть" - ясна. Вперед! 

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

Итак вводные. 4 дня на все про все. 6 человек с хорошим опытом решения дивелоперских проблем в прошлом. Один эксперт по Андроиду. Один я - эксперт по самообучению, парному программированию, фану в процессе. Программа че делать на 2х листиках А4 - спасибо экспертам. Закрылись в комнате, перезнакомились, разбились на пары и стали писать простые приложеньица типа записной книжки. 

Моя вводная часть была миксом всего, чего я знаю, что поможет сделать это возможным. Знаний много надо впихунить в голову за ограниченное время. Что этому может помешать? Если задаться этому вопросу, то можно написать целый гайд.

Если ты хочешь для своей команды неэффективного обучения, то сделай следующее:

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

- найми какого-то бла-бла-бла-тренера, который хоть и шарит, но будет целый день об этом рассказывать у проектора со слайдами. 

- не давай ребятам попробовать практически все то, что они проспят услышат на семинаре - пусть записывают ("я им зачем блокнотики раздал?") а потом пусть делают мне проект.

- максимально рассади их так, чтобы они не списывали и не общались друг с другом. 

- скажи, что после тренинга с них спросишь результат - деньги потраченные на тренера надо отработать! ROI, блин!

- игнорируй их предыдущий опыт и постоянно повторяй, что теперь все будет по другому!

- строго придерживайся первоначального плана и штрафуй за его несоблюдение

- попроси тренера продемонстрировать пофигизм к результатам учащихся.

- критика наше все! поощряй ее.

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

Блин, аж поплохело, как описал это... Брррр... Но есть жеж такие компании, в которых все именно так и происходит... Бррр... Бррр еще раз. И еще раз... Брррр..

Что сделали мы:

- познакомились и спросили друг у друга, почему Ребята тут, как их жизнь подтолкнула к андроиду. "Нет плохих или хороших ответов - хорошо так, как это есть у вас". Помню повторял это часто. 

- поинтересовались предыдущим опытом ребят, где они уже успешны? в чем их фишка? 

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

 

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

- мы разбились на пары, после небольшой вводной про роли в парном программировании и основные "бока" в нем. 

- мы пилили вначале сами, пробовали сделать то что задумали, но если не получалось - мы спрашивали "помощь друга" у эксперта.

- мы дробили максимально подробно задачи, чтобы каждых 10-15 минут был коммит. 

- мы "давали пять" друг другу, когда случался успех. 

- мы шутили и улыбались. 

- мы делали перерывы.

- мы в конце дня задемили результаты друг другу - каждыая пара пилила в своем направлении и получил какие-то особенные результаты.

- мы решили, что второй день будет проходить иначе - мы провели небольшое ретро

Мы не успели сделать всё, что было запланировано. Не все. Но мы разобрались с тем, как быть дальше.

Зачем я этот пост написал? А так - это то, что мне понравилось в сегодняшнем дне, и я хочу этим поделиться.

Вовсе не обязательно быть экспертом в какой-то области. Достаточно быть экспертом в процессе самообучения и учиться напоказ.  Учиться напоказ. Мне нравится!

Я сегодня узнал немного больше про Андроид. Где-то в следующем посту я расскажу об этом подробнее.

Спасибо Ребятам и Денису за его экспертную поддержку.

Заметочки на сегодня

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

Мужик хорошую статью написал, как перебрался в деревню, провел туда нормальный интернет, коммуникации. Реально есть какая-то магия в отдалении от центра суеты. 10 км от центра и все, тишина, спокойствие и продуктивность. Пока это делают единицы, дальше - больше. И вообще пусть офисы будущего должны быть не в центрах города. Айишные городки на 2-5k человек, в 20-50 км от центра города. Со своей инфраструктурой. Чтобы там могли жить семьи разработчиков, детсады, поликлиники. 

Что хочешь получить вначале отдай.  Какое глубокое словосочетание...

Магия начинается, когда начинаешь применять знания. Знать != делать. 

А еще говорили о детях. Еще раз перечитал заметки Ошо. Тунц, пынц. Насколько необычный человек этот старикашка. Недавно нашел описание критериев зрелой личности по Маслоу. Match! 

Проект для Хакерспейса. Дивайс, который бьет меня током, если слышит негатив из моих уст.

"у меня не получится"
хдыщь!
"понял, получится!!"
...
"нет на это денег"
хдыщь! 

"ок, поищем..."

Можно ли научить его слушать только мой голос и распознавать слова? Последнее уже реализовано в смартфонах, точно. А первое - можно проигнорить. Пусть распознает голос всех собеседников. Зато у меня будет причина, по которой я хочу остановить общение с собеседником - "слушай, ты тут ноешь, а меня током бьет, давай не будешь это делать, а?"

Зуб ночью разболелся. Принять обезболивающее? Попробовал без него. Закрыть глаза и помедитировать. Боль усиливалась. Но понял одну штуку - когда напрягаешься, становится только больнее. Я и расслабился. Болит сильнее, а я расслабляюсь еще больше. Потом стал думать мысль - боль это информация. Боль это информация. Короче как-то нашелся регулятор громкости боли и она меня перестала парить. Не могу сказать что не болело, но этот факт перестал волновать. Конечно же причину фиксить стоит, а не игнорить, но этим займется мой стоматолог завтра днем. А тем временем интересный эксперимент получился - по поиску регулятора громкости зубной боли. Боль - это информация.

Есть проблема - как найти напарника?

Вот эта картинка очень кстати будет сейчас

Много друзей. Очень много контактов на фейсбуке/скайпе и других соцсетях. Очень хорошие и талантливые все ребята. Конечно же все заняты. Конечно же все перегружены информацией - айтишники жеж. И вот у тебя появляется идея - ты ее осторожно вынашиваешь, потом крайне осторожно озвучиваешь вслух в соцсетях. И тут трахбах! Бабах тудух! "Это все уже было" "Зачем изобретать колесо" "Это неудобно" Или более нейтральное "Ну не знаю..." "А ты пробовал заюзать qwe" "А какую проблему ты решаешь?" Омг. Я нахожусь сейчас на этапе, где необходима помощь и поддержка, а не отговоры. Самое лучшее, что может быть - это помощь в виде некоторых рекомендаций что можно было бы улучшить и как, если не услышал идею или попытаться понять идею, увидеть ее такой какой ее вижу я. Но это дано не всем для этого есть лучший друг. Ему спасибо!

Наверняка в такой ситуации бывал не только я сам. Идеи у каждого в голове рождаются. Кто более смелее, тот рвется в бой игнорируя мнение окружающих. Получилось? Нет, идем дальше. Получилось? Ок, возмем левее. Снова нет. Правее. За этих ребят я не беспокоюсь. С ними все будет ок - у них большое и яркое будущее. У них нацеленность на успех через череду неудач. У них есть знание, что ошибки это тики таймера с обратным счетом которые говорят только об одном - скоро будет успех.

Я же беспокоюсь за других ребят, которые слишком долго вынашивают свои идеи в голове, а потом очень расстраиваются, когда нечто-подобное появляется на просторах сети. Ведь идея не приходит в голову к кому-то одному, она как ливень - кто был на улице и намок, вероятно задумается о изобретении защитного устройства - зонтика. Что мешает идее развиваться? Неуверенность. И по себе сужу сейчас. Кто такой же - пост для тебя. Не знаю когда эта неуверенность возникла, вероятно в детстве, но она живет со мной всегда. Каждый день мы с ней идем на работу, каждый день возвращаемся домой: все ли я сделал правильно, что подумают люди, получится ли, а что дальше? Неуверенность эта это не один единственный голос - это хор из десятков тысяч голосов тех людей, которые говорили когда я слушал. Это было давно, еще до школы, потом в школе, потом в вузе, на первой работе. Они говорили, а я слушал, даже если не хотел. Слова как программы, они прочно встраиваются в мозг и при случае срабатывают.

Иногда я хочу быть как тот пес на картинке. Чтобы не видеть ничего, кроме той мечты, к которой меня манит. В это время не хочется никого видеть и ничего слышать, чтобы не дай бог не сбили с пути истинного. По крайней мере, пока не наберешь достаточно кинетической энергии, чтобы услышанное "позвольте возразить!.." меня уже не остановило. Если на начальном пути если есть красивая картинка впереди что манит, стоит сократить внешний шум до 0 и пилить, пока не будешь готов. Готов к чему? Ну во первых стоит обработать большую часть своих же замечаний. А потом приготовиться получать фидбек и конструктивно превратить внешние "нет, это не будет работать" в "список задач, выполнив которые это заработает".

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

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

Но если проблемы нет, ее можно создать. Все думали что оно "вот так", а теперь оказывается оно совсем иначе! И это даже очень круто, потому как тогда вообще непонятно, что будет и как оно будет. А ты типа в курсе. Как вот было с интернетом или соцсетями. Но могут сжечь. Будь готов. Никто не хочет вот так вот просто выходить из зоны комфорта. Щас.

Почему я верю в то, что идея требует реализации - просто не могло в твоей голове родиться что-то нелепое. Может быть текущая реализация - она и нелепа, но без этого фейла не будет второй, третьей, пятой, седьмой реализации... В голове есть боттлнек - о нем писал раньше. Идею забыть не получится, никто не убедит что это (что я придумал) не сработает, пока сам не проверишь. Может для галочки и согласишься, но идея не пропадет без следа - она будет напоминать о себе мыслями "а что, если бы..." И будет очень печально, если кто-то ее все же реализует. А такое бывает. У меня было. Надо пробовать. Видеть что не вышло. Пробовать еще и идти дальше. Пилить надо в любом случае. И если не понятно что будет в результате - пофиг, там на месте разберемся! Но хоть будет с чем.

Что еще может помочь? Напарник. Тот, из числа немногих ребят, кто думает так же как и ты, кто понимает проблему, тобой решаемую, тот, кто так же хочет ее решить. Я писал и об этом. Посуди сам. Сколько гениальных идей у тебя возникало и сколько из них ты уже реализовал? Прочитал книгу по  Кийосаки про финансовую независимость, подумал что надо делать то-то и се-то, но прошло 5 лет, а воз и ныне там. Прочитал статью про здоровое питание, отметил в мыслях, что хорошо бы, но лишний вес никуда не делся. Придумал интересную концепцию, нарисовал диаграммку но дальше дело не пошло. Собрал группу, обсудил кой-че и так больше ничего не произошло. И так далее... Продолжать можно бесконечно. Все как-то откладывается на завтра. Может быть. Как-нибудь. А время идет. Вот мне например скоро 30. Недавно, кажется, было только 20. Найти напарника-единомышленника.  Вы инструменты в руках друг друга. Дела сдвинутся с места. И с кем обсудить будет. И кому похвастать. С кем порадовать за успех.

Как его найти? Вот эту проблему я и хотел обнажить. Есть идеи. Но есть и неуверенность. А еще все вокруг отговаривают. Или заняты. Дела (твои, а не компании) стоят на месте. Многое из этого решилось бы, но нет напарника. Мечты не приближаются. Жизнь течет. Мама говорит, что пенсия приходит очень быстро. Там будет ретроспектива. Печалька. Проблема? Если да - идем дальше.

У меня есть большая идея пересажать всех айтишников в пары один относительно другого. Пусть Его Величество Нетворкинг все сделает сам. На каждую идею минимум по паре толковых ребят. И начинать я хочу с себя. Мне нужна тулза, в которой я буду вывешивать свое ближайшее расписание (путь это будет часть моего календарика). Скажем, в субботу с 16:00 по 19:00 я буду изучать новый фреймворк. А в воскресенье с 11:00 по 16:00 я буду пилить новую игрульку для codenjoy - реверси. В понедельник с 7 до 9 я буду (я надеюсь) пилить новую идею с тем, чтобы проверить ее чуть позже на большой аудитории. Я понятия не имею кому это интересно. Но я хотел бы, чтобы мои друзья, а так же друзья их друзей видели, чем я занимаюсь - быть может кто-то из них решает (или уже решил) подобную проблему и захочет присоединиться. И пусть в это время он будет со мной в одной комнате, или в другом городе - мы будем решать одну и ту же проблему.

Так же я хочу, видеть кто уже решает мои проблемы. Нет, речь сейчас идет не про гугление конференций или всевозможных юзер-групп, на которых быть может я смогу обрести покой. Я раньше писал, что меня немного утомили конференции, на которых говорит только один человек - докладчик, а все остальные в зале, не менее умные - платят деньги и пассивно слушают. Да, конференции - классный инструмент и отменять их конечно же не стоит. Но хожу туда сейчас только ради нетворкинга. В кулуарах за тех же 40 минут можно тет-а-тет послушать 4 мини-доклада от разных ребят.  

Это тоже проблема (пускай пока только моя), которую я решаю. Провели конференцию java.io2 попробовали несколько новшеств. Уже готовим следюущую серию. И один из будущих форматов который мы попробуем - собрание ребят в определенное время в определенном месте для решения определенной задачи. Задачу пусть каждый сам себе придумает, а потом озвучит. Как показала прошлая java.io2 тем есть предостаточно. Я прийду со своей темой, но зачитав весь список быть может я примкну к кому-то решать его задачу, кто знает? Образуется несколько рабочих групп. Конечно же за 2-3 часа ничего толком не решить, но начало есть. Через два дня очередное собрание - демим результаты. Очень похоже на Хакатон, скорее всего это он и есть. Пусть Хакатонов будет на один больше! И не цель запилить какую-то аппликуху со своей командой, а понетворкать ребят, которые еще не знакомы. Пусть в этом будет отличие. И пусть решат совместно что-нибудь.

Вот это красота! Вот где рождаются идеи.

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

Итак еще раз другими словами. Я хочу иметь тулу, в которой я могу 1) описать вкратце кто такой я, чем увлечен, над чем работаю... 2) описать ближайший свой календарик задач, которые я планирую решить сам, но не хочу делать этого в одиночку 3) дождаться, когда появится заинтересовавшийся напарник (или группа людей) и 4) собраться вместе любым удобным для нас способом. Так же я хочу 5) иметь возможность поучаствовать в решении чьей-то проблемы, при условии, что мне 6) интересен опыт будущего напарника и его mind set. Вот такую тулзу я хочу. И вся трудность в том, что я уже ее пилю... И значит она совсем скоро будет. 

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

А у тебя есть напарник?

Парное программирование полезно при решении задач. Не буду утверждать, что парное программирование все 8 часов в день поможет всем и всегда, нет - сейчас не об этом. Сейчас про парную разработку. Разработку не только кода, а всего того, что может придумать человеческий мозг.

Я заметил, что в тренингах в основном работают пары в разных комбинациях. Бери любую конференцию, любой клуб, любой тренинг, любое собрание - главные идейщики всегда вдвоем. Несколько ярких примеров:
http://www.scrumguides.com - Наташа Тренина и Леша Кривицкий
http://stratoplan.ru  - Слава Панкратов и Саша Орлов
http://xpdays.com.ua - Леша Солнцев и Коля Алименков 
http://qaclub.com.ua - Виктория Мусияченко и Юрий Ековенко
http://itbrunch.com.ua - Тим Евграшин и Коля Алименков
http://pechakucha-kyiv.com - Тимофей Евграшин и Антон Белецкий
http://www.qaclubkiev.com - Андрей Матухно и Саша Майданюк
Да и что греха таить, мы с Серегой тоже почти все тренинговое вместе все делаем. 
А можно продолжать и дальше...

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

И теперь вопрос, а стоит ли и дальше из себя выдавливать эффективность по капельке? Может пора уже найти напарника и вместе вперед! Только вот найти не всегда легко - не все пары срастаются, бывает поработают вместе и разбегаются. И дай Бог, чтобы друзьями. Так что тут не все так просто. Но если найти своего напарника, то дело пойдет. Кстати, из всего того, в чем успел разобраться - Соционика ближе всех подошла ктому какие пары работают, а какие нет.

Творите в парах.

Парноблоггинг

Только что пришла идея. Был такой классный google wave инструмент (не знаю, может есть еще). Суть в том, чтобы заюзать его для написания постов в блоге. Двое, трое людей пишут один пост. Правила: никто не удаляет того, что написал его коллега - только добавляет и, возможно, исправляет грамматические ошибки.

Google wave потому, как сразу видно, что пишет коллега - чувствуется эффект его присутствия и можно менять мысль глядя на то, что пишет напарник.

Кто хочет попарнобложить со мной?

Coding Dojo - экстремальное погружение

Сегодня сутра я шел на работу в припрыжку, ведь на 9:00 мы с Сереежй договорились потестить одну платформочку для программерских соревнований. Сережа описал как она работает в своем блоге. Я лишь поделюсь фидбеками.

Это круто! Это реально круто. Тебя сервак спамит текстовыми запросами, типа:
Привет, меня зовут Петя. Как меня зовут?
Сколько будет 23 + 2?
Как тебя зовут?
и так далее...

Запрос приходит каждые 10 секунд, и если ты не ответил на него или ответил не прапвильно - то с твоего счета снимается какое-то количество очков. Если ответ правильный, то тебе, соответственно, прибавляется некоторое количество очков. Играют все желающие. Любые языки - кто на чем учился.

Что я понял, когда спешишь. Я сразу стал писать через TDD потому как знаю - вот тут он мне точно поможет. Кстати, это классный способ проверить что быстрее TDD или классическая разработка. Что быстрее, парное программирование или работа в одиночку? Теперь есть количественная характеристика - счет игрока. Но мне уже не хочется этим заниматься, я знаю что с TDD быстрее, а в парах качественнее.

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

Работа с IDE. Я ввел в привычку еще пару хоткеев - потому что время идет на секунды! Так же я ужалил нафиг все лишние панели, которые выскакивали. Сережа посоветовал установить плагин вместо того, чтобы регулярки в голове тестить, но я повременил с этим.

Что интересно, соревнуясь с ним, мы все же обменивались советами, потому как подсознательно понимали - в команде работа идет эффективнее, даже если мы соревнуемся.

К концу сеанса мы вышли на финишную и заработали почти равное количество очков (разница на 66, при сумме 1300). Оба довольные как слоны и с улыбками до ушей!

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

Класс! Спасибо Сережа!

Проф fest 2011 - или объяснить школьнику кто такой программист

В пошлом месяце в компании меня попросили выступить с докладом на ПРОФ fest 2011. Согласился, ибо ново. Сразу попросили заполнить анкетку о профессии. Легко (спасибо блогу - опыт текстгенерирования есть).

Очень понравилось общаться с организаторами Алексеем Ястребовым и Аленой Янишевской - ребята были моими гидами на весь период подготовки. И хоть все было описано в изначально предложенном чеклисте (и как следствие запланировано в мой календарь), ребята заблаговременно напоминали мне о том, что нужно сделать что-то со своей стороны. Очень удобно и приятно, спасибо. На будущее я себе запечатлел образ отличного организатора/волонтера. Если тебе когда-нибудь доведется повстречать этих людей - тебе повезло. 

А вот презенташка. Жаль, что обратной связи от школьников не будет, но я старался вселить в них уверенность, что у них получится если захотят. 




В отличие от мастер-классов и тренингов по TDD, где мы с Сережей работали вместе, тут я докладывался сам. Кто-то когда-то сказал, что после продолжительной практики в паре, если садишься кодить сам, то кажется что у тебя удалили пол мозга. То же относится не только к разработке, а еще и к подготовке докладов и выступлениям - тут мне пришлось делать все в одиночку. Чувство было неприятное. Спасибо Косте, моему другу, который предложил свою поддержку и был "школьником" слушая мой доклад. Если бы не Костя, было бы еще грустнее.

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

Еще один момент, который очень помогает в первый раз (когда доклад делается впервые). Если время позволяет - совет нумбер 9 - открой презентацию и начни рассказывать свой доклад плюшевому мишке, а речь свою запиши на диктофон (или компьютер с микрофоном). После прослушай запись доклада. Это действо повтори еще два раза. Первое что ты получишь - это репетиция. Второе - это обратная связь (прослушивание записи). 

Это полезно по двум причинам. Первое. Если ты ранее свой голос не слышал, то будешь неприятно удивлен - тебе он скорее всего не понравится. Помню свое первое публичное выступление - я рассказывал в 10 классе стихотворение. Небольшое - всего 8 строк. Я его заучил, отрепетировал. Ничего не должно было помешать. Но вот пришло время и мне в руки дали микрофон. Начал с первых строк и тут же завис - я никогда раньше не слышал свой голос со стороны. Как результат - я перепутал строки стиха и у меня не получилось рифмы. Смеялись все :) В общем, когда делаешь доклад хорошо бы чтобы твои мысли работали не над оценкой твоего голоса, а над тем, что сказать дальше, как удержать аудиторию...

Второе - ты услышишь то, как звучит твой доклад со стороны. Тут задействованы те участки мозга, которые очень хорошо работают, когда ты слушаешь чей-то доклад на конференции. Скорее всего, если докладчик новичок, то ты его доклад мысленно комментируешь - "ну кто так зажигает публику?", "а тут я бы не говорил это...", "о, а это интересно!". Примечательно то, что при этом не надо напрягаться и пытаться исправить ошибки - просто прослушай свой доклад. Второй раз ты скорее всего будешь рассказывать с учетом твоих же непреднамеренных замечаний. Они учитываются автоматически и подсознательно. А трех итераций - запись - прослушивание хватит для того, чтобы максимально улучшить качество доклада. Не напрягайся и не улучшай ничего осознанно - просто прослушай свой же доклад пару раз.

Если же у тебя времени нет, тогда 15 минут вполне хватит. Подключаешь ноутбук у проектору, открываешь презентацию, включаешь таймер, закрываешься в комнате сам и начинаешь рассказывать вслух. Пускай ты не пройдешься по всем слайдам, но ты проделаешь три вещи:
- Когда зайдут люди и начнется доклад - у тебя будет чувство, что в этой комнате ты уже работал раньше (волнение--).
- Глянув на таймер после 15 минутной репетиции ты узнаешь, сколько времени ты потратил на X слайдов. А при том, что у тебя слайдов в докладе Y, а продолжительность доклада Z - ты сможешь подкорректировать то, что будешь говорить (вернее то, сколько говорить).
- Ты прогреешь мотор. Как оказалось, говорить доклад после 15 минут репетиции - очень помогает. Я не разгонялся в начале доклада, я уже гнал на всех парах.
Так же было любопытно замечание Кости после доклада (он во время репетиции был в комнате {Костя, спасибо за поддержку!}) - "удивительно, но на репитиции ты говорил совсем другое". Видимо так работает мой иррациональный моцк.

Идем дальше! Следующий совет нумбер 10 - запиши в своем блоге отчет о том, как все прошло. Что это дает? Ну во-первых друзья узнают, что с тобой происходило в жизни, и почему "у тебя статус в skype был красный как зад у бабуина" (Саша привет!). Во-вторых есть еще один повод поделятся фидбеком (приятным или нет). Еще одно - если ты выложишь материалы, то сделаешь очень хорошо тем, кто по какой-то причине не мог посетить мероприятие, а теперь имеет возможность сделать это в любое удобное для себя время.

Да! И сделай то, чего я до сих пор не собрался. Совет нумбер 11- напечатай себе визитки. Если ты делаешь доклад, то в любом случае хоть кто-то к тебе подойдет и попросит твоих контактов. А то очень неудобно писать свои контакты всякий раз, когда их попросят. Позже, кто-то из взявших контакты напишет тебе со своей историей, и ты (если пойдешь на контакт), получишь для своего опыта еще один кейс. Новые истории от ребят практикующих то же, что и ты - это прирост в опыте больший, чем когда ты сам работаешь в поисках граблей. Даже, если грабли - детские.

Пока все :)

Если интересуют советы с нумбер 1 по нумбер 7 - можешь почитать про то, как мы с Сережей колесили по Украине с темой Test Driven Development в руках