Hacker News Reader

Comment by ghurtado | Hacker News Reader

>Words you would associate with perfectionism (detail-oriented, accurate, etc.) are usually used with lower-paid and lower-status jobs.

It may surprise you to hear this, but I have encountered a lot of perfectionism (the negative kind) in software development.

I have struggled with perfectionism for essentially all of my life, and I find that the uncertainties of this particular trade (the lack of well established standards and the constant barrage of tool choices, to name two) make this a fertile ground for perfectionism hell.

View on HN

I wouldn't be surprised if software engineering tends to attract perfectionists. Writing code requires a very high level of specificity - you have to think about all the ways that your code might not be perfect or there will inevitably be bugs. Computers are not particularly good at dealing with underspecified goals.

While that's definitely true, there's also a great degree of "many ways to skin the cat."

What I've found is that while engineers will often focus on getting the implementation just right, they will just as often get stuck on murky architectural decisions. All things considered the decision is murky because the alternatives aren't clearly better, so the correct path is "pick one, try it, reflect later" rather than "debate hypotheticals until an impasse."

I've seen many engineers who are good at these murky architectural decisions, and I've also seen otherwise detail oriented engineers lock up a team on the debate around architectural decisions for so long you could have tried both ideas by then.

Interesting point. I suppose that decisive perfectionism is the goal then. This is definitely more difficult when the scale increases, and the time between deciding the path and seeing the results increases.

I've been working on a project involving some highly optimized C++ code, where the smallest architectural mistakes can cause serious slowdown. My architectural strategy thus far has been to 'just try' all of the decent options and then pick which one is the fastest. It's been working out well, but luckily my code is ~1K lines and the cost of doing this is minimal. (fun fact: template classes >> polymorphism in terms of speed, also, cache yo trig functions)

In contrast, I worked on a partial refactor of a fairly large (~150KLOC) code base, and the 'just try it' approach was definitely not an option due to the person-months work required to even make a small dent. That took quite a lot of thinking to figure out a reasonable path forward. And a lot of diagrams...

I think it's about perfectionism in the user experience vs. perfectionism everywhere else. This is the difference between a Steve Jobs-like quality focus and the kind of irrevant perfectionism that often plagues software development.

Getting into programming helped me isolate my perfectionist tendencies. As long as I have something I can obsessively polish, I can relax in other areas of my life.

Reply on news.ycombinator.com