2013 Secret magic of developer productivity

Почему я об этом рассказываю Производительность разработчиков может отличаться в раз Часто люди склонны свою сравнительно низкую производительность списывать на обстоятельство необоримой силы (сопроцессор в голове ) Хочется развенчать идею о генетически запрограммированном превосходстве

Вопрос слушателям У кого сколько лет опыта разработки ПО?

«О любви не говори, о ней все сказано»(с) В какой-то мере эта строчка относится и к производительности труда разработчика Книг на эту тему очень много. Если их все читать, то времени на собственно разработку не останется. К счастью правило 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++. Убить, расчленить и съесть.» Оба этих варианта не позитивны, не делают Вам чести как профессионалу и совершенно не конструктивны.

Интересное наблюдение Если раньше программа = алгоритмы + структура данных Сейчас это структуры данных + архитектура Фактически доля классических ветхозаветных программистов в современном мире

Мифы

Мифы: серебрянная пуля «Мы перепишем строк с Java на Ruby, т.к. на Ruby разрабочики пишут быстрее.» На самом деле, все современные mainstream платформы в плане производительности труда разработчиков совершенно одинаковы. Разница может быть в пределах 5-10%. Да, исторически переход с Assembler на C/Pascal дал высокий прирост. Появление Delphi дало прирост в разы (особенно для специфичных задач). Появление Java-like плаформ тоже дало прирост, но уже довольно небольшой. Увы, все, что появлялось после, улучшало ситуацию очень не значительно.

Почему тогда это работает? Новая платформа == драйв == высокая производительность. В этом нет ничего плохого, и эффект надо использовать – он есть. Просто не надо думать, что прирост производительности происходит от того, что вы используете язык X. Если Вы так считаете, то Вы обманываете сами себя.

Мифы: работает – не трожь Один из самых живучих мифов, ибо распространяется джуниорами, а джуниорами в той или иной форме были все. На самом деле «не трожь развалится» – это один их первых симптомов плохого кода Хороший код в правильно сделанном проекте от этого только хорошеет Часто существование в проекте таких «черных ящиков» существенно снижает производительность команды

Мифы: отладчик «Я тут весь день код дебажил (я крут, сижу за монитором с непонятными закорюками и вообще все девушки мои). Зачем нужен отладчик (для чего его придумали) – Отладка реально сложных алгоритмов/устройств (кто/когда последний раз програмиировал хоть какой-то алгоритм?) – Работа с библиотеками с плохой документацией (а что у нас в регистре R14 после этого вызова)

Зачем на самом деле используют отладчик в 99% случаев? – В коде бардак, и вместо того, чтобы переписать по нормальному, некоторые пытаются реанимировать мертвое тело посредством некромантии с отладчиком – Лень почитать доку, и вместо этого человек пытается угадать, как работает метод пользуясь отладчиком – Тупить, глядя в отладчик, всяко легче, чем решать проблемы и вообще работать, при этом совесть чиста. Я код 8 часов отлаживал, и вообще фиг знает когда баг починится. – Т.е. это прекрасный способ прокрастинации

Реальный случай «8 часов борьбы с отладчиком vs 5 минут внятно рассказать голосом в чем проблема» aka метод резинового утенка.

Вопросы Skype: denis.tsyplakov

Спасибо