Doing the thing is doing the thing
softwaredesign.ing
softwaredesign.ing
This one works for me, and I've learned it from a post on HN. Whenever I feel stuck or overthink how to do something, just do it first - even with all the flaws that I'm already aware of, and if it feels almost painful to do it so badly. Then improve it a bit, then a bit, then before I know it a clear picture start to emerge... Feels like magic.
I learned this the bad way, but now I just lie and say it doesn't work until it's good enough for me
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.
I hate this, but seems to be fairly normal practice.
If you don't ship it in time it's also your fault
This is bound to happen with any company that needs to deliver to clients. Sales are incentivized to sell at all cost, even if the product is not there yet.
Personally I’ve never felt blamed for bugs that made it into production. I’ve felt responsible for sure, but I’ve never been blamed by others in the business. And I have seen sales people utterly chewed out for selling features we haven’t implemented without asking engineering. It all really depends on where you work, and what the culture is like.
If you hate it there, you don’t have to stay. Not every job will be like that.
Got me through many a rough spot.
if youre worried about doing it well, youre a step or two ahead of where you need to be
I think I've reached the "make it fast" bit in my career twice. Most projects are considered as ready after "make it work" =)
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.*
'“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.'
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.
> 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.
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.
[0]: https://strangestloop.io/essays/things-that-arent-doing-the-...
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...
This is a tasteless copy.
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.
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.
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
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.
"Preparation" isn't mentioned explicitly, but by my reading it would come firmly under "is not doing the thing".
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?
Pivoting to zero-planning, would also have a basket of flaws.
From the Red Dwarf book and quoted previously:
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.
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.
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.
1. https://strangestloop.io/essays/things-that-arent-doing-the-...
In the GenAI era, "doing the thing badly without planning" has become so easy that some counterweight is needed.
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.
I needed this today. Currently questioning my career choices, as I hit my first wall where people are involved. Gave me quite the headache.
I 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 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.
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.
For corps: timesheets is one of the things.
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.
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.
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".
“Writing about writer’s block is better than not writing at all.”
I.e. by making sure that they're doing the right thing.
Life is tough like that
Guilty as charged, going back to work.
I like that this was included.
Doing the thing2 is doing the thing2
What do you gain by saying it isn't thing? You have to do it first either way.
I still believe there's a mise en place step before doing the thing, when quality counts.
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.
Corollary: whoever has done something, even "wrong", is 1,000x more valuable as somebody else who is "planning to do it someday".
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.
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.
Edit: Seems like a way to show they’re looking for roles, I guess.
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?
Why not? If i need a saw to build a deck, buying a saw must be the first step?
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.
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.
To your neighbor, doing it badly is still doing the thing.
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
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.