It was probably Montesquieu who coined the proto-hacker motto “the best is the mortal enemy of the good”. He was talking about compromises in drafting national constitutions for nascent democracies, of course, but I’ll admit that I do hear his voice when I’m in get-it-done mode and start cutting corners on a project. A working project is better than a gold-plated one.
But what should I do, Monte, when good enough turns out to also be the mortal enemy of the best? I have a DIY coffee roaster that is limping along for years now on a blower box that uses a fan scavenged in anger from an old Dust Buster. Many months ago, I bought a speed-controllable and much snazzier brushless blower fan to replace it, that would solve a number of minor inconveniences with the current design, but which would also require some building and another dive into the crufty old firmware.
So far, I’ve had good enough luck that the roaster will break down from time to time, and I’ll use that as an excuse to fix that part of the system, and maybe even upgrade another as long as I have it apart. But for now, it’s running just fine. I mean, I have to turn the fan on manually, and the new one could be automatic. I have only one speed for the fan, and the new one would be variable. But the roaster roasts, and a constant source of coffee is mission critical in this house. The spice must flow!
Reflecting on this situation, it seems to me that the smart thing to do is work on smoothing the transitions from good enough to best. Like maybe I could prototype up the new fan box without taking the current one apart. Mock up some new driver code on the side while I’m at it?
Maybe Montesquieu was wrong, and the good and the best aren’t opposites after all. Maybe the good enough is just the first step on the path toward the best, and a wise man spends his energy on making the two meet in the middle, or making the transition from one to the other as painless as possible.
Good enough brings us a planet full of life.
https://youtu.be/DZ_T4zMBx6E
Yes, evolution is based on the very principle of “good enough (to reproduce)”. Perfection is a very human concept that seems to stem from our instinctual desire to expend as little energy as possible. If what we did was perfect then we would never have to do it again because it would be “complete”.
Nature has the winning concept: Produce a variation, test its survival/reproducibility, and repeat ad infinitum. Of course, this works because nature has a lot more time than mere chemical entities like ourselves.
We could blame Plato and his concept of the “ideal” as poisoning our conception of the world as it is!
I’d rather blame the world for not being good enough.
I think the line between not good and good enough is more important than the line between good enough and perfect. The crux is knowing where to put that line.
Knowing where to put that line is wisdom because comes from experience (even if it’s not your own).
And require wisdoms because – even in the same project – that line is different for each of us; and over time it’ll shift even for yourself.
E.G. Hacking the hardware and OS of my computer for performance, cost, etc used to be great fun. Now the computer is mission critical and stability is far more important; it needs to just work.
This piece hits home. I used to be a perfectionist, perhaps OCD – ask my therapist about that one. As you can imagine I would rarely “finish” projects. When I did finish projects, I’d realize their minor imperfections and often scrap them before they saw daylight. Looking back some of those were pretty exceptional. Then I became a real corner cutter… but part of that was a study, which I… Never did publish… Anyway.
Now that I’m older, I am acutely aware of the sometimes invalid Pareto suggestion that “20% the effort gets you 80% the way there”. My new approach to hobby work is different then before, mostly because of lifestyle changes. Getting older means less time to focus on one thing.
In an effort to hopefully help someone else in a similar phase of life, probably the most important thing I will share is how I am more conservative with cognitive complexity and focusing on the goal of a project. Having to write less notes, often none, I can pick up and drop projects quickly and choose the type of fun I want when Saturday comes. Dropping complexity also means crossing the finish line more. If the goal of a project is to play with a new way to configure something, I will not spend any time building a great case for it – unless that becomes a fun project to do.
Goals can be staged too like the article mentions. What I found surprising was how often I was only interested in a small piece of something and had nerd sniped myself into trying to build a larger effort which included that tiny piece to give it context. This was less fun and projects would lay about unfinished. Why do 95% unfun things for nothing other then to say “I did”?
An important addendum for me is also learning not to give 1 moments notice to what someone else may think of something. Most hacks are closer to art then engineering. Nerd cred. regularly has negative hidden value. Especially among nice people. Most of my projects are not shared publicly. What I do share is often just a thought or concept, and nowhere near a honed project. I owe nothing to an engineer being paid 4 times my salary on the internet copy pasting or borrowing my ideas nor their parent company. If you come over for dinner though we could talk for hours about the shelves of things I have created if you wanted too :).
You may see this as a lack of “discipline”, but the truth is, I have invested a lot of effort to become highly disciplined in spending my short time on Earth how I want too.
Thank you.
On the other hand:
Q: ‘Why do you ‘beat yourself up’ for not getting ‘perfect’ results?’
A: ‘Because I don’t want to go entirely through life, half-assed…(‘like you’ unsaid)’
On the other hand, show the internet a single example of anything “perfect” and await for absolutely non-negative reception and the reasons why you should do it over again :)
Yeah I can condense that down a lot tho I share your “issues”:
1) Just get on with it and get it done. (I’ve quit work to re-discover this passion from youth)
2) Screw other people and their opinions (which is why I never share anything even when praise is heaped upon it)
3) Now you’ve got the time back, revisit anything done under 1.
This guy has some great stuff to say about perfectionism – how it inhibits productivity, and how it can affect mental health.
https://www.thomascurran.co.uk/
I thought the quote was from Voltaire. But hey, let’s not let the perfect be the enemy of the good!
LMWikiTFY
In the English-speaking world the aphorism is commonly attributed to Voltaire, who quoted an Italian proverb in his Questions sur l’Encyclopédie [fr] in 1770: “Il meglio è l’inimico del bene”
Previously, around 1726, in his Pensées, Montesquieu wrote “Le mieux est le mortel ennemi du bien”
Provisorisch ist ein Synonym für Dauerhaft.
Provisional is a synonym for permanent.
Can’t justify major hacking on a coffee roaster.
I will say these are the best comments I’ve read on hackaday in a long time, how do we keep this up?
Hope for good comments.
I made an integration for ESPHome to monitor my Texecom alarm. While debugging, I reduced the polling rate to 0.5Hz, and I still haven’t quite solved the problem of how to Stay arm the panel. Well, I have a solution, which involves using the virtual keyboard to “press the Stay button”, but I haven’t implemented that yet. I know how to, though, just a simple matter of programming.
But the last firmware build for my alarm was 3 years ago, and the sluggish responses irritate me, but not enough to rebuild the firmware, and I get by actually pressing the Stay button on the physical panel, because ESPHome has moved on, and I can’t quite be sure of exactly which git branch holds the latest version that is running right now, and I don’t want to fight with it anymore. I know I’d be happier if I finished it, and adjusted the polling rate to 2Hz, etc, but …
I’ve a similar problem due to not quite finishing a project, my blind controllers with moved to custom firmware and bluetooth to esp, working fine on mqtt.
Then I move to HASS and updated them to ESPEasy, which was far from easy as I had to disassemble to reflash them all, now none of my blinds work.
Now I’m having to debug someone elses code to figure out how to fix them when I should have left them on mqtt and just accepted it wasn’t perfect running mqtt and HASS.
Seeking perfection = fail.
“a working project is better than a gold-plated one”
Should have been: “a working project is better than a gold-plated one that doesn’t work”.
i see a bit of discussion here about starting vs finishing projects and i have an anecdote…
i sometimes have a hard time starting projects. i can get paralyzed at the blank slate because i have to make too many interlinked decisions at once. but generally once i make the core decisions, i can spew an enormous volume of code fairly quickly. and once i have a working prototype, i am easily motivated to clean up the details. though i’m never done with the details because i keep finding things. and i don’t always know when i’m done with the core decisions, because sometimes i’ll get blocked by a decision i didn’t realize was still pending.
but i met a guy who is a bit of the opposite. throws together prototypes very quickly, but has a hard time motivating to finish the details.
and there is a detail about our approaches that i think casts that in a new light. i am very hesitant to use a library…a lot of libraries come with huge nested dependencies that might ‘just work’, but if there is any problem then i will have a hard time ‘getting to the bottom of it’. and often, that work may need to be repeated sporadically as upgrades break the dependencies in unanticipated ways. so if i am trying to do something simple, i will go out of my way to do it anew instead of pulling in something complicated to accomplish a simple task. and if i am trying to do something complicated, i am very judicious in what extraneous complexity i will allow into a project.
but the other guy is the opposite. he is constantly in the process of learning new bloated javascript frameworks. he loves to pull in a ton of dependencies to do the bulk of the work.
there’s real downsides to my approach, because there are tasks i can’t hardly get started on that he can complete in a weekend. but there’s real downsides to his approach, because everything he makes is bloated and slow and buggy.
the interesting distinction is that our different approaches to beginnings/ends of projects are mandated by these tools we use! i like the detail work of finishing off a project because i have done everything leading up to that point with the goal of being ab le to get to the bottom of every problem. and he hates that detail work because he has done everything leading up to that point with the tacit assumption that he will never get to the bottom of anything!
so if he finds some UI quirk in his final draft, he might have to unpack several layers of interdependency just to find the bug. there’s a real material reason he doesn’t like getting the last few details right.