[verisimilitudes]

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.

[badtension]

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.

[spoiler]

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.

[badtension]

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

[spoiler]

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.

[rulamba]

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

[badtension]

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.

[ChrisMarshallNY]

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.

[fredrivett]

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.

[mattgreenrocks]

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.

[Dracophoenix]

How does one practice perfection without succumbing to overoptimistic expectations and the burnout follows?

[ChrisMarshallNY]

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.

[taeric]

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.

[verisimilitudes]

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.

[taeric]

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.

[rulamba]

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

[karmakaze]

The trick is defining a subset of a larger problem that you can solve perfectly--and know what isn't solved for next time.

[Jorengarenar]

>programming is applied mathematics

You may want to rethink this one