The thing I most worry about using anti-perfectionism arguments is that it begs a vision in the first place—perfectionism requires an idea of what's perfect. Projects suffer from a lack of real hypotheses. Fine, just build. But if you're cutting something important to others by calling it too perfect, can you define the goal (not just the ingredients)? We tend to justify these things by saying, we'll iterate. Much like perfectionism can always be criticized, iteration can theoretically always make a thing better. Iteration is not vision and strategy, it's nearly the reverse, it hedges vision and strategy. This is a slightly different point, but when we say we don't need this extra security or that UX performance, you're setting a ceiling on the people who are passionate about them. Those things really do have limits (no illusions!), but you're not just cutting corners, you're cutting specific corners. That's a company's culture. Being accused of perfectionism justifiably leads to upset that the company doesn't care about security or users. Yeah, maybe it's limited to this one project, but often not.

Perfection can be the enemy of the good. It's that it's not a particularly a helpful critique. To use the article’s concept, it’s the wrong scale. It might be helpful to an individual in a performance review, but it doesn’t say why X is unnecessary in this project or at this company. Little is added to the discussion until I describe X relative to the goal. Perfectionism is indeed good to avoid—it's basically defined as a bad thing by being "too". But the better conversation says how X falls short on certain measuring sticks. At the very least it actually engages X in the X discussion. Perfectionism is more of a critique of the person.

It takes effort to understand the person's idea enough to engage it, but more importantly it takes work that was supposed to (but might not) have gone into developing good projects or goals in the first place. Projects well-formed enough to create constraints for themselves.

I agree with the thesis of this article but I actually think the point would be better made if we switch from talking about optimizing to talking about satisficing[1]. Simply put, satisficing is searching for a solution that meets a particular threshold for acceptability, and then stopping. My personal high-level strategy for success is one of continual iterative satisficing. The iterative part means that once I have met an acceptability criterion, I am free to either move on to something else, or raise my bar for acceptability and search again. I never worry about whether a solution is optimal, though, only if it is good enough. I think that this is what many people are really doing when they say they are "optimizing", but using the term "optimzing" leads to confusion, because satisficing solutions are by definition non-optimal (except by luck), and some people (especially the young, in my experience) seem to feel compelled to actually optimize, leading to unnecessary perfectionism.

Perfectionism is sort of polarizing, and a lot of product manager / CEO types see it as the enemy. In certain contexts it might be, but in others “perfectionism” translates to “building the foundation flawlessly with the downstream dependencies in mind to minimize future tech debt.” Of course, a lot of managers prefer to pretend that tech debt doesn’t exist but that’s just because they don’t think they can pay it off in time before their team gets cut for not producing any value because they were so busy paying off tech debt.

kthejoker2 3 months ago | prev | next [–] Not sure you can talk about perfectionism without clarifying between "healthy" perfectionism and "unhealthy" perfectionism. Both exist, but often people are thinking of one or the other when discussing perfectionism, and it creates cognitive dissonance when two people thinking of the two different modes are singing perfectionism's praises or denouncing its practice.

looking at these comments, it seems perfectionism is ill-defined. it seems to be positive - perfectionism is not giving up, it is excellence, it is beyond mediocre. it also seems to be negative - it is going too far, it is avoiding/procrastinating, it is self-defeating. I wonder what the perfect definition would be?

1. First and foremost: measure early, measure often. It's been said so often and it still needs repeating. In fact, the more you know about performance the easier it can be to fall into the trap of not measuring enough. Measuring will show exactly where you need to focus your efforts. It will also tell you without question whether your work has actually lead to an improvement, and to what degree.2. The easiest way to make things go faster is to do less work. Use a more efficient algorithm, refactor code to eliminate unnecessary operations, move repeated work outside of loops. There are many flavours, but very often the biggest performance boosts are gained by simply solving the same problem through fewer instructions.3. Understand the performance characteristics of your system. Is your application CPU bound, GPU compute bound, memory bound? If you don't know this you could make the code ten times as fast without gaining a single ms because the system is still stuck waiting for a memory transfer. On the flip side, if you know your system is busy waiting for memory, perhaps you can move computations to this spot to leverage this free work? This is particularly important in shader optimizations (latency hiding).4. Solve a different problem! You can very often optimize your program by redefining your problem. Perhaps you are using the optimal algorithm for the problem as defined. But what does the end user really need? Often there are very similar but much easier problems which are equivalent for all practical purposes. Sometimes because the complexity lies in special cases which can be avoided or because there's a cheap approximation which gives sufficient accuracy. This happens especially often in graphics programming where the end goal is often to give an impression that you've calculated something.

Things that eat CPU: iterations, string operations. Things that waste CPU: lock contentions in multi-threaded environments, wait states.