Archive for the ‘Эффективность’ Category

Как научиться учиться?

Пятница, Февраль 29th, 2008

Продолжая тематику образования и эффективности.

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

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

Кстати, описанная проблема это классическое проблема целевика (детальнее о то, что такое целевик можно почитать в статье «Цель vs Путь»)

Таким образом, я по молодости не подготавливал «базу» для решения следующих задач.

Сейчас, я перешел кардинально на другой подход. Обучение я разбиваю на три фазы

А) Сбор информации.

Б) Первичный анализ информации.

В) Сбор вопросов и контроль понимания.

Во время сбора информации, я просто ищу, все, до чего могу добраться на интересующую тему. Например, сегодня я разбирался с Bluetooth на WinMobile и соответственно добрался до общего описания, описания security, описания как бороться с этим security, Widcomm SDK для BT WinCE, Microsoft примеры в Platform Builder’е, ну и еще некоторого количества документов. Все это я просто пробегаю взглядом, чтобы оценить, интересующая меня это информация или нет. Дальше, я аккуратно складываю все в папочку (не читая) и продолжаю поиск. В тот момент, когда я вижу, что документов достаточно  где-то на день чтения, то я перехожу к второй стадии.

В момент первичного анализа информации, я бегло читаю текст (относясь к нему скорее как к художественному произведению, чем как к научному), пытаясь понять, но в случае застревания или не понимания, просто помечая непонятное и выписывая возникшие вопросы. Собственно говоря, я не хочу застревать и разбираться в этот момент, так как вероятнее всего в найденных мной документах информация будет дублироваться и вполне вероятно она где-то будет написана лучше. Например, в моем сегодняшнем случае, в одной статье по security было очень сложно описано, что происходит с ключами в момент pairing устройств. Добравшись до статьи, как бороться с BT security, я обнаружил гораздо более толковое описание.

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

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

Работать 8 часов вредно.

Среда, Февраль 27th, 2008

Интересно, что длина нынешнего рабочего дня, хотя гораздо меньше чем была раньше (10-и или 12-и часов), но тем не менее она не вычислена с умом, а была взята с длительности рабочего дня у представителей профессий физического труда.

В чем тут кроется проблема?

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

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

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

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

В результате выходит, что множество работников IT индустрии работают в режиме загнанной лошади ( бег по 11 часов в день) и при этом от них ждут чудесов интеллектуальности.

В определенный момент, благодаря любимой жене, я обнаружил, что все сложные проблемы я решаю обычно, когда «отпускаю» мысль о проблемах и не загоняю себя по 11 часов. Получается, что работая 6 рабочих часов в день (и имея в результате 8 часов нагрузки на мозг) моя эффективность становится намного выше, чем в 11 часовом марафоне.

Решаем нерешаемые проблемы.

Понедельник, Февраль 25th, 2008

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

Вот некоторые мои характеристики:

— у меня плохая память (API на память я не помню)

— код чаще всего я пишу не слишком аккуратно

— архитектуру, конечно пытаюсь поддерживать, но тоже нельзя сказать, что я великий архитектор

— языки программирования (например тот же C++ на котором постоянно пишу) знаю весьма поверхностно

— техническую документацию читать не люблю

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

Итак, открывает секреты (повышая тем самым себе конкуренцию):

А) Я глубоко убежден, что нерешаемых задач нету. В тот момент, когда даже хорошие программисты бросают задачу с фразой: “Это сделать нереально”. Я продолжаю идти вперед и чаще всего мне таки нахальством/упорством удается ее добить.

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

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

Б) Бывают задачи, которые требуют для решения слишком большого количества времени/ресурсов и т.п.

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

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

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

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

Так, что я не хороший программист. Я человек, который умеет решать нерешаемые проблемы в программировании.

P.S. Я сечас всячески пытаюсь перенести эту область своих умений в бизнес, но похоже это не так просто как казалось изначально, что только придает прелести этой задаче 😉

