4 ms·

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

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.

taeric 4y ago
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 4y ago
  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 4y ago
    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.
badtension 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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.
karmakaze 4y ago
The trick is defining a subset of a larger problem that you can solve perfectly--and know what isn't solved for next time.
ChrisMarshallNY 4y ago
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 4y 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.
  - mattgreenrocks 4y ago
    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 4y ago
  How does one practice perfection without succumbing to overoptimistic expectations and the burnout follows?
Jorengarenar 4y ago
>programming is applied mathematics You may want to rethink this one
rulamba 4y ago
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

taeric 4y ago

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 4y ago
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 4y ago
  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.

badtension 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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.

karmakaze 4y ago

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

ChrisMarshallNY 4y ago

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 4y 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.
- mattgreenrocks 4y ago
  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 4y ago
How does one practice perfection without succumbing to overoptimistic expectations and the burnout follows?

Jorengarenar 4y ago

>programming is applied mathematics You may want to rethink this one

rulamba 4y ago

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