[alan_n]

This method is great. I use it all the time. But one of these does not feel like the others... (cough "Build a program → Code a function" cough).

All the others could be done in the day, except for the vegetable one which is too abstract. And their solution could be done in 2 minutes. The coding one on the other hand... impossible to do in a day and also writing code is imo almost impossible to write in small chunks of time. Brainstorming a feature,thinking about a problem for 2 minutes, deleting/cleaning code, or even just opening your IDE and checking where you're at and planning the next step, sure. But actual coding, would not recommend. I require at least 30m+, preferably 60m+ to get anything reasonable done.

[LeonB]

I used to code on the bus while commuting to work. There were many interruptions that meant it would only be successful if I optimised it such that I could start/stop at a moment’s notice. Through this experience I learned that you definitely can do highly productive programming work in tiny burts.

Patterns like these were helpful to getting there:

- “do the simplest thing that could possibly work”

- yagni

- shorten the code-compile-test loop

- don’t put up with slow tools

And others made it super super efficient.

[alan_n]

Being interrupted (and especially by the type of interruptions on a bus, like what's the worse interruption? getting asked to move?) or working in bursts is not the same as doing 2 minutes of work then stopping.

The reason I'm nitpicking this example is because I've found it helps substantially to know that even if I only do 2 minutes of the thing, I'm making progress. Otherwise it's very hard to trick my brain into doing the thing. I don't like the "wear running shoes" example either. I have found that when I plan habits like that I maybe do them once or twice, then never again. There is no reward for me without the progress and in the case of the coding example would only bring me frustration.

[LeonB]

A crowded public bus has far more intense interruptions than those in the workplace. I've never been thrown from my seat at work. (Ok -- once.) At work I've never been surrounded by a group of strangers having a shouting argument. And much more.

And there were many bus trips where I would not get a seat until the very end of the ride, and still manage to get work done. A single burst of work was frustrating, but you'd make the most of it. Honestly - it was a transformative experience. I completely agree with you here:

> it helps substantially to know that even if I only do 2 minutes of the thing, I'm making progress.

...and that was the trick for me. Transforming it from "in 2 minutes I won't even get the IDE loaded" to a situation where "in 2 minutes I'll make small but genuine progress, progress that I can bank. A tiny but solid win." And seeing that happen over and over is what got my brain into a place where I would be kind of "proud" instead of "frustrated".

With this topic in general, when you say:

> I don't like the "wear running shoes" example either

...I think maybe you'd need to go back to the real source of this stuff, which is not the linked article, and not James Clear, but Fogg. Also the book 'the power of habit' by Duhigg is quite in depth.

Because if you only read the 1-minute pop-psychology versions it's very easy to pick holes in it and it looks quite superficial, I get that. They present it as just little "hacks" and how can you get a deep trust in it, if it's just gimmicky little hacks?

Anyway, best wishes.

[alan_n]

Mmm I don't know, maybe it's me and the fact I don't have a problem coding for many hours at a time, during which it's one step forward, two back, three forward, etc. We all know how debugging is. If I broke that time down across many 2 minutes as a beginner I would have quit. And currently when I don't have time I'd rather let the problem ruminate in my head than code, or make progress in some of the other ways I mentioned, but definitely not coding.

I've actually read both Fogg (dry and repetitive but more precise) and Clear (more engaging but more fuzzy/muddled concepts) although not Duhigg. Like I said I agree/use the method. I'm not picking holes just pointing out potentially bad examples. Also most people will not read the books. They'll read the 5 minute versions like these. They should have the absolute clearest/best examples.