One of the biggest productivity improvements I've had as a developer was to make a habit of planning all my work upfront. Specifically, when I pick up a ticket, I break it down into a big bullet point list of TODOs. Doing it this way leads to a better design, to dealing with inter-ticket dependencies upfront, to clarifying the spec upfront (which yes, is part of your job as a senior developer), and most valuable of all it allows me to get into flow state much more regularly when I am programming.

Its not a surprise to me that this approach also helps AI coding agents to work more effectively, as in-depth planning is essentially moving the thinking upfront.

(I wrote more about this here: https://liampulles.com/jira-tickets.html)

I do this process for myself but I also make it a ritual with the juniors and mids I mentor. We'll sit with a new ticket together and do a little brainstorming session. This typically helps me give them a higher-level view of how the specific unit of work fits into the overall ecosystem and provides a lot of clarity that is often sorely lacking in ticket descriptions. Ultimately it'll culminate in a small series of bullet points that describe our intention for the implementation. And I'm very deliberate about the words I choose. Intentions are just that and they will often not survive first contact with the enemy. That's totally fine and when that happens we typically discuss it asynchronously or a quick chat after standup. It's a collaborative process but it has a lot of autonomy baked in.

In my work notes (a giant Markdown file, e.g. 2025.md), my process is extremely similar to the OP, all the way down to the serialized checklist of items being marked off once they're completed.

Waterfall gets an unnecessarily bad rap.

Nobody who delivers any system professionally thinks it’s a bad thing to plan out and codify every piece of the problem you’re trying to solve.

That’s part of what waterfall advocates for. Write a spec, and decompose to tasks until you can implement each piece in code.

Where the model breaks - and what software developers rightly hate - is unnecessarily rigid specifications.

If your project’s acceptance criteria are bound by a spec that has tasked you with the impossible, while simultaneously being impossible to change, then you, the dev, are screwed. This is doubly true in cases where you might not get to implementing the spec until months after the spec has been written - in which case, the spec has calcified into something immutable in stakeholders’ minds.

Agile is frequently used by weak product people and lousy project managers as an excuse to “figure it out when we get there”. It puts off any kind of strategic planning or decision making until the last possible second.

I’ve lost track of the number of times that this has caused rework in projects I’ve worked on.

I wrote this, a few years ago, about being careful to avoid "concrete galoshes"[0].

I've found that it's a balancing act; like so many things in software development. We can't rush in, willy-nilly, but it's also possible to kill the project by spending too much time, preparing (think "The Anal-Retentive Chef" skits, from Saturday Night Live).

Also, I have found that "It Depends" is an excellent mantra for life, in general, and software development, in specific.

I think having LLM-managed specs might be a good idea, as it reduces the overhead required to maintain them.

[0] https://littlegreenviper.com/various/concrete-galoshes/

> One of the biggest productivity improvements I've had as a developer was to make a habit of planning all my work upfront. Specifically, when I pick up a ticket, I break it down into a big bullet point list of TODOs.

You're describing Agile.

Just to further clarify what I said above: What I talk about here specifically is for the developer who picks up a ticket to flesh out and plan the ticket before diving into code.

This doesn't say anything about what is appropriate for larger project planning. I don't have much experience doing project planning, so I'd look to others for opinions on that.

This is how I approach my stories as well. I used to call this “action plan” way before it became fashionable with the rise of AI agents.

It helps me not only reduce the complexity into more manageable chunks but go back to business team for smoothening the rough edges which would otherwise require a rework after review.

It doesn’t seem like you read the article, which argues against this sort of pre-planning.