121–130 of 196 posts
[flagged]
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.
Why not? If i need a saw to build a deck, buying a saw must be the first step?
[flagged]
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."
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.
Earlier quoted context omitted.
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…
I hate this, but seems to be fairly normal practice.
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…
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.
[flagged]
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…
Not sure about this user specifically, but interesting that a lot of their comments follow a pattern of ' nailed it'
[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.
"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.
The essay is quite similar to this one from strangestloop.io[0] [0]: https://strangestloop.io/essays/things-that-arent-doing-the-...