Серебряная пуля в разрезе.

Воскресенье, Февраль 10th, 2008

В далеком 1986 году, мистер Брукс написал статью «No silver bullet”. Эта статья в последствие стала классикой жанра. И хотя многие не читали оригинальную статью, тем не менее термин «серебряная пуля» очень прижился.

После этого статья вошла в книгу Брукса «мифический человеко-месяц». Тут эта книга есть на русском (похоже издание 95 года).

Для тех, кому лень читать много букв, там говорится о том, что в программировании не будет изобретено никаких методов или технологий, которые позволят существенно (скажем в 10 раз) улучшить эффективность разработки. Идея обосновывается тем, что вся разработка состоит из двух частей – сущности и побочных сложностей. И что сущность нельзя сделать проще, а основные побочные сложности (такие как, например, написание программ на assembler’е) уже упрощены.

Serg Kond в своем блоге сделал интересную заметку насчет статьи о программистском синхрофазотроне. Что по большему счету, я пытаюсь найти серебренную пулю. Я бы сказал, что действительно методика, которая повысит мотивацию хороших программистов может стать серебренной пулей XXI века. Отличие нынешней ситуации от 86 года в том, что разрыв у хороших и плохих программистов в соотношении эффективность/оплата очень уменьшился за последние двадцать лет. Проще говоря, выросло количество плохих программистов получающих достаточно высокие зарплаты и хороших программистов упершихся в зарплатный потолок (который не слишком далек от зарплат плохих программистов). Но, речь впрочем не об этом.

Просто, хочу внести свою небольшую лепту в обсуждение статьи Брукса.

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

Итак, к фактам:

А) Каждый программист получил в свое пользование персональный компьютер (а иногда и несколько).

Б) Компьютеры стали быстрее, что позволяет вести быстрее разработку (более быстрая компиляция и т.п. вещи)

В) Языке стали еще более высокоуровневыми (например, C# vs C).

Г) Операционные системы предоставляют API с функциональностью, которая гораздо богаче, чем в 86 году.

Д) Множество утилит теперь доступны для разработчиков – система контроля версий, трекинга багов, wiki и т.п.

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

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

Однако, я напоследок оставил то, что действительно является «серебряной пулей».

Это – библиотеки. Точнее не только библиотеки, но и разнообразные платформы. За последние двадцать лет появилось гигантское количество открытого доступного кода или хотя бы платформ с открытыми интерфейсами. Казалось бы, ну и что? Ну есть библиотеки, и чем это поможет?

Приведу пример. Возьмем автоматизацию склада в 1986 и в 2008 году.

1986 год: Небольшая программка в текстовом режиме написанная на С (не на C++). Возможности – ввод пришедших товаров, удаление ушедших и показ текущих. База данных хранится в текстовом файлике.

2008 год: RFID ворота на складе, подключенные к машинам на которых установлен Ubuntu с программой, которая выгребает данных с RFID считыватели и по сети закатывает в БД. На сервере крутится программа, которая выгребает данные из БД и через SOAP загружает их в Sales Force Automation (я правда не уверен, что они работаю с складскими данными).

Итого, в первом случае мы имеем программку и человека, считающий ящики на входе и выходе, вводящий постоянно это в программу. Фактически полное отсутствие report’ов и невозможность получения данных на другом компьютере (интернета еще нет)

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

Дай бог 0.01% второй системы написано программистом, а остальные (сайт sales force, библиотеки по работе с RFID, база данных, tcp/ip, xml, soap, графический интерфейс, броузер и т.п.) досталось ему фактически забесплатно. Если бы он пытался написать все сам (даже «срезая углы») у него это заняло бы всю жизнь.

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

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

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

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

P.S. Только дописав статью я понял, за что собственно говоря борется opensource  communit. Ведь собственно во многом именно благодаря им мы получили улучшение в эффективности.

P.P.S. И, кстати, тот же самый WordPress, который я сейчас использую результат этого самого движения.