The "doing it badly" principle changed everything for me. I spent weeks planning the perfect architecture for some automation tools I was building. Then I just... stopped planning and built the ugly version that solved my own pain point.

What surprised me was how much the ugly first version taught me that planning never could. You learn what users actually care about (often not what you expected), which edge cases matter in practice, and what "good enough" looks like in context.

The hardest part is giving yourself permission to ship something you know is flawed. But the feedback loop from real usage is worth more than weeks of hypothetical architecture debates.

"Doing it badly is doing the thing."

This one works for me, and I've learned it from a post on HN. Whenever I feel stuck or overthink how to do something, just do it first - even with all the flaws that I'm already aware of, and if it feels almost painful to do it so badly. Then improve it a bit, then a bit, then before I know it a clear picture start to emerge... Feels like magic.

I used to think this. Then I noticed how often "preparation" became its own infinite loop.

At work we built something from a 2-page spec in 4 months. The competing team spent 8 months on architecture docs before writing code. We shipped. They pivoted three times and eventually disbanded.

Planning has diminishing returns. The first 20% of planning catches 80% of the problems. Everything after that is usually anxiety dressed up as rigor.

The article's right about one thing: doing it badly still counts. Most of what I know came from shipping something embarrassing, then fixing it.

At a previous company we used to joke that most of management was a "problem admiration society":

They'd love to talk about problems, investigate them from all angles, make plans on how to plan to solve the problem, identify who caused it or how to blame for it, quantify how much it costs us or how much money we could make from solving it, everything and anything except actually doing something about it.

It was never about doing the thing.

On the other hand: sometimes doing the thing is itself a bad idea. One reason I continue to insist on design docs and code review is that I'd rather find this out ahead of time rather than deal with the damage afterwards.

In the GenAI era, "doing the thing badly without planning" has become so easy that some counterweight is needed.

This is very similar to [1] (as discussed here [2]). It is a good message though, which is why I remember the earlier post at all.

1. https://strangestloop.io/essays/things-that-arent-doing-the-...

2. https://news.ycombinator.com/item?id=45939431

In "Remains of The Day" they call just talking about "the thing" an indulgence. Which is really what it is, it feels good, isn't hard, and doesn't achieve anything.

The characters in the book are quick to cut non-productive discussions short, but it feels like the feel good discussions around "the thing" are about as far as many people want to go these days.

My nitpick is that thinking and dreaming about solving the problem is part of doing. Its the planning phase. Skipping This planning phase in Software engineering is the root cause of most Day 2 operations issues. However I agree that thinking or announcing about outcome is not doing.

On the other hand.. planning, preparation and mise-en-place can help with doing the thing.

I wholeheartedly agree. In an age of talking heads. you will not hear from the people actually doing the thing. because they too busy doing the thing versus talking about it. now excuse me ima go back to doing the thing.

A bit of a meta lesson for me here: Writing a short, pointed, opinionated blog post is blogging. If I care about blogging my thoughts, I need to just do it, not worry about rigor or depth ahead of time

A lot of tech-savvy people (like me) love solving meta-problems. Doing the thing that would take 10 minutes? Na man, let me build an unnecessary complicated technical solution that in theory enables hundreds of people to do the thing much more efficiently in just 2 minutes. That takes a month and the thing has not been done, ha.

"Failing while doing the thing is doing the thing."

I needed this today. Currently questioning my career choices, as I hit my first wall where people are involved. Gave me quite the headache.

I kinda agree, but I also gain pleasure from doing all those things that are not supposed to be "the thing". The thinking, the dreaming, the visualizing... I just like that. I do it a lot when working on personal projects (which some of them I never ship). I think it's fine, and I wouldn't go as far as saying that those things are "not doing the thing"; in many ways those things are "the thing", at least for me.

As a person with ADHD, I feel personally attacked.

Am I crazy or have I read this or a very similar post before?

in short learn by doing.

Is telling AI to do thing, doing the thing?

Ironically people who fall in not doing the thing category of this article are valued more than those who do the thing.

Is planning, like deciding how to position your troops in battle, doing the thing?

"Everybody wants to be a bodybuilder but nobody wants to lift no heavy ass weights!"

> Doing it badly is doing the thing.

No it's not. Sometimes (or maybe most of the time) doing it badly means maybe it's not your thing.

I used to have a neighbour who liked to play the piano and sing. He was doing it consistently badly and he didn't have anyone to tell him that he should probably stop trying.