Thread by @CasualEffects

When coding, I always maintain a journal in the repo (I happen to use Markdeep for this now) with a TODO list.

Tasks are at the level of one hour for "today" stuff, one day for next week, and then week- or longer level tasks.

I expand the details for the next week on Friday.

I expand the one-day tasks into one hour either first or last thing in a day, but ideally as my last action so that I start each day with clear direction.

When I start working on the top, ~1-hour item, on the list, I immediately expand it recursively until the subtasks are completely braindead to implement.

I do all of the hard part of programming here, in the TODO list, figuring out the library calls, designing the APIs, etc.

When I get into the actual source code, I'm just working from my own walk-through on the TODO list, and I only need to think about syntax and code cleanup. I can focus on programming legibly in the small instead of worrying about the big picture.

This process is essential to my productivity, across many tools and languages. It also works exceptionally well for collaboration because my teammates and I can specify together and then implement separately, or hand off already-specified tasks when rescheduling.

For a junior colleague, I'll create the TODO list myself, down to the full task details. For a more senior colleague, I will only specify at the day or week level. For an expert, I'll describe the overall goal and then we'll sketch the day/week together and leave the rest to them

But I follow this process even when coding alone, and even when working on hobby projects. It isn't burdensome at all; it is about reducing the burden of coding.

For example, I'm now working on some new features for the #quadplay web-based game IDE. Here's the top of my list: