2 ms·

The article is pretty muddled, in large part because they don't seem to really understand what perfectionism is. Their anecdotes aren't really about perfectioni

The article is pretty muddled, in large part because they don't seem to really understand what perfectionism is. Their anecdotes aren't really about perfectionism at all, they're about times when they didn't pay attention to the context they were working in and made poor decisions as a result (usually because of inexperience). In other words, it's not perfectionism that's the productivity killer they've identified, it's inexperience. I'm a perfectionist in the clinical sense. Shipping something that I know is imperfect gives me a high amount of anxiety. But I also have enough experience to avoid wasting my time on things that I now understand don't matter. I don't get anxiety about not having the perfect abstraction anymore, I get anxiety about things like whether we have enough monitoring in place, whether our release plan will cause problems in prod, or whether I considered all the edge cases in this critical piece of security-related code. The perfectionism isn't gone, but it's not really hindering my progress in my career because it's focused on the things that actually matter. I'm working on addressing the anxiety aspects of my perfectionism, but that's a mental health issue, not a software development cycle issue.

nextos 2y ago
I think you have hit the nail on the head, focusing on the wrong things. The problem is that software engineering is still, in many ways, in a pre-scientific era [1]. For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand. In the software field, we don't really know how to proceed in the same way. We have formal methods, but they are quite costly, and therefore not used very often. [1] https://www.di.uminho.pt/~jno/ps/pdbc.pdf https://www.di.uminho.pt/~jno/ps/pdbc.pdf
- godelski 2y ago
  > For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand. And "good enough" is a relative and changing thing. What was "good enough" thousands of years ago is nowhere near standards today. This is even true a hundred or 50 years ago with the specific example of bridges. Engineers learn this the hard way because the results are visibly catastrophic and usually through the loss of many lives. But I think one of the difficulties of software is that failures are often less apparent and can be difficult to accurately attribute. But then again, when a bridge fails there are both internal and independent investigations that are extremely thorough and result in updated policies. This does not seem to be the same in software (at least to nearly the same degree), in part due to the abstracted nature of how software can cause harm. It is actually harder to attribute error (like you said, formal methods exist, but are costly and not just in the monetary sense).
godelski 2y ago
> they're about times when they didn't pay attention to the context they were working in and made poor decisions as a result (usually because of inexperience). I think there is an irony in this because often someone managing a group will accuse them of perfectionism when they themselves do not have the appropriate context to understand that the arguments are really about goodenoughism. I do think this is why companies that are fairly transparent to their employees have been successful. Because it helps them understand the balance and constraints of which they are operating under. To have an environment which is closed and groups are unable to communicate (e.g. in a highly classified setting[0]), the person managing the groups needs to have intimate knowledge of all the pieces coming together, because somewhere along the line someone needs to glue all the puzzle pieces together. So I wouldn't call what you express perfectionism. Perfectionism doesn't really exist because perfection doesn't exist. Rather it sounds like you are detail minded. It also sounds like you've learned to understand what details can (or have to) be ignored, what details can be temporarily ignored but need to be revisited, and to understand that keeping track of details is still important to understand how one needs to improve and mitigate future catastrophes. Obviously there is a balance, but I think this is very different from someone who is trying to turn a map into the territory. [0] I should mention in many classified settings people are still encouraged to communicate and bounce ideas off of one another. Just to do so exclusively in secure areas and to ensure the other person also has the requisite clearance.
- lolinder 2y ago
  To be clear, I literally experience the clinical definition of perfectionism, at a level that is arguably disordered [0]: > the tendency to demand of others or of oneself an extremely high or even flawless level of performance, in excess of what is required by the situation. It is associated with depression, anxiety, eating disorders, and other mental health problems. At my worst, every single mistake I made would give me hours to days of stress and anxiety. I've gotten it much better under control in general, but it still does cause a lot of stress from time to time. This is why I object to people equating "perfectionism" with "being bad at prioritizing truly important work". I'm pretty darn good at prioritizing what's important. I actually perceive wasting time on unimportant work as a mistake, the opposite of perfection, and if I do it and realize my mistake I get stressed about it. Perfectionism is holding yourself (and/or others) to excessively high standards, often met by anxiety or depression when those standards aren't met. The amount of perfectionism someone has is completely orthogonal to the question of how you measure perfection—a perfectionist with a definition of perfection that is well aligned with reality may accomplish a lot while a perfectionist with a definition that's less well aligned ends up wasting a lot of time. And while you're right that perfect doesn't exist, that doesn't stop a perfectionist from pursuing it. [0] https://dictionary.apa.org/perfectionism https://dictionary.apa.org/perfectionism
