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

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

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

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

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

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

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

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

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

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

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

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

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

Невозможно управлять тем, что нельзя измерить.

Невозможно понять то, модель чего нельзя описать.

Невозможно решить проблему, которую нельзя сформулировать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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