Live data from Hacker News

Doing the thing is doing the thing

softwaredesign.ing

111–120 of 196 posts

Re: Doing the thing is doing the thing

#111

"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.

> 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 exper…

> 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.

Re: Doing the thing is doing the thing

#112

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

I 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.

Re: Doing the thing is doing the thing

#113

[flagged]

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.

Re: Doing the thing is doing the thing

#114

"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.

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 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.

Re: Doing the thing is doing the thing

#115
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.

Re: Doing the thing is doing the thing

#116

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 d…

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.

Re: Doing the thing is doing the thing

#118
post #75
post #61

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…

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

Re: Doing the thing is doing the thing

#120

[flagged]

> 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.

Post reply on HN