johnnyanmac 2y ago
> In other words, it's not perfectionism that's the productivity killer they've identified, it's inexperience. experience without growth is just inexperience with more "years of experience". This is pretty much what happens in more technical parts of industry when you have your best workers jumping every year, poor documentation of proprietary tech, and a lack of proper training because you expect "experienced" developers to simply grasp your entire tech stack from day one. You have people falling into the same pitfalls every year (or few months even) and building on a foundation that is not fully understood. Because there is no time to properly understand. Maybe there should be some "perfectionism". Maybe not in shipping "things that actually matter" (as business defines it), but in the boring stuff that keeps a ship afloat. They could also simply give raises to their best workers instead of having them walk, but clearly that's not in the cards.

nextos 2y ago

I think you have hit the nail on the head, focusing on the wrong things. The problem is that software engineering is still, in many ways, in a pre-scientific era [1]. For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand. In the software field, we don't really know how to proceed in the same way. We have formal methods, but they are quite costly, and therefore not used very often. [1] https://www.di.uminho.pt/~jno/ps/pdbc.pdf https://www.di.uminho.pt/~jno/ps/pdbc.pdf

godelski 2y ago
> For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand. And "good enough" is a relative and changing thing. What was "good enough" thousands of years ago is nowhere near standards today. This is even true a hundred or 50 years ago with the specific example of bridges. Engineers learn this the hard way because the results are visibly catastrophic and usually through the loss of many lives. But I think one of the difficulties of software is that failures are often less apparent and can be difficult to accurately attribute. But then again, when a bridge fails there are both internal and independent investigations that are extremely thorough and result in updated policies. This does not seem to be the same in software (at least to nearly the same degree), in part due to the abstracted nature of how software can cause harm. It is actually harder to attribute error (like you said, formal methods exist, but are costly and not just in the monetary sense).

godelski 2y ago

> they're about times when they didn't pay attention to the context they were working in and made poor decisions as a result (usually because of inexperience). I think there is an irony in this because often someone managing a group will accuse them of perfectionism when they themselves do not have the appropriate context to understand that the arguments are really about goodenoughism. I do think this is why companies that are fairly transparent to their employees have been successful. Because it helps them understand the balance and constraints of which they are operating under. To have an environment which is closed and groups are unable to communicate (e.g. in a highly classified setting[0]), the person managing the groups needs to have intimate knowledge of all the pieces coming together, because somewhere along the line someone needs to glue all the puzzle pieces together. So I wouldn't call what you express perfectionism. Perfectionism doesn't really exist because perfection doesn't exist. Rather it sounds like you are detail minded. It also sounds like you've learned to understand what details can (or have to) be ignored, what details can be temporarily ignored but need to be revisited, and to understand that keeping track of details is still important to understand how one needs to improve and mitigate future catastrophes. Obviously there is a balance, but I think this is very different from someone who is trying to turn a map into the territory. [0] I should mention in many classified settings people are still encouraged to communicate and bounce ideas off of one another. Just to do so exclusively in secure areas and to ensure the other person also has the requisite clearance.

lolinder 2y ago
To be clear, I literally experience the clinical definition of perfectionism, at a level that is arguably disordered [0]: > the tendency to demand of others or of oneself an extremely high or even flawless level of performance, in excess of what is required by the situation. It is associated with depression, anxiety, eating disorders, and other mental health problems. At my worst, every single mistake I made would give me hours to days of stress and anxiety. I've gotten it much better under control in general, but it still does cause a lot of stress from time to time. This is why I object to people equating "perfectionism" with "being bad at prioritizing truly important work". I'm pretty darn good at prioritizing what's important. I actually perceive wasting time on unimportant work as a mistake, the opposite of perfection, and if I do it and realize my mistake I get stressed about it. Perfectionism is holding yourself (and/or others) to excessively high standards, often met by anxiety or depression when those standards aren't met. The amount of perfectionism someone has is completely orthogonal to the question of how you measure perfection—a perfectionist with a definition of perfection that is well aligned with reality may accomplish a lot while a perfectionist with a definition that's less well aligned ends up wasting a lot of time. And while you're right that perfect doesn't exist, that doesn't stop a perfectionist from pursuing it. [0] https://dictionary.apa.org/perfectionism https://dictionary.apa.org/perfectionism

johnnyanmac 2y ago

> In other words, it's not perfectionism that's the productivity killer they've identified, it's inexperience. experience without growth is just inexperience with more "years of experience". This is pretty much what happens in more technical parts of industry when you have your best workers jumping every year, poor documentation of proprietary tech, and a lack of proper training because you expect "experienced" developers to simply grasp your entire tech stack from day one. You have people falling into the same pitfalls every year (or few months even) and building on a foundation that is not fully understood. Because there is no time to properly understand. Maybe there should be some "perfectionism". Maybe not in shipping "things that actually matter" (as business defines it), but in the boring stuff that keeps a ship afloat. They could also simply give raises to their best workers instead of having them walk, but clearly that's not in the cards.