Not Perfect, Just Better
satfax.substack.comSomething I will add which relates to the examples in the post (gym, business, relationships) is that big things happen with lots of small steps over time. You can't do a years worth of workouts on Jan 1 and be fit for the year. These things take daily effort and cycles of work and recovery to happen.
That desire for perfection can also be a desire to be done. To have it finished and get closure. It's hard to accept that some things are going to take a long time or a lifetime.
Reminds me of a quote from Bojack Horseman I think about quite often (in the show it's in reference to running): "It gets easier. Every day it gets a little easier. But you gotta do it every day. That's the hard part".
I have that quote printed out and hanging in my work room. With the running baboon next to it, smiling, looking at his watch and the sun shining behind him. I've never watched that show, but the quote hits home and was welcome during hard times.
I think it should be more like: "Every day you get faster/stronger/better. But every day will be just as hard as your first day, and you gotta do it every day."
100% with you on this smitec.
It's what I tried to capture in the post, but probably could have put better.
The sense of just taking the steps I can today, rather than burdening myself with the expectation of needing to have worked it all out and achieved all of my comparison-driven life goals.
The key is to find healthy rhythms that help us continue to better ourselves over time.
May I say with all humility and honesty, I used to be what I call a "Christian perfectionist". Without going into a lengthy detail, I came to learn that trying to attain some kind of perfection was just a reason to be competitive and a way to judge others because of my feelings of not being good enough from a faith perspective. I now understand that trying to improve is the only compassionate way, both to myself and others. I explain this to other Christians when the opportunity arises, but it is a hard sell to them because we've been told for a long time how to believe.
I appreciate you sharing this, thank you. Always good to see another believer on HN.
I did similar too. Amongst the dozens of despicable things, one of the precious few good things to come out of a divorce is the new appreciation and deep understanding of God accepting us just as we are. Married or not, perfect or not (mostly not!), guilty or not. He pursues us, loves us, and improves us, slowly, over time.
Glad you found your peace. Indeed, continuous self improvement is the fundamental concept in Christianity, constantly shooting for but never attaining the ideal of Jesus. It is a very difficult concept to teach, and I think most people get lost along the way during their “fake it until you make it” phase.
We are all already fallen. Best to accept and care for it
Would be just better with capital letters.
Or a haiku, there's not much being said there.
i don't know if I'm alone in this, but i find this style easier to read - find it less intense in a way. maybe it's an adaptive thing. maybe i'm just weird.
when i read caps i can almost feel the author's resentment at having had to reach for one of those shift keys and break up their typing rhythm, when without them text can flow so easily.
I find your post and the TFA difficult to read quickly. When I read, I don't consciously read every single word. I depend on recognizing the shapes of words, and the organization of those shapes with respect to each other. Without the normal capitalization, the pattern recognition becomes broken, so it takes longer to read, and causes more stress. I'm sure with enough time and practice, the brain can be trained to read without capitalization. But it is not the norm right now so it's harder.
Ah, I realise that it's a current stylistic trend but I've got to say that I really hate reading all lowercase text.
I find it harder to read and it comes across as the author using a passive aggressive tone where they can't be bothered to form sentences properly.
Probably the best way to describe it is, itwouldbelikesomeonenotbotheringtousespacesandexpectingyoutomakesenseofit. It makes communication harder.
You made me notice I use 'tall letters' as cues when reading, which help me read a little faster. I's seems to be an important letter for me. It took me, maybe, some extra milliseconds to read without them, enough to make me aware of it.
Personally the caps are second nature. You may find me sending U's and O's before you see me sending i's :-)
I sometimes like to read or write all-lower. Oftentimes, for me, it signifies a more casual air, so I tend to do it in text chats more often than not. I find the font and size in the article more annoying than the all-lower, personally -- if it was in HN-style 12pt Verdana, I don't know if I'd have noticed.
You’re probably alone in this.
Yeah. It reads like a 2nd grader's writing. My brain is thinking the author has run the sentences on after the paragraph breaks. Really tough to read.
I am not aiming for perfect, or better. I am no longer aiming. I am reacting to the kinetics of the life I long ago put into motion.
Like Butcher Ding:
When I first began cutting up oxen, all I could see was the ox itself. After three years, I no longer saw the ox as a whole. And now—now I meet it with my spirit and don’t look with my eyes. My senses and conscious awareness have shut down and my spiritual desires take me away. I follow the Heavenly pattern of the ox, thrusting into the big hollows, guiding the knife through the big openings, and adapting my motions to the fixed structure of the ox. In this way, I never touch the smallest ligament or tendon, much less a main joint.
Fascinating quote. It's lovely to see how people can find spirituality and meditative insight even in (seemingly) mundane tasks.
Thanks for sharing!
I'm not entirely disagreeing, but this is a disgusting mindset when applied to mathematics, and programming is applied mathematics. I've seen it so often. The incompetent spend so much of their time dredging up excuses for mediocrity, rather than improving.
I have a completely opposite view. Striving for perfectness can be very toxic and create an environment where growth is impossible if you don't match someones definition of "perfect". It's not about excuses, it's about compromises, making progress, growing in our own pace and being human.
You both make good points.
Striving for perfection is a toxic habit (not just to your team, but to yourself too). However, there's also a category of people that write sloppy/unthoughtful code at the expense of their colleagues. Often times this is just due to inexperience, and we should reach out with advice and mentorship, but also have patience with their pace of improvement.
However, there's also a subset of people who abuse this compassion to get away with being sloppy intentionally (ie lazy). We should be mindful that these people exist, as they also create resentment/contempt, which also creates a toxic work environment.
Can you provide some rough statistics of each group size from your personal experience? Not asking to trap you but I am genuinely interested whether in practice it is useful to focus on the underlying cause.
Intentionally sloppy vs. inexperienced/tired/overworked/ADHD sloppy
Intentionally sloppy is someone I would categorise as being persistent sloppy, and showing no interest in improving themselves, but also a resistance to advice, and/or feedback. It sounds silly, because "who wouldn't wanna improve?", but sometimes they can't tell the difference between saying/wishing it and doing it.
I'd say I probably had a handful of such colleagues out of roughly ~70 devs I've worked with. They were all good people though, and had different reasons for their "sloppyness," but I think it kinda boiled down to being slightly more insecure and egotistical, or self-serving than I'm personally comfortable with (not that I hold it against them; all these traits are gradients). One was very open that he doesn't care about maintenance burden, and couldn't understand why I'm frustrated by the idea of amalgamated hacks. It was just the cost doing business to him. I sometimes think about this attitude and the wonder of I'd be happier by caring less about quality and maintainability than I do right now.
There's other components to all the other kinds you listed, IMO. People who are inexperienced tend to learn from their mistakes and don't repeat them (or at least try not to) once they know better. People who are tired/burnt out also show this indirectly outside of code in different ways. And people with ADHD don't tend to be sloppy in my experience, but they tend to just have a more erratic cadence (depending on how well they can maintain focus), or just be a bit sporadic (ie not get anything done for almost two weeks then have a barrage of PRs on Thursday/Friday).
All of these can be addressed if the person is willing to improve, though.
“I sometimes think about this attitude and the wonder of I'd be happier by caring less about quality and maintainability than I do right now”
Probably. Do they get paid any less than you? At the end of the day it’s your employer that benefits from your commitment to quality, not you. Your employer is also the one paying your colleague, so unless your his/her boss it’s not really you who gets to judge the quality of their work.
Thank you for a detailed response. In my limited experience I don't think I ever met anyone who genuinely didn't give a fuck. Some people were slower than others, some had a "5 pm and I am off" attitude (but without dropping work on others on exit), some were stuck in their old ways of doing things but no one was actually malicious.
Like you said, it is a gradient. We are all a bit different, in my work it was much more beneficial to me and everyone involved to just understand each other honestly, without judgement. That way it is much easier for everyone to find a good path to work happily and grow as people.
Some do not want to improve that much and I still think it's ok as long as it doesn't hinder anyone else's work. They may get switched to simpler and less challenging work over time but there's usually plenty of that to go around.
I'm not sure I'd be comfortable, calling it "disgusting."
It's different from the one I tend to apply, in my own work.
I used to work for a famous Japanese imaging corporation. Their brand was pretty much synonymous with "Quality."
They got that way, by practicing Perfection as a religion. It could be very, very tough, to deal with, but it gave me a great appreciation for a Quality mindset, in my own work.
The result is that even my lash-up, throwaway code, tends to be better than many folks' final release code.
This has great advantages for me. In fact, I just experienced one, a few minutes ago. If the baseline code is of as high Quality as I can possibly make it, then I can avoid lash-ups, or at least, reduce their severity, later. I refactored a fairly complex server interaction timeline, and it was made much easier, because I was pretty damn anal, when I first wrote it, maybe six months ago.
I think this is a good point I didn't convey in my hastily-written-in-10-minutes-blog-post-that-I-didn't-expect-to-reach-the-HN-front-page.
I can fall into perfectionism, but I find this a suboptimal mindset for healthy outcomes.
Excellence seems the far better path.
Keeping a high bar still, but not expecting something that's unreasonable.
Continuing to challenge yourself to get better, but not expecting yourself to have achieved something already that's out of your grasp.
For me it's about trajectory and momentum over perfection.
Aim high, but have compassion for yourself as you push forward.
This is not embracing mediocrity, it is not disengagement, slacking, or merely rejecting perfectionism. It is understanding that the process of growth and improvement exacts a toll, and that growth is not always a pure function of time invested.
How does one practice perfection without succumbing to overoptimistic expectations and the burnout follows?
They use perfection as a target, and any deviation is considered a national emergency. They will have all-day meetings, with screaming matches, over whether or not to release with a known issue.
It is a lot of pressure. Not for the faint of heart. They are demanding as hell. Their testing/QA is crazy. 3,000-line Excel punchlists. If even one item on that list fails, the whole shooting match is sent back.
You can't argue with the results, though. They have been selling very expensive optical gear, for over 100 years, and people base their entire careers on this gear.
That said, I think they are really struggling, these days, and I believe that their conservatism and rigidity play a big part in that.
Mathematics can be applied to programming, for sure. However, much of programming is encoding of business processes. Such that, unless you expand your scope for all business process also being applied mathematics, I'm not sure this is that instructive.
Let's use the linux kernel as an example, since it does very few, well-defined things, and still doesn't work. This comes from an inability to imagine better, an unwillingness to use proper tools, and an attitude that kernel panics be acceptable.
It's fine to solve a vague problem by simply having the machine ask for human direction in a few cases. It's not fine to have the machine do something inappropriate or crash because a valid case wasn't handled in any way.
Everything below these vague areas can, and should, be perfect. People who claim this be an unobtainable goal are liars.
I strongly disagree on this. If you really think nobody working on these problems imagines better, I assert you are being highly insulting to the people working on these problems. Both in the Linux kernel and otherwise.
Successful systems that solve real world problems are not perfect. This works in your favor though, as when you release your project, its perfection will be a great competitive advantage
The trick is defining a subset of a larger problem that you can solve perfectly--and know what isn't solved for next time.
>programming is applied mathematics
You may want to rethink this one