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