Форум продуктивных

Здравствуйте! Я программист , читаю вашу замечательную книгу, конспектирую, пересказываю своими словами, чтобы полностью понять материал. Сейчас остановился на 5-й главе (ещё не прочёл). Возник вопрос к автору, Вы пишите, что обезьяне нужно поручать только те задачи, над которыми не надо думать, а если и надо то делать это минимально, цитата из книги (стр. 70)

3. Задачу можно выполнить, по минимуму используя мышление (в
идеале формулировка должна вызывать внутренний возглас: «Да это уже
проще сделать, чем записать!»).

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

Например задача вида: Написать код для многопоточности в юните UserStore по ответу Асама с GitHub.
Здесь подразумевается, что во время написания кода я буду думать, и на мой взгляд здесь должно быть исключение из правил, если я не прав, объясните пожалуйста этот момент.

Обезьян не должен думать, чем ему заняться, где взять пререквизиты и тд.
По примеру: не должно быть "Написать код ... по ответу Асама с GitHub"
Должно быть или " изучить ответ Асама" - в процессе ответ дербанится на ИНФО и задачи
Или уже "Написать код для многопоточности с учетом ХХХ", где ХХХ - конкретный контекст, а не ссылка на руководящий документ.

У программистов более прокачанная обезьяна Она умеет немного думать.

Написать код для многопоточности в юните UserStore по ответу Асама с GitHub

Звучит вполне себе как задача...

Иногда можно попробовать формулировки вида:
Вставить сниппет из ответа Асама, посмотреть, заработает ли

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

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

Написать код для многопоточности в юните UserStore по ответу Асама с GitHub - высокоуровневая задача. Перед тем как приступать к выполнению задачи, делю высокоуровневую задачу на понятные мне куски. Куски должны быть понятны лично мне, а не коллеге \ тимлиду \ заказчику. Эти куски - вехи, без которых задача не будет считаться выполненной. Пример обезьянопонятных вех:
- попробовать послать запрос к github и посмотреть глазами содержимое ответа
- запустить прогармму в дебаггере и смотреть как работают различные сценарии текущей реализации многопоточности

Большинство моих задач начинаются с "Засечь помидор и тупить в заведенную задачу в системе таскооборота, пока не станет понятно что именно непонятно, затем записать вехи".

Если же есть факт пробуксовки выполнения задач, то хорошо отмечать для себя триггеры тупняков и избавляться от них. Примеры тупняков:
- вообще нихрена непонятно, фрустрация, ад, хочется к маме на руки. Нужно идти и узнавать что всё-таки подразумевается. Задавать вопросы пока не станет понятно, а ответы записывать.
- по мере выполнения задачи резко стало понятно что возникнет такой-то баг или уязвимость, в общем, какая-то критическая вещь, про которую вот никак нельзя забыть. Либо стало понятно что нужно уточнить у заказчика что-либо. Например, что github не отдает нужных данных. Предпочитаю не переключаться и судорожно фиксить, а сформулировать хоть как-то и после помидора доформулировать уже в годную задачу. А конкретно текущий помидор - доделываю чтобы код начал работать и выполнять свою бизнес-задачу (за которую уплачены ресурсы заказчика).
- лежащий билд - невозможность погонять свой код (отвлекают ошибки, потому что понимаю что может наложиться сложность и будут непонятные баги).
- отсутствие возможности запустить программу чтобы подебажить. Возможность дебажить и видеть содержимое переменных - сильно экономит мыслетопливо. Не нужно в голове удерживать хрустальный замок (хотя это очень приятно, через 2 недели уже не вспомнишь что написал).
- если проект большой, бывает трудно найти место для своего кода. В таком случае нужно найти место, где можно писать хоть как-нибудь, главное чтобы писалось, а позже уже перенести.
- никак не придумываются имена методов, имена переменных, хотя понятно что надо написать. В таком случае у меня переменные dasd, dsajdl12, и перед коммитом придумываю что-нибудь понятное коллегам.

Так или иначе, хотелось бы больше информации по вашей проблеме

Вот, кстати, да. Тут каждая задача чуть ли не в проект превращается.

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

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

Приведу утрированную аналогию. Для вас, программиста, написать скрипт "hello world" не будет являться сложной, непонятной задачей или проектом, и ваша обезьянка даже с удовольствием может это сделать. А вот обезьянка слесаря-сантехника из жэка наверняка может даже впасть в кому от такой задачи. Но в то же время верно и обратное: заменить "кран-буксу в смесителе" для программиста может стать целым проектом, особенно если даже не знаешь как эта неведомая сущность выглядит.

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