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."
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves? I don't buy that.
I understand that it's not the main point in your comment (you're trying to determine if the parent comment was written using an LLM), but yes, we do exist: I've spent years planning personal projects that remain unimplemented. Don't underestimate the power of procrastination and perfectionism. Oliver Burkeman ("Four Thousand Weeks", etc.) could probably explain that dynamic better than me.
> While I do agree with the content, this tone of writing feels awfully similar to LLM generated posts
> Commenter's history is full of 'red flags': - "The real cost of this complexity isn't the code itself - it's onboarding" - "This resonates."
Wow it's obvious in the full comment history. What is the purpose for this stuff? Do social marketing services maintain armies of bot accounts that just build up credibility by doing normal-ish comments, so they can called on later like sleeper cells for marketing? On Twitter I already have scroll down to find the one human reply on many posts.
And when the bots get a bit better (or people get less lazy prompting them, I'm pretty sure I could prompt to avoid this classic prose style) we'll have no chance of knowing what's a bot. How long until the majority of the Internet be essentially a really convincing version of r/SubredditSimulator? When I stop being able to recognize the bots, I wonder how I'll feel. They would probably be writing genuinely helpful/funny posts, or telling a touching personal story I upvote, but it's pure bot creative writing.
[deleted]
I didn't catch it immediately, but after you pointed it out I totally agree. That comment is for sure LLM written. If that involved a human in the loop or was fully automated I cannot say.
We currently live in the very thin sliver of time where the internet is already full of LLM writing, but where it's not quite invisible yet. It's just a matter of time before those Dead Internet Theory guys score another point and these comments are indistinguishable from novel human thought.
> … the internet is already full of LLM writing, but where it's not quite invisible yet. It's just a matter of time …
I don't think it will become significantly less visible⁰ in the near future. The models are going to hit the problem of being trained on LLM generated content which will cause the growth in their effectiveness quite a bit. It is already a concern that people are trying to develop mitigations for, and I expect it to hit hard soon unless some new revolutionary technique pops up¹².
> those Dead Internet Theory guys score another point
I'm betting that us Habsburg Internet predictors will have our little we-told-you-so moment first!
--------
[0] Though it is already hard to tell when you don't have your thinking head properly on sometimes. I bet it is much harder for non-native speakers, even relatively fluent ones, of the target language. I'm attempting to learn Spanish and there is no way I'd see the difference at my level in the language (A1, low A2 on a good day) given it often isn't immediately obvious in my native language. It might be interesting to study how LLM generated content affects people at different levels (primary language, fluent second, fluent but in a localised creole, etc.).
[1] and that revolution will likely be in detecting generated content, which will make generated content easier to flag for other purposes too, starting an arms race rather than solving the problem overall
[2] such a revolution will pop up, it is inevitable, but I think (hope?) the chance of it happening soon is low
To me it seems like it'd only get more visible as it gets more normal, or at least more predictable.
Remember back in the early 2000's when people would photoshop one animals head onto another and trick people into thinking "science has created a new animal". That obviously doesn't work anymore because we know thats possible, even relatively trivial, with photoshop. I imagine the same will happen here, as AI writing gets more common we'll begin a subconscious process of determining if the writer is human. That's probably a bit unfairly taxing on our brains, but we survived photoshop I suppose
This reminds me of how bad browsing the internet will likely get this year. There are a ton of 'Cursor for marketing' style startups going online now that basically spam every acquisition channel possible.
Not sure about this user specifically, but interesting that a lot of their comments follow a pattern of '<x> nailed it'
This is true, but the need to read critically especially on the internet has become an indispensable skill anyway.
Psy-ops, astroturfing, now LLM slop.
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves?
Probably. I've been known to spend weeks planning something that I then forget and leave completely unstarted because other things took my attention!
> Commenter's history is full of 'red flags'
I wonder how much these red flags are starting to change how people write without LLMs, to avoid being accused of being a bot. A number of text checking tools suggested replacing ASCII hyphens with m-dashes in the pre-LLM-boom days¹ and I started listening to them, though I no longer do. That doesn't affect the overall sentence structure, but a lot of people jump on m-/n- dashes anywhere in text as a sign, not just in “it isn't <x> - it is <y>” like patterns.
It is certainly changing what people write about, with many threads like this one being diverted into discussing LLM output and how to spot it!
--------
[1] This is probably why there are many of them in the training data, so they are seen as significant by tokenisation steps, so they come out of the resulting models often.
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves?
Ironically, I see this very often with AI/vibe coding, and whilst it does happen with traditional coding too, it happens with AI to an extreme degree. Spend 5 minutes on twitter and you'll see a load of people talking about their insane new vibe coding setup and next to nothing of what they're actually building
[deleted]
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.
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.
To me, that is the only way to write code.
One of my friends calls it "development-driven development".
> 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.
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.
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.
+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.
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.
This is the right point to mention "How Big Things Get Done" by Bent Flyvbjerg. You can iterate your design without putting lives into danger.
"I spent weeks planning" -- using the terminology from that book: No, you didn't spend weeks planning, you spent weeks building something that you _thought_ was a plan. An actual plan would give you the information you got from actually shipping the thing, and in software in particular "a model" and "the thing" look very similar, but for buildings and bridges they are very different.
I want to do this with a multiplayer online game I'm working on but you just can't do it wrong and have it actually work though :/
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.
"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.
"Everything worth doing is worth doing badly."
Got me through many a rough spot.
it fits well enough into another frame - make it work, then make it pretty, then make it fast
if youre worried about doing it well, youre a step or two ahead of where you need to be
>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.*
Henry Rollins too.
'“One day, I’m gonna write that novel.” Pal? You better start tomorrow morning because the right time never happens. It’s when you boldly determine it. It’s like running on a rainy day. You’re fine once you get out there. The only difficulty is getting off the couch when you lace your shoes up.'
I miss Harmontown dearly. He was always dropping solid-gold wisdom like this in the middle of otherwise borderline-incoherent rants.
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
^^^ THIS ... If what you're building is useful, showing someone a prototype too early can cause the whole company to rush you to deploy.
Everyone's threshold is different. I aspire to "move fast and break things", but more often than not, I obsess over the rough edges.
This is what it looks like when trust has broken down at a company. Management don't trust engineers when they say "this needs more time". And engineers don't trust management with the truth (it kinda works - we really could ship it now if we wanted to).
Remarkably common, but not inevitable. Thankfully there's plenty of workplaces which don't look like this.
And yeah, lying is certainly one way to get work done in a bad organisation. I'd much rather - if at all possible - to find and fix the actual problem.
Another fun one is when sales has already sold the thing to the customer without there being a product to sell. At that point it stops being about trust it's just "get it out there".
I hate this, but seems to be fairly normal practice.
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.
> Funny how these things when done by a human is a positive and when done by an LLM is a negative.
> Humans generate perfect code on the first pass every time and it's only LLMs that introduce bad implementations.
That's not what the "anti-llm experts" are saying at all. If you think of LLMs as "bad first draft" machines, then you'll likely be successful in finding ways to use LLMs.
But that's not what is being sold. Atman and Amodei are not selling "this tool will make bad implementations that you can improve on". They are selling "this tool will replace your IT department". Calling out that the tool isn't capable of doing that is not pretending that humans are perfect by comparison.
"When in doubt, use brute force."
The essay is quite similar to this one from strangestloop.io[0]
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...
I’m glad someone mentioned this. Couldn’t remember where I’d read this but knew there was something really similar.
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.
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.
Oh man, I feel this.
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.
you remove "managers" then simply rate of output goes up.
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
Output goes up until everything fails catastrophically
That is OK if that fed into a decision to do another thing now because of <good reasons>.
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.
I think you may have slightly misunderstood the article.
"Preparation" isn't mentioned explicitly, but by my reading it would come firmly under "is not doing the thing".
Getting everyone to fall in love with the thing is not doing the thing... learned this as a data scientist brought in to work on a project which ended soon thereafter. A team of 20 people spent 1.5 years getting people to love an idea which never materialized. Time was wasted because the technical limitations and issues came too late... it died as a 40 page postmortem that will never see daylight.
I learned that lesson as a solo dev on a project that lasted a year, then learned it again as a team of 4 on a 2-year project. I've not had to learn the lesson again but I've certainly trod the same path... 20 people (including some VERY expensive contractors), 3.5 years, AU$80m to deliver what amounts to a timesheeting system that needs a team of 10 people manually massaging the data every month to make it work.
How do you not be "toxic" after that? How do you retain a chipper attitude when you know for a rock-solid certainty that even if the project is successful it's likely by accident?
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.
I think the original agile people had the right idea. Do some planning, not too much. Then write some code - but not too much. Then take what you've learned from implementing and replan.
Or if you want another way of thinking about it, code isn't only useful for deployment. Its also a tool you can use during the planning process to learn more about the problem you're trying to solve. When planning, the #1 killer is unknown unknowns. You can often discover a lot of them by building a super simple prototype.
Rimmer planning for his astro-navigation exam sums up the "infinite loop" of preparation.
Pivoting to zero-planning, would also have a basket of flaws.
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.
Beware quitting early. All good builders do.
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.
The discussion is going to be so similar, this really ought to be marked as a [dupe].
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.
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.
On the other hand.. planning, preparation and mise-en-place can help with doing the thing.
But only if you end up doing the thing (and avoid analysis paralysis)
I think the point is people mistaking planning, preparation, talking about the thing... for doing the thing.
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.
The article was great — for solopreneurs.
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.
"Filling in timesheets" sucks until you want to qualify for R&D credits.
I dont take the post too literally.
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.
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.
As a person with ADHD, I feel personally attacked.
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.
What about doing the thing intently for a week and then realizing later you haven't touched the project in 6 months?
This sounds not too dissimilar to the release the POC to prod mentality.
There are times where you obviously need to do the thing to understand the thing to see the process of doing the thing. This allows for breaking the process down into better steps. Just writing code to do things you think is doing thing but prove not to do the thing when actually doing the thing is common.
I'm talking about having completely different, unstarted, overall projects in mind.
that sounds like paralysis by analysis. just pick a project and go.
Same. I'm tempted to print this post out and hang it for inspiration. But I guess that would also not be doing the thing.
I have bad ADHD and printed the strangestloop.io blog post out and put it on the wall by my work desk in Oct 2023 according to the printout timestamp. I still haven't done the thing in some meaningful areas, and the print has honestly kind of been dispiriting. I'm going to take this post as the prompt to take it down.
I'm going to consider this with the same weight I would if my future grey-bearded self popped out of a portal to say it, thank you. I've had a sticky note on my monitor for a few years that just says "SHIP SHIP SHIP SHIP SHIP SHIP"; it might be time for that to go before it becomes much more depressing.
[deleted]
sometimes i find that being okay with not doing the thing is exactly the thing i need to do to be okay with getting around to doing the thing
Coming up with excuses is not doing the thing.
Who claimed it was?
"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.
> "Buying tools for the thing is not doing the thing."
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.
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.
Thanks for this. It is timely.
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.
Am I crazy or have I read this or a very similar post before?
“Writing about writer’s block is better than not writing at all.”
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.
Planning to do the thing is a new thing, thing2
Doing the thing2 is doing the thing2
Ok, but thing2 is a dependency of thing, so you have to do thing2 before you can do thing.
What do you gain by saying it isn't thing? You have to do it first either way.
Ironically people who fall in not doing the thing category of this article are valued more than those who do 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.
Are they "not doing the thing", or are they "doing the different thing"?
Selling the thing isn't doing the thing, but it pays more!
Life is tough like that
Let's all switch to finance.
"If I had six hours to chop down a tree, I’d spend the first four sharpening the axe."
I still believe there's a mise en place step before doing the thing, when quality counts.
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.
Sure, but a lot of the things on the list marked as “not doing the thing” are actually important early steps to 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
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.
Reading or adding comments is not doing the thing.
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.
[deleted]
> Buying tools for the thing is not doing the thing.
Why not? If i need a saw to build a deck, buying a saw must be the first step?
Is telling AI to do thing, doing the thing?
The more I use AI to do the thing, the more it feels like I didn't do the thing.
Yet the thing got done. Perhaps in the age of AI, it’s about making things get done.
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.
Idk, depends. Is going to office-hours in order to pass an exam "doing the thing?" Help seems fine.
Brother please add proper exception handling :/D
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.
[deleted]
Is planning, like deciding how to position your troops in battle, doing the thing?
Planning is doing the planning thing, but it is not doing the battle thing.
And running the marathon is just running the marathon? I disagree. Big part of running the marathon is in the preparation. Weeks after weeks of training and not skipping a single session. The marathon itself is the tip of the iceberg; important but not the whole "thing".
There are some things that you just can't do without preparation. But never mistake the preparation for doing the thing. You can be "getting in shape for a marathon" forever without ever running a marathon.
It depends on your thing. If the marathon was just the motivation, your thing is running... if the marathon was the bucketlist item, it is the thing.
No matter how much preparation and training one does, if they haven’t run the marathon, they haven’t run the marathon.
Right, but conversely you can’t run the marathon unless you train. You can’t skip straight to doing the thing.
But both are doing the winning thing, which is more valuable than just the battle thing. Unless you do it just for fun and don't mind the result.
I don't know anything about planning and battle.
But as a metaphor for other creative pursuits, my experience is that most of the time when people are "planning" or working on other things that they like to believe will help them do the thing... they are really just avoiding doing the thing.
People spend years doing "world-building" and writing character backgrounds and never write the damn book. Aspiring musicians spend thousands collecting instruments and never make a song.
As you say, if it's just for fun, that's all fine. But if the satisfaction you want comes from the result of the thing, you have to do the thing.
[deleted]
Thank you for shaking me once more .....
"Everybody wants to be a bodybuilder but nobody wants to lift no heavy ass weights!"
"Ain't nuttin but a peanut"
in short learn by doing.
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"?
TLDR: "Just do it." ~ Nike
[flagged]
> 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.
People sometimes do things because they enjoy doing them, even if they aren’t particularly good at them.
I have two problems with that. One is, you can do what you like quietly and without disturbing anyone around you. Second is the Dunning Kruger effect: witnessing it first hand is never fun.
And both of those problems are yours, not your neighbor’s.
To your neighbor, doing it badly is still doing the thing.
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.
Yeah the dude should have stopped doing what he liked
Well you are pretty bad at comments. Hang up the keyboard bud
no, theres a different thing here, which is that practice needs yo be deliberate.
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
Maybe people did tell him he sucked, but he was having fun
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."
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves? I don't buy that.
I understand that it's not the main point in your comment (you're trying to determine if the parent comment was written using an LLM), but yes, we do exist: I've spent years planning personal projects that remain unimplemented. Don't underestimate the power of procrastination and perfectionism. Oliver Burkeman ("Four Thousand Weeks", etc.) could probably explain that dynamic better than me.
> While I do agree with the content, this tone of writing feels awfully similar to LLM generated posts
> Commenter's history is full of 'red flags': - "The real cost of this complexity isn't the code itself - it's onboarding" - "This resonates."
Wow it's obvious in the full comment history. What is the purpose for this stuff? Do social marketing services maintain armies of bot accounts that just build up credibility by doing normal-ish comments, so they can called on later like sleeper cells for marketing? On Twitter I already have scroll down to find the one human reply on many posts.
And when the bots get a bit better (or people get less lazy prompting them, I'm pretty sure I could prompt to avoid this classic prose style) we'll have no chance of knowing what's a bot. How long until the majority of the Internet be essentially a really convincing version of r/SubredditSimulator? When I stop being able to recognize the bots, I wonder how I'll feel. They would probably be writing genuinely helpful/funny posts, or telling a touching personal story I upvote, but it's pure bot creative writing.
I didn't catch it immediately, but after you pointed it out I totally agree. That comment is for sure LLM written. If that involved a human in the loop or was fully automated I cannot say.
We currently live in the very thin sliver of time where the internet is already full of LLM writing, but where it's not quite invisible yet. It's just a matter of time before those Dead Internet Theory guys score another point and these comments are indistinguishable from novel human thought.
> … the internet is already full of LLM writing, but where it's not quite invisible yet. It's just a matter of time …
I don't think it will become significantly less visible⁰ in the near future. The models are going to hit the problem of being trained on LLM generated content which will cause the growth in their effectiveness quite a bit. It is already a concern that people are trying to develop mitigations for, and I expect it to hit hard soon unless some new revolutionary technique pops up¹².
> those Dead Internet Theory guys score another point
I'm betting that us Habsburg Internet predictors will have our little we-told-you-so moment first!
--------
[0] Though it is already hard to tell when you don't have your thinking head properly on sometimes. I bet it is much harder for non-native speakers, even relatively fluent ones, of the target language. I'm attempting to learn Spanish and there is no way I'd see the difference at my level in the language (A1, low A2 on a good day) given it often isn't immediately obvious in my native language. It might be interesting to study how LLM generated content affects people at different levels (primary language, fluent second, fluent but in a localised creole, etc.).
[1] and that revolution will likely be in detecting generated content, which will make generated content easier to flag for other purposes too, starting an arms race rather than solving the problem overall
[2] such a revolution will pop up, it is inevitable, but I think (hope?) the chance of it happening soon is low
To me it seems like it'd only get more visible as it gets more normal, or at least more predictable.
Remember back in the early 2000's when people would photoshop one animals head onto another and trick people into thinking "science has created a new animal". That obviously doesn't work anymore because we know thats possible, even relatively trivial, with photoshop. I imagine the same will happen here, as AI writing gets more common we'll begin a subconscious process of determining if the writer is human. That's probably a bit unfairly taxing on our brains, but we survived photoshop I suppose
This reminds me of how bad browsing the internet will likely get this year. There are a ton of 'Cursor for marketing' style startups going online now that basically spam every acquisition channel possible.
Not sure about this user specifically, but interesting that a lot of their comments follow a pattern of '<x> nailed it'
This is true, but the need to read critically especially on the internet has become an indispensable skill anyway.
Psy-ops, astroturfing, now LLM slop.
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves?
Probably. I've been known to spend weeks planning something that I then forget and leave completely unstarted because other things took my attention!
> Commenter's history is full of 'red flags'
I wonder how much these red flags are starting to change how people write without LLMs, to avoid being accused of being a bot. A number of text checking tools suggested replacing ASCII hyphens with m-dashes in the pre-LLM-boom days¹ and I started listening to them, though I no longer do. That doesn't affect the overall sentence structure, but a lot of people jump on m-/n- dashes anywhere in text as a sign, not just in “it isn't <x> - it is <y>” like patterns.
It is certainly changing what people write about, with many threads like this one being diverted into discussing LLM output and how to spot it!
--------
[1] This is probably why there are many of them in the training data, so they are seen as significant by tokenisation steps, so they come out of the resulting models often.
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves?
Ironically, I see this very often with AI/vibe coding, and whilst it does happen with traditional coding too, it happens with AI to an extreme degree. Spend 5 minutes on twitter and you'll see a load of people talking about their insane new vibe coding setup and next to nothing of what they're actually building
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.
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.
To me, that is the only way to write code.
One of my friends calls it "development-driven development".
> 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.
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.
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.
+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.
https://wiki.c2.com/?PlanToThrowOneAway
> ship something you know is flawed
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.
This is the right point to mention "How Big Things Get Done" by Bent Flyvbjerg. You can iterate your design without putting lives into danger.
"I spent weeks planning" -- using the terminology from that book: No, you didn't spend weeks planning, you spent weeks building something that you _thought_ was a plan. An actual plan would give you the information you got from actually shipping the thing, and in software in particular "a model" and "the thing" look very similar, but for buildings and bridges they are very different.
I want to do this with a multiplayer online game I'm working on but you just can't do it wrong and have it actually work though :/
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.
"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.
"Everything worth doing is worth doing badly."
Got me through many a rough spot.
it fits well enough into another frame - make it work, then make it pretty, then make it fast
if youre worried about doing it well, youre a step or two ahead of where you need to be
My two favorite bits of wisdom in this vein:
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.*
Henry Rollins too.
'“One day, I’m gonna write that novel.” Pal? You better start tomorrow morning because the right time never happens. It’s when you boldly determine it. It’s like running on a rainy day. You’re fine once you get out there. The only difficulty is getting off the couch when you lace your shoes up.'
I miss Harmontown dearly. He was always dropping solid-gold wisdom like this in the middle of otherwise borderline-incoherent rants.
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
^^^ THIS ... If what you're building is useful, showing someone a prototype too early can cause the whole company to rush you to deploy.
Everyone's threshold is different. I aspire to "move fast and break things", but more often than not, I obsess over the rough edges.
This is what it looks like when trust has broken down at a company. Management don't trust engineers when they say "this needs more time". And engineers don't trust management with the truth (it kinda works - we really could ship it now if we wanted to).
Remarkably common, but not inevitable. Thankfully there's plenty of workplaces which don't look like this.
And yeah, lying is certainly one way to get work done in a bad organisation. I'd much rather - if at all possible - to find and fix the actual problem.
Another fun one is when sales has already sold the thing to the customer without there being a product to sell. At that point it stops being about trust it's just "get it out there".
I hate this, but seems to be fairly normal practice.
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.
> Funny how these things when done by a human is a positive and when done by an LLM is a negative.
> Humans generate perfect code on the first pass every time and it's only LLMs that introduce bad implementations.
That's not what the "anti-llm experts" are saying at all. If you think of LLMs as "bad first draft" machines, then you'll likely be successful in finding ways to use LLMs.
But that's not what is being sold. Atman and Amodei are not selling "this tool will make bad implementations that you can improve on". They are selling "this tool will replace your IT department". Calling out that the tool isn't capable of doing that is not pretending that humans are perfect by comparison.
"When in doubt, use brute force."
The essay is quite similar to this one from strangestloop.io[0]
[0]: https://strangestloop.io/essays/things-that-arent-doing-the-...
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...
I’m glad someone mentioned this. Couldn’t remember where I’d read this but knew there was something really similar.
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.
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.
Oh man, I feel this.
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.
you remove "managers" then simply rate of output goes up.
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
Output goes up until everything fails catastrophically
That is OK if that fed into a decision to do another thing now because of <good reasons>.
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.
I think you may have slightly misunderstood the article.
"Preparation" isn't mentioned explicitly, but by my reading it would come firmly under "is not doing the thing".
Getting everyone to fall in love with the thing is not doing the thing... learned this as a data scientist brought in to work on a project which ended soon thereafter. A team of 20 people spent 1.5 years getting people to love an idea which never materialized. Time was wasted because the technical limitations and issues came too late... it died as a 40 page postmortem that will never see daylight.
I learned that lesson as a solo dev on a project that lasted a year, then learned it again as a team of 4 on a 2-year project. I've not had to learn the lesson again but I've certainly trod the same path... 20 people (including some VERY expensive contractors), 3.5 years, AU$80m to deliver what amounts to a timesheeting system that needs a team of 10 people manually massaging the data every month to make it work.
How do you not be "toxic" after that? How do you retain a chipper attitude when you know for a rock-solid certainty that even if the project is successful it's likely by accident?
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.
I think the original agile people had the right idea. Do some planning, not too much. Then write some code - but not too much. Then take what you've learned from implementing and replan.
Or if you want another way of thinking about it, code isn't only useful for deployment. Its also a tool you can use during the planning process to learn more about the problem you're trying to solve. When planning, the #1 killer is unknown unknowns. You can often discover a lot of them by building a super simple prototype.
Rimmer planning for his astro-navigation exam sums up the "infinite loop" of preparation.
From the Red Dwarf book and quoted previously:
https://news.ycombinator.com/item?id=28033747
That’s not a zero-sum game.
Pivoting to zero-planning, would also have a basket of flaws.
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.
Beware quitting early. All good builders do.
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
The discussion is going to be so similar, this really ought to be marked as a [dupe].
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.
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.
On the other hand.. planning, preparation and mise-en-place can help with doing the thing.
But only if you end up doing the thing (and avoid analysis paralysis)
I think the point is people mistaking planning, preparation, talking about the thing... for doing the thing.
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.
The article was great — for solopreneurs.
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.
"Filling in timesheets" sucks until you want to qualify for R&D credits.
I dont take the post too literally.
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.
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.
As a person with ADHD, I feel personally attacked.
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.
What about doing the thing intently for a week and then realizing later you haven't touched the project in 6 months?
This sounds not too dissimilar to the release the POC to prod mentality.
There are times where you obviously need to do the thing to understand the thing to see the process of doing the thing. This allows for breaking the process down into better steps. Just writing code to do things you think is doing thing but prove not to do the thing when actually doing the thing is common.
I'm talking about having completely different, unstarted, overall projects in mind.
that sounds like paralysis by analysis. just pick a project and go.
Same. I'm tempted to print this post out and hang it for inspiration. But I guess that would also not be doing the thing.
I have bad ADHD and printed the strangestloop.io blog post out and put it on the wall by my work desk in Oct 2023 according to the printout timestamp. I still haven't done the thing in some meaningful areas, and the print has honestly kind of been dispiriting. I'm going to take this post as the prompt to take it down.
I'm going to consider this with the same weight I would if my future grey-bearded self popped out of a portal to say it, thank you. I've had a sticky note on my monitor for a few years that just says "SHIP SHIP SHIP SHIP SHIP SHIP"; it might be time for that to go before it becomes much more depressing.
sometimes i find that being okay with not doing the thing is exactly the thing i need to do to be okay with getting around to doing the thing
Coming up with excuses is not doing the thing.
Who claimed it was?
"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.
> "Buying tools for the thing is not doing the thing."
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.
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.
Thanks for this. It is timely.
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.
Am I crazy or have I read this or a very similar post before?
I thought the same thing. From a few months ago: https://news.ycombinator.com/item?id=45939431
https://www.anquotes.com/charles-bukowski-quotes/ has some similar themes.
“Writing about writer’s block is better than not writing at all.”
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.
Planning to do the thing is a new thing, thing2
Doing the thing2 is doing the thing2
Ok, but thing2 is a dependency of thing, so you have to do thing2 before you can do thing.
What do you gain by saying it isn't thing? You have to do it first either way.
Ironically people who fall in not doing the thing category of this article are valued more than those who do 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.
Are they "not doing the thing", or are they "doing the different thing"?
Selling the thing isn't doing the thing, but it pays more!
Life is tough like that
Let's all switch to finance.
"If I had six hours to chop down a tree, I’d spend the first four sharpening the axe."
I still believe there's a mise en place step before doing the thing, when quality counts.
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.
Sure, but a lot of the things on the list marked as “not doing the thing” are actually important early steps to 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
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.
Reading or adding comments is not doing the thing.
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.
> Buying tools for the thing is not doing the thing.
Why not? If i need a saw to build a deck, buying a saw must be the first step?
Is telling AI to do thing, doing the thing?
The more I use AI to do the thing, the more it feels like I didn't do the thing.
Yet the thing got done. Perhaps in the age of AI, it’s about making things get done.
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.
Idk, depends. Is going to office-hours in order to pass an exam "doing the thing?" Help seems fine.
Brother please add proper exception handling :/D
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.
Is planning, like deciding how to position your troops in battle, doing the thing?
Planning is doing the planning thing, but it is not doing the battle thing.
And running the marathon is just running the marathon? I disagree. Big part of running the marathon is in the preparation. Weeks after weeks of training and not skipping a single session. The marathon itself is the tip of the iceberg; important but not the whole "thing".
There are some things that you just can't do without preparation. But never mistake the preparation for doing the thing. You can be "getting in shape for a marathon" forever without ever running a marathon.
It depends on your thing. If the marathon was just the motivation, your thing is running... if the marathon was the bucketlist item, it is the thing.
No matter how much preparation and training one does, if they haven’t run the marathon, they haven’t run the marathon.
Right, but conversely you can’t run the marathon unless you train. You can’t skip straight to doing the thing.
But both are doing the winning thing, which is more valuable than just the battle thing. Unless you do it just for fun and don't mind the result.
I don't know anything about planning and battle.
But as a metaphor for other creative pursuits, my experience is that most of the time when people are "planning" or working on other things that they like to believe will help them do the thing... they are really just avoiding doing the thing.
People spend years doing "world-building" and writing character backgrounds and never write the damn book. Aspiring musicians spend thousands collecting instruments and never make a song.
As you say, if it's just for fun, that's all fine. But if the satisfaction you want comes from the result of the thing, you have to do the thing.
Thank you for shaking me once more .....
"Everybody wants to be a bodybuilder but nobody wants to lift no heavy ass weights!"
"Ain't nuttin but a peanut"
in short learn by doing.
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"?
TLDR: "Just do it." ~ Nike
[flagged]
> 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.
People sometimes do things because they enjoy doing them, even if they aren’t particularly good at them.
I have two problems with that. One is, you can do what you like quietly and without disturbing anyone around you. Second is the Dunning Kruger effect: witnessing it first hand is never fun.
And both of those problems are yours, not your neighbor’s.
To your neighbor, doing it badly is still doing the thing.
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.
Yeah the dude should have stopped doing what he liked
Well you are pretty bad at comments. Hang up the keyboard bud
no, theres a different thing here, which is that practice needs yo be deliberate.
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
Maybe people did tell him he sucked, but he was having fun
Just let people be.