Comment by TheAlchemist
13 days ago
"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
This has been my motto for decades, dunno where I picked it up frst.
I think I've reached the "make it fast" bit in my career twice. Most projects are considered as ready after "make it work" =)
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.
I think the problem is that in the current system, the blame is always on the engineer. If you ship something early and it didn't work, then it's your fault because you didn't QA it enough.
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.
1 reply →
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.
And overthinking starts to feel less like diligence and more like avoidance
"When in doubt, use brute force."
> 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.