раз

Secret magic of developer
productivity
2013
Почему я об этом
рассказываю
• Производительность разработчиков может
отличаться в 10-20 раз
• Часто люди склонны свою сравнительно
низкую производительность списывать на
обстоятельство необоримой силы
(сопроцессор в голове )
• Хочется развенчать идею о генетически
запрограммированном превосходстве
Вопрос слушателям
У кого сколько лет опыта
разработки ПО?
«О любви не говори,
о ней все сказано»(с)
• В какой-то мере эта строчка относится и к
производительности труда разработчика
• Книг на эту тему очень много. Если их все
читать, то времени на собственно
разработку не останется.
• К счастью правило 20/80 тут работает, и
путем незначительных улучшений можно
достичь значительного прогресса
Step back: чем же занимаются
разработчики?
Мне нужна ваша помощь… 
Жмут на клавиши
• На самом деле результат нашей работы в
сыром виде это код. Да, мы решаем проблемы
заказчика, делаем бизнес-анализ,
коммуницируем. Но все-таки 95% работы
разработчиков, в конечном счете, это код
программ (работающих).
• Чтобы писать код, надо тупо жать на клавиши.
Очевидно, что надо жать в правильном
порядке на нужные клавиши.
История о игре Life на Turbo Pascal
Немного математики
• За день в зависимости от проекта
разработчик производит примерно в
среднем от 10Кб до 30Кб кода.
• 30Кб кода с современными IDE (code
complete и т.п.) это где-то 6000 раз нажать
на клавиши. При довольно невысокой
скорости печати в 120 знаков в минуту это
получается 50 минут.
Ого!!!
• Получается, что для того чтобы за день
добиться более чем впечатляющего
результата (для сравнения 30Кб это код
класса java.util.HashMap), надо потратить
всего 50 минут.
• Почему-то в реальной жизни так не
получается. Мы делаем паузы и жмем на
кнопки с перерывами.
Что надо чтобы жать на клавиши
без остановки?
Quick answers
1. Драйв/Мотивация
2. Знания
3. Фокус
4. Правильная организация работы в проекте
5. Умение «ловить поток» и не терять его
6. Научная организация труда aka ясная голова
7. GTD
… список можно продолжать, но остановимся на
красивой цифре 7
Драйв он же правильная
мотивация
• Вам должно нравиться (очень очень нравиться)
–
–
–
–
–
Программировать вообще
Программировать на этой платформе
Работать над этим конкретным проектом
Работать с этими людьми
Работать …
Без этой «чалмы» магия не работает. Вообще.
Крутые профессионалы могут компенсировать
отстствие драйва высокой з/п, но не долго и далеко не
все. И им нравится быть профессионалами (что тоже
драйв).
Знания
• Надо много знать. Чтобы понимать какие
кнопки жать.
• Не знание одного конкретного аспекта это 1%
вероятности фэйла и ступора. Количество
вещей, которые надо знать для создания
среднего проекта – >1000
• Часто львиную долю времени работы
разработчика отнимает чтение StackOverflow и
документации /именно в таком порядке  /
Учите матчасть (с) анекдот
Фокус
• Четко понимать, что надо делать, как и
зачем.
• Есть очень много путей к цели
• Исселедуя библиотеки, читая
документацию, создавая свою архитектуру,
слои бизнес логики и utility классы, можно
потерять месяцы времени, не
приблизившись к цели ни на шаг
Организация работы в
проекте
• Требования
• План работ
• Координация, QA, utility tasks (design, веб
верстка, нарезка картинок etc.)
• Кто за что отвечает, где, кого и что искать, кого
спрашивать
• И т.д.
В общем-то обычно это забота менеджера, но
если человек не знает что ему надо, ему очень
тяжело «продать» требования, план работ и т.д.
Умение «ловить поток»
и не терять его
• Что такое поток и как его «поймать», я
рассказывать не буду. На всякий случай, в
двух словах….
• В общем-то если бы вы этого не умели, то
вы бы меня наверное сейчас не слушали 
Поток: что тут важно
• Понимание что нет потока – нет кода. Если решили
отвлечься, отвлечься – отвлекайтесь. Решили работать –
ловите поток. Будете смешивать – не отдохнете и не
поработаете.
• Умение не сбиваться. Сидеть на горной вершине с
ноутбуком и кодить – не получится, и то что к вам
приходят коллеги и пытаются вас из состояния потока
выбить это нормально. Надо учиться не отвлекаться.
• По моим наблюдениям наиболее ушлые синьеры из
потока не выходят, а интерфейс с внешним миром
умело эмулируют, находясь непосредственно в потоке –
сбить с мысли их либо очень сложно, либо вообще
невозможно. Но у этого состояние есть хорошо
известные недостатки. 
GTD
Search wiki: GTD aka
«Умение разобраться с
делами»
Будьте позитивны
• Есть два очень неприятных стереотипа:
– «ААА! Мы занимаемся планированием иттерации, а
заказчик спросил у меня чатом какого цвета кнопка на
странице sales.php. О ужас! Как так можно работать! Он
совершенно не понимает кошерный скрам, нас же
нельзя отвлекать. Все плохо-плохо-плохо!!!»
– «Ты посмотри, какой нехороший человек! Он написал
i=i+1 вместо i++. Убить, расчленить и съесть.»
Оба этих варианта не позитивны, не делают Вам чести
как профессионалу и совершенно не конструктивны.
Интересное
наблюдение
• Если раньше программа = алгоритмы + структура
данных
• Сейчас это структуры данных + архитектура
• Фактически доля классических ветхозаветных
программистов в современном мире <0,1%
остальные, сейчас фокус сместился в сторону того,
что 30-40 лет назад называли архитектурой.
• При этом культура во многом не изменилась, и
далеко не все это изменение осознают. Это
изменение привело к появлению некоторого
количества мифов – правил, которые работали
раньше но не работают сейчас.
Мифы
Мифы: серебрянная
пуля
• «Мы перепишем 1000000 строк с Java на Ruby, т.к. на
Ruby разрабочики пишут быстрее.»
• На самом деле, все современные mainstream
платформы в плане производительности труда
разработчиков совершенно одинаковы. Разница может
быть в пределах 5-10%.
• Да, исторически переход с Assembler на C/Pascal дал
высокий прирост. Появление Delphi дало прирост в разы
(особенно для специфичных задач).
• Появление Java-like плаформ тоже дало прирост, но уже
довольно небольшой.
• Увы, все, что появлялось после, улучшало ситуацию
очень не значительно.
• Почему тогда это работает?
• Новая платформа == драйв == высокая
производительность.
• В этом нет ничего плохого, и эффект надо
использовать – он есть. Просто не надо
думать, что прирост производительности
происходит от того, что вы используете язык
X. Если Вы так считаете, то Вы обманываете
сами себя.
Мифы:
работает – не трожь
• Один из самых живучих мифов, ибо
распространяется джуниорами, а джуниорами
в той или иной форме были все.
• На самом деле «не трожь развалится» – это
один их первых симптомов плохого кода
• Хороший код в правильно сделанном проекте
от этого только хорошеет 
• Часто существование в проекте таких «черных
ящиков» существенно снижает
производительность команды
Мифы: отладчик
• «Я тут весь день код дебажил (я крут, сижу за
монитором с непонятными закорюками и
вообще все девушки мои).
• Зачем нужен отладчик (для чего его
придумали)
– Отладка реально сложных алгоритмов/устройств
(кто/когда последний раз програмиировал хоть
какой-то алгоритм?)
– Работа с библиотеками с плохой документацией (а
что у нас в регистре R14 после этого вызова)
• Зачем на самом деле используют отладчик в
99% случаев?
– В коде бардак, и вместо того, чтобы переписать по
нормальному, некоторые пытаются
реанимировать мертвое тело посредством
некромантии с отладчиком
– Лень почитать доку, и вместо этого человек
пытается угадать, как работает метод пользуясь
отладчиком
– Тупить, глядя в отладчик, всяко легче, чем решать
проблемы и вообще работать, при этом совесть
чиста. Я код 8 часов отлаживал, и вообще фиг знает
когда баг починится.
– Т.е. это прекрасный способ прокрастинации
Реальный случай
«8 часов борьбы с отладчиком vs 5 минут
внятно рассказать голосом в чем проблема»
aka метод резинового утенка.
Вопросы
Email: lc@yandex.ru
Skype: denis.tsyplakov
Спасибо