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.
While I do agree with the content, this tone of writing feels awfully similar to LLM generated posts that flood some productivity subreddits recently. Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves? I don't buy that.
Commenter's history is full of 'red flags':
- "The real cost of this complexity isn't the code itself - it's onboarding"
- "This resonates."
- "What actually worked"
- "This hits close to home"
- "Where it really shines is the tedious stuff - writing tests for edge cases, refactoring patterns across multiple files, generating boilerplate that follows existing conventions."
Yeah; this is such a hard intuition to teach beginners. And something I think will be lost as we move more and more toward vibe coding.
There is so much to be learned about a problem - and programming in general - by implementing stuff and then refactoring it into the ground. Most of the time the abstractions I think up at first are totally wrong. Like, I imagine my program will model categories A, B and C. But when I program it up, the code for B and C is kinda similar. So I combine them, and realise C is just a subset of B. And sometimes then I realise A is a distinct subset of B as well, and I rewrite everything. Or sometimes I realise B and C differ in one dimension, and A and B in another. And that implies there's a fourth kind of thing with both properties.
Do this enough and your code ends up in an entirely unrecognisable place from where you started. But very, very beautiful.
> What surprised me was how much the ugly first version taught me that planning never could.
Fred Brooks, author of “The Mythical Man Month” wrote an essay called “Plan to Throw One Away” in 1975.
He argues much what you’ve described.
Of course, in reality we seldom do actually throw away the first version. We’ve got the tools and skills and processes now to iterate, iterate, iterate.
+1, if you can get positive feelings from doing something bad, i think that gives real improvement to one’s life. “The first step to getting good is being bad”.
Of course you’ll also maintain the satisfaction of doing something well.
> 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.
Nice statement.
I think there is another equally pervasive problem: balancing between shipping something and strategizing a complete "operating system" but in the eyes of OTHER stakeholders.
I'm in this muck now. Working with an insurance co that's building internal tools. On one had we have a COO that wants an operating model for everything and what feels like strategy/process diagrams as proof of work.
Meanwhile I am encouraging not overplanning and instead building stuff, shipping, seeing what works, iterating, etc.
But that latter version causes anxiety as people "don't know what you're doing" when, in fact, you're doing plenty but it's just not the slide-deck-material things and instead the tangible work.
There is a communication component too, of course. Almost an entirely separate discipline.
I've never arrived at acceptable comfort on either side of this debate but lean towards "perfect is the enemy of good enough"
The most important aspect of software design, at least with respect to software that you intend not to completely throw away and will be used by at least one other person, is that it is easy to change, and remains easy to change.
Whether it works properly or not, whether it's ugly and hacky or not, or whether it's slow... none of that matters. If it's easy to change you can fix it later.
Put a well thought out but minimal API around your code. Make it a magic black box. Maintain that API forever. Test only the APIs you ship.
I guess the important (and hard) part is to not make a categorical error and mix up design of high level functionality and UI with the plumbing underneath it.
The plumbing also needs iteration and prototyping, but sound, forward looking decisions at the right time pay dividends later on. That includes putting extra effort and thinking into data structures, error handling, logging, naming etc. rather earlier than later. All of that stuff makes iterating on the higher levels much easier very quickly.
I completely agree and went by the proverb "everything worth doing is worth doing poorly" about a year ago now, it took some time for it to sink in but now I'm actually productive. My main blocker was waiting for other's approval, now I feel a lot more free.
I've forgotten where I've seen this now, but one of the best developers I've seen wrote code by writing it, deleting everything, then writing it again, sometimes many times in order to get their final code. I found it fascinating.
There is a difference between shipping something that works but is not perfect, and shipping something knowingly flawed. I’m appalled at this viewpoint. Let’s hope no life, reputation or livelihood depends on your software.
For my personal projects, which are under zero time constraints, I usually build an ugly version, to figure out the kinks. Then delete it and write a proper one using the lessons I learned the first time.
Yes, but the experience you're describing is just getting stuck due to insufficient experience architecting a solution.
Not saying this is you, but it's so easy for people to give up and sour into hyper-pragmatists competing to become the world's worst management. Their insecurities take over and they actively suppress anyone trying to do their job by insisting everything be rewritten by AI, or push hard for no-code solutions.
This nails my issue with systems design insanity. There are so many things you learn through living with systems that are correct, though counterintuitive.
Do a thing. Write rubbish code. Build broken systems. Now scale scale. Then learn how to deal with the pattern changing as domains specific patterns emerge.
I watched this at play with a friend's startup. He couldn't get response times within the time period needed for his third party integration. After some hacking, we opted to cripple his webserver. Turns out that you can slice out mass amounts of the http protocol (and in that time server overhead) and still meett all of your needs. Sure it needs a recompile - but it worked and scaled, far more then anything else they did. Their exit proved that point.
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.
>You know how you suck and you know how everything sucks and when you see something that sucks, you know exactly how to fix it, because you're an asshole. So that is my advice about getting unblocked. Switch from team "I will one day write something good" to team "I have no choice but to write a piece of shit" and then take off your "bad writer" hat and replace it with a "petty critic" hat and go to town on that poor hack's draft and that's your second draft.
>Your taste is why your work disappoints you... it is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.*
Except you do this in a corporate setting and they will stop you the second it works. And then you are stuck maintaining a barely working version forever.
I learned this the bad way, but now I just lie and say it doesn't work until it's good enough for me
I always try and keep in mind that we typically think of software as having three versions -- alpha, beta, and release -- but for it's considered even kind of "finished."
In my own work, this often looks like writing the quick and dirty version (alpha), then polishing it (beta), then rewrite it from scratch with all the knowledge you gained along the way.
The trick is to not get caught up on the beta. It's all too tempting to chase perfection too early.
> 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.
Funny how these things when done by a human is a positive and when done by an LLM is a negative. According to all the anti-llm experts... Humans generate perfect code on the first pass every time and it's only LLMs that introduce bad implementations. And this isn't a callout on this user in specific. It's a generalization to the anti-ai sentiment on HN. If incremental improvement works, incremental improvement works.
Honestly, it feels like straight up plagiarism. When I saw the title, I thought I knew which website was posted because I had seen it before. When I clicked, I saw an unfamiliar website and was surprised that it was posted 3 days ago rather than a couple months ago.
The contents are so similar, that it cannot be coincidence. It really seems like the author of this blog simply plagiarized the strangestloop post without referring to it at all...
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.
That definitely happens, but I wish had the displeasure of working at companies that were enamored with the solution they have, and couldn't be convinced to look again at the problem and see how it's changed since they originally solved it. As with most anything, the best approach is to somewhere in the middle, combining a love for the problem with a drive to repeatedly solve it. And one of the best tools for that seems to be dog-fooding, when the people in the company really want to use it for themselves.
Somewhat related, I've learned that when you're the one who ends up doing the thing, it's important to take advantage of that. Make decisions that benefit you where you have the flexibility.
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.
Is it always like that? I worked in teams where we had some planning beforehand (months, like in your example). We shipped just fine and the product started to bring money. I guess it depends, as usual.
I agree that planning has diminishing returns, yet simultaneously nearly every software project I’ve been part of has been under-planned and ended up worse off for it.
Analysis paralysis is a thing. And as the article makes very clear, there are a lot of ways to get stuck doing anything else then the one thing you are supposed to be doing.
The way to break through that is indeed to start doing. Forget about the edge cases. Handle the happy path first. Build something that does enough to deliver most of the value. Then refine it; or rebuild it.
Seriously. The cost of prototyping is very low these days. So try stuff out and learn something. Don't be afraid to fail.
One reason LLMs are so shockingly effective for this is that they don't do analysis paralysis; they start doing right away. The end results aren't always optimal or even good but often still good enough. You can optimize and refine later. If that is actually needed. Worst case you'll fail to get a useful thing but you'll have a lot better understanding of the requirements for the next attempt. With AI the sunk cost is measured in tokens. It's not free. But also not very expensive. You can afford to burn some tokens to learn something.
A good rule is to not build a framework or platform for anything until you've built at least three versions of the type of thing that you would use it for. Anything you build before that is likely to be under and overengineered in exactly the wrong places. These places make themselves clear when you build a real system.
Just don't mistake prototyping for doing the thing.
Good enough is a self limiting fallacy.
A prototype failing to attract fans doesn't prove a lack of a market for the job the prototype attempts to perform. It only proves the prototype, as it stands, lacks something.
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.
The happy path is trivial now but I've found the gap between prototype and production is actually wider. You end up spending all your time handling non-determinism and latency issues that simply didn't exist with deterministic code. It seems like the real engineering challenge is just getting the unit economics to work.
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.
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.
There's probably some fuzziness here. I have notes upon notes going back ugh, 20 years (idk how old I am anymore?) that I could count as planning. At some point I need a kick in the ass to do it. Mike Tyson said everyone has a plan until they get punched in the face. Sometimes getting to prod feels like that.
I guess you understand this and are making a joke, but that "attack" would appear to be intentional (and motivating).
I find that I don't have major issues doing a thing once I get started on it. The main problem is choosing from among many things that I could reasonably consider "the thing", and then feeling confident enough in that choice to start.
There are things that humans have to unfortunately do when working as a group of people. That's why we became the alpha predator. Not because we were the strongest ape. That includes:
- Filling in timesheets, quarterly, half yearly cycles, company meetings, team meetings is not doing the thing — as a solopreneur. But not as a member of a group.
- Writing tickets, reviewing PRs is not doing the thing — as a solopreneur.
- Commuting to work and back is not doing the thing — If I'm a solopreneur this doesn't even matter.
- Answering technical questions, analyzing data, attending to bugs is not doing the thing — If I'm a solopreneur especially on a greenfield stuff, I have zero baggage.
- Writing test cases and putting up alerts is not doing the thing — if it's only me judging me, I have nothing to judge.
I take it to mean: if you can just do the thing now (you are in the right place, healthy, with tools and prerequisites) and you choose not to because of (procrastination reasons) then you could be doing the task but you choose not to.
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.
That's OK. It's totally fine to not doing the thing. Find joy however you want.
But it's not good to lie to yourself about doing the thing while not doing the thing. If your joy comes from the result of doing the thing, but you're putting time into other things that aren't doing the thing, that joy is not getting any closer.
This is something I ran into, ego satisfaction, where you tell people/show things like concepts, talk about it, get the "that sounds cool" but yeah it's not real. I now try to build something real like a hardware project before showing it.
I split activities at work into "Engineering" and "Talking about Engineering". We're a consultancy so there's a certain amount of "Talking about Engineering" that is required and good, but I try not to lose sight of what is actually engineering and what isn't.
What I am still on the fence about is when "design" or "architecture" type work counts as Engineering. There's a certain amount of design work that is valuable to do before coding and is part of the thinking process. But sometimes you get into a lot of abstract talking that is "not 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.
Sometimes that's because they're making it worthwhile, by connecting the thing with those who will benefit from it and explaining how to use it, which is as valuable as doing the thing.
I.e. by making sure that they're doing the right thing.
Writing a litany about doing the thing is not doing the thing.
Posting on HN about doing the thing is not doing the thing.
Commenting about doing the thing is not doing the thing.
Will this continue to be true? I do agree with the principle. But I've sometimes had the feeling that poor design upfront can have compounding consequences, especially when AI is filling in ambiguities.
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
I get the sentiment, but thinking and planning are important steps to doing things. Obviously you can’t stop there, and you shouldn’t spend too much time on that part, but it is still important.
If some task has a known step-by-step pattern, then doing it step by step makes perfect sense. That is doing the thing. Taking the known shortest/best path.
Doing the thing is going to involve both direct steps, and indirect steps necessary to do the direct steps.
Not doing the thing involves doing things other than the shortest/safest/effective path to getting the thing done.
This is a useful methodology and article nudges the reader towards doing things and "taking action". I am sure it will appeal to a huge number of people and indeed, rightly it has climbed to the top of HN, else I would have completely missed it.
I have found these articles on the exact same topic to be creating more actionable mindset.
1. The cult of done by No Boilderplate: https://youtu.be/bJQj1uKtnus?si=efV5OTF35LcDjuN3. Through the years, I have come back to this video many a times and even have the Cult of Done manifesto (snipped from this video) stuck on to my wall.
2. High agency by George Mack: https://www.highagency.com/. This is a long form article and sitting and just reading it has helped me unblock myself. I have a bookmark of this on my favourites bar at all times.
When saying 'doing the thing', we often mean getting some progress or a result. I'd say you did the thing if you consider the result created by the AI acceptable.
I don’t get it? Are they sharing a quote they liked or taking credit for it? Maybe they just saw the YouTube video and decided to turn it into the page?
Edit:
Seems like a way to show they’re looking for roles, I guess.
This version has the general form of the original, So why does it seem there is something odd about it?
Whoever the guy from ‘Strangest Loop’ is it’s my impression that it’s meant to resonate with self-starters; as if he’s speaking from that vantage of and for hustle culture. The grinders. The movers. The seniors. The managers. The founders. [1]
I don’t get that vibe from this derivative and in fact I think it carries a slight affect of a neurotic employee while the original airs determination. Reading this brings one into the mind of an observer, the founder of a VC firm, watching OP wring over a Palo Alto brewed latte.
[1] Am I the only one who was unable to find out his actual name on this website?
So the typical nonsensical argument is that an architect should be a builder.
Alright.
You can very much do the thing when it's not too costly to fuck up. For many important things, thinking about doing the thing is even more important than doing the thing.
I like that this place still primarily focuses on the message (even just the headline) rather than the messenger. Feels like an antifeature of the big social media platforms that who’s saying it is often more important than what’s being said.
as a counter point, in another current thread https://news.ycombinator.com/item?id=46789913, there's a discussion of the "hostile codebase" of openssl. maybe they neglected preparation and "just did it"?
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.
Who are you, to define what "the thing" is, for someone else?
Doing the thing isn't about judging other people. That doesn't contribute to your thing.
If someone is bothering you, making it hard to do your thing, then your thing involves talking to them about your problem. Without judging what they are doing.
Oh.. So you start doing something new and you're top 10% without practicing or being bad at it first? I'd love to test that to see if it's the case... Your logic is "You're not the best ever to do something so you are not doing it" means you have probably never done a single thing your entire life. Maybe you should just stop.
jackfranklyn|1 month ago
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.
A_Venom_Roll|1 month ago
Commenter's history is full of 'red flags': - "The real cost of this complexity isn't the code itself - it's onboarding" - "This resonates." - "What actually worked" - "This hits close to home" - "Where it really shines is the tedious stuff - writing tests for edge cases, refactoring patterns across multiple files, generating boilerplate that follows existing conventions."
josephg|1 month ago
There is so much to be learned about a problem - and programming in general - by implementing stuff and then refactoring it into the ground. Most of the time the abstractions I think up at first are totally wrong. Like, I imagine my program will model categories A, B and C. But when I program it up, the code for B and C is kinda similar. So I combine them, and realise C is just a subset of B. And sometimes then I realise A is a distinct subset of B as well, and I rewrite everything. Or sometimes I realise B and C differ in one dimension, and A and B in another. And that implies there's a fourth kind of thing with both properties.
Do this enough and your code ends up in an entirely unrecognisable place from where you started. But very, very beautiful.
stevoski|1 month ago
Fred Brooks, author of “The Mythical Man Month” wrote an essay called “Plan to Throw One Away” in 1975.
He argues much what you’ve described.
Of course, in reality we seldom do actually throw away the first version. We’ve got the tools and skills and processes now to iterate, iterate, iterate.
pinkmuffinere|1 month ago
Of course you’ll also maintain the satisfaction of doing something well.
aaronblohowiak|1 month ago
https://wiki.c2.com/?PlanToThrowOneAway
grvdrm|1 month ago
Nice statement.
I think there is another equally pervasive problem: balancing between shipping something and strategizing a complete "operating system" but in the eyes of OTHER stakeholders.
I'm in this muck now. Working with an insurance co that's building internal tools. On one had we have a COO that wants an operating model for everything and what feels like strategy/process diagrams as proof of work.
Meanwhile I am encouraging not overplanning and instead building stuff, shipping, seeing what works, iterating, etc.
But that latter version causes anxiety as people "don't know what you're doing" when, in fact, you're doing plenty but it's just not the slide-deck-material things and instead the tangible work.
There is a communication component too, of course. Almost an entirely separate discipline.
I've never arrived at acceptable comfort on either side of this debate but lean towards "perfect is the enemy of good enough"
nly|1 month ago
The most important aspect of software design, at least with respect to software that you intend not to completely throw away and will be used by at least one other person, is that it is easy to change, and remains easy to change.
Whether it works properly or not, whether it's ugly and hacky or not, or whether it's slow... none of that matters. If it's easy to change you can fix it later.
Put a well thought out but minimal API around your code. Make it a magic black box. Maintain that API forever. Test only the APIs you ship.
dgb23|1 month ago
The plumbing also needs iteration and prototyping, but sound, forward looking decisions at the right time pay dividends later on. That includes putting extra effort and thinking into data structures, error handling, logging, naming etc. rather earlier than later. All of that stuff makes iterating on the higher levels much easier very quickly.
bionsystem|1 month ago
zipy124|1 month ago
aryehof|1 month ago
There is a difference between shipping something that works but is not perfect, and shipping something knowingly flawed. I’m appalled at this viewpoint. Let’s hope no life, reputation or livelihood depends on your software.
vrighter|1 month ago
Madmallard|1 month ago
sublinear|1 month ago
Not saying this is you, but it's so easy for people to give up and sour into hyper-pragmatists competing to become the world's worst management. Their insecurities take over and they actively suppress anyone trying to do their job by insisting everything be rewritten by AI, or push hard for no-code solutions.
KolibriFly|1 month ago
cik|1 month ago
Do a thing. Write rubbish code. Build broken systems. Now scale scale. Then learn how to deal with the pattern changing as domains specific patterns emerge.
I watched this at play with a friend's startup. He couldn't get response times within the time period needed for his third party integration. After some hacking, we opted to cripple his webserver. Turns out that you can slice out mass amounts of the http protocol (and in that time server overhead) and still meett all of your needs. Sure it needs a recompile - but it worked and scaled, far more then anything else they did. Their exit proved that point.
TheAlchemist|1 month ago
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.
black_puppydog|1 month ago
Got me through many a rough spot.
nlawalker|1 month ago
Dan Harmon's advice on writer's block: https://www.reddit.com/r/Screenwriting/comments/5b2w4c/dan_h...
>You know how you suck and you know how everything sucks and when you see something that sucks, you know exactly how to fix it, because you're an asshole. So that is my advice about getting unblocked. Switch from team "I will one day write something good" to team "I have no choice but to write a piece of shit" and then take off your "bad writer" hat and replace it with a "petty critic" hat and go to town on that poor hack's draft and that's your second draft.
"The Gap" by Ira Glass: https://www.reddit.com/r/Screenwriting/comments/c98jpd/the_g...
>Your taste is why your work disappoints you... it is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.*
gonzalohm|1 month ago
I learned this the bad way, but now I just lie and say it doesn't work until it's good enough for me
rewgs|1 month ago
In my own work, this often looks like writing the quick and dirty version (alpha), then polishing it (beta), then rewrite it from scratch with all the knowledge you gained along the way.
The trick is to not get caught up on the beta. It's all too tempting to chase perfection too early.
KolibriFly|1 month ago
replooda|1 month ago
tstrimple|1 month ago
Funny how these things when done by a human is a positive and when done by an LLM is a negative. According to all the anti-llm experts... Humans generate perfect code on the first pass every time and it's only LLMs that introduce bad implementations. And this isn't a callout on this user in specific. It's a generalization to the anti-ai sentiment on HN. If incremental improvement works, incremental improvement works.
longnguyen|1 month ago
[0]: https://strangestloop.io/essays/things-that-arent-doing-the-...
HendrikHensen|1 month ago
The contents are so similar, that it cannot be coincidence. It really seems like the author of this blog simply plagiarized the strangestloop post without referring to it at all...
lessconfused|1 month ago
jgeada|1 month ago
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.
falcor84|1 month ago
KolibriFly|1 month ago
nlawalker|1 month ago
Somewhat related, I've learned that when you're the one who ends up doing the thing, it's important to take advantage of that. Make decisions that benefit you where you have the flexibility.
theshrike79|1 month ago
dzonga|1 month ago
specially the middle managers i.e engineering managers, senior engineering manager, director of engineering duh duh
there's less coordination to do - to keep managers up to date.
the most functional software orgs out there - don't have managers
hahahahhaah|1 month ago
augusteo|1 month ago
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.
jstanley|1 month ago
"Preparation" isn't mentioned explicitly, but by my reading it would come firmly under "is not doing the thing".
dakiol|1 month ago
dwd|1 month ago
From the Red Dwarf book and quoted previously:
https://news.ycombinator.com/item?id=28033747
tshaddox|1 month ago
KolibriFly|1 month ago
sghiassy|1 month ago
Pivoting to zero-planning, would also have a basket of flaws.
jillesvangurp|1 month ago
The way to break through that is indeed to start doing. Forget about the edge cases. Handle the happy path first. Build something that does enough to deliver most of the value. Then refine it; or rebuild it.
Seriously. The cost of prototyping is very low these days. So try stuff out and learn something. Don't be afraid to fail.
One reason LLMs are so shockingly effective for this is that they don't do analysis paralysis; they start doing right away. The end results aren't always optimal or even good but often still good enough. You can optimize and refine later. If that is actually needed. Worst case you'll fail to get a useful thing but you'll have a lot better understanding of the requirements for the next attempt. With AI the sunk cost is measured in tokens. It's not free. But also not very expensive. You can afford to burn some tokens to learn something.
A good rule is to not build a framework or platform for anything until you've built at least three versions of the type of thing that you would use it for. Anything you build before that is likely to be under and overengineered in exactly the wrong places. These places make themselves clear when you build a real system.
retropragma|1 month ago
Good enough is a self limiting fallacy.
A prototype failing to attract fans doesn't prove a lack of a market for the job the prototype attempts to perform. It only proves the prototype, as it stands, lacks something.
Beware quitting early. All good builders do.
arscan|1 month ago
1. https://strangestloop.io/essays/things-that-arent-doing-the-...
2. https://news.ycombinator.com/item?id=45939431
crazygringo|1 month ago
Goofy_Coyote|1 month ago
tibbar|1 month ago
In the GenAI era, "doing the thing badly without planning" has become so easy that some counterweight is needed.
storystarling|1 month ago
thunfischtoast|1 month ago
ericmcer|1 month ago
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.
HPsquared|1 month ago
ninju|1 month ago
thunfischtoast|1 month ago
wanderingmind|1 month ago
llbbdd|1 month ago
MrGilbert|1 month ago
I needed this today. Currently questioning my career choices, as I hit my first wall where people are involved. Gave me quite the headache.
dondraper36|1 month ago
zahlman|1 month ago
I find that I don't have major issues doing a thing once I get started on it. The main problem is choosing from among many things that I could reasonably consider "the thing", and then feeling confident enough in that choice to start.
llbbdd|1 month ago
dijksterhuis|1 month ago
myst|1 month ago
rdsubhas|1 month ago
There are things that humans have to unfortunately do when working as a group of people. That's why we became the alpha predator. Not because we were the strongest ape. That includes:
- Filling in timesheets, quarterly, half yearly cycles, company meetings, team meetings is not doing the thing — as a solopreneur. But not as a member of a group.
- Writing tickets, reviewing PRs is not doing the thing — as a solopreneur.
- Commuting to work and back is not doing the thing — If I'm a solopreneur this doesn't even matter.
- Answering technical questions, analyzing data, attending to bugs is not doing the thing — If I'm a solopreneur especially on a greenfield stuff, I have zero baggage.
- Writing test cases and putting up alerts is not doing the thing — if it's only me judging me, I have nothing to judge.
hahahahhaah|1 month ago
I take it to mean: if you can just do the thing now (you are in the right place, healthy, with tools and prerequisites) and you choose not to because of (procrastination reasons) then you could be doing the task but you choose not to.
For corps: timesheets is one of the things.
jjmarr|1 month ago
zikani_03|1 month ago
This one hit me right in the feels, I have been buying more woodworking/DIY tools than the projects I've worked on with them.
unknown|1 month ago
[deleted]
dakiol|1 month ago
munificent|1 month ago
But it's not good to lie to yourself about doing the thing while not doing the thing. If your joy comes from the result of doing the thing, but you're putting time into other things that aren't doing the thing, that joy is not getting any closer.
ge96|1 month ago
rkangel|1 month ago
What I am still on the fence about is when "design" or "architecture" type work counts as Engineering. There's a certain amount of design work that is valuable to do before coding and is part of the thinking process. But sometimes you get into a lot of abstract talking that is "not doing the thing".
nowittyusername|1 month ago
poolnoodle|1 month ago
mbsa7|1 month ago
smingo|1 month ago
“Writing about writer’s block is better than not writing at all.”
KolibriFly|1 month ago
robofanatic|1 month ago
TuringTest|1 month ago
I.e. by making sure that they're doing the right thing.
Nevermark|1 month ago
amarant|1 month ago
Life is tough like that
stared|1 month ago
Guilty as charged, going back to work.
otikik|1 month ago
I like that this was included.
calebhwin|1 month ago
moralestapia|1 month ago
Corollary: whoever has done something, even "wrong", is 1,000x more valuable as somebody else who is "planning to do it someday".
soiltype|1 month ago
cortesoft|1 month ago
hahahahhaah|1 month ago
Doing the thing2 is doing the thing2
unknown|1 month ago
[deleted]
matchagaucho|1 month ago
I still believe there's a mise en place step before doing the thing, when quality counts.
Nevermark|1 month ago
Doing the thing is going to involve both direct steps, and indirect steps necessary to do the direct steps.
Not doing the thing involves doing things other than the shortest/safest/effective path to getting the thing done.
hrtk|1 month ago
s3micolon0|1 month ago
I have found these articles on the exact same topic to be creating more actionable mindset.
1. The cult of done by No Boilderplate: https://youtu.be/bJQj1uKtnus?si=efV5OTF35LcDjuN3. Through the years, I have come back to this video many a times and even have the Cult of Done manifesto (snipped from this video) stuck on to my wall.
2. High agency by George Mack: https://www.highagency.com/. This is a long form article and sitting and just reading it has helped me unblock myself. I have a bookmark of this on my favourites bar at all times.
taikahessu|1 month ago
OpenDrapery|1 month ago
olliepro|1 month ago
keithluu|1 month ago
tony_cannistra|1 month ago
doodpants|1 month ago
sghiassy|1 month ago
munificent|1 month ago
neko_ranger|1 month ago
CuriouslyC|1 month ago
unknown|1 month ago
[deleted]
LTL_FTC|1 month ago
Edit: Seems like a way to show they’re looking for roles, I guess.
unknown|1 month ago
[deleted]
_springbootapp|1 month ago
tolerance|1 month ago
Whoever the guy from ‘Strangest Loop’ is it’s my impression that it’s meant to resonate with self-starters; as if he’s speaking from that vantage of and for hustle culture. The grinders. The movers. The seniors. The managers. The founders. [1]
I don’t get that vibe from this derivative and in fact I think it carries a slight affect of a neurotic employee while the original airs determination. Reading this brings one into the mind of an observer, the founder of a VC firm, watching OP wring over a Palo Alto brewed latte.
[1] Am I the only one who was unable to find out his actual name on this website?
ramshanker|1 month ago
oldestofsports|1 month ago
Why not? If i need a saw to build a deck, buying a saw must be the first step?
trentnix|1 month ago
seec|1 month ago
You can very much do the thing when it's not too costly to fuck up. For many important things, thinking about doing the thing is even more important than doing the thing.
COMMENT___|1 month ago
gordonhart|1 month ago
1317|1 month ago
dzonga|1 month ago
globalnode|1 month ago
mike741|1 month ago
PrettiGoodDead|1 month ago
[deleted]
mojuba|1 month ago
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.
redmattred|1 month ago
Nevermark|1 month ago
Doing the thing isn't about judging other people. That doesn't contribute to your thing.
If someone is bothering you, making it hard to do your thing, then your thing involves talking to them about your problem. Without judging what they are doing.
funkmasterzeb|1 month ago
jdefr89|1 month ago
scandox|1 month ago
8note|1 month ago
the answer isnt to stop practicing, its to practice the right thing and not practice doing it wrong.
theyre probably still better off playing badly and enjoying it, vs just staring at an unplayed piano though
ashtonshears|1 month ago
pyrolistical|1 month ago