4 ms·

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 abou

by kctess5 10y ago

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.

munchbunny 10y ago
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.
- kctess5 10y ago
  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...
- inimino 10y ago
  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.
splicer 10y ago
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.

by kctess5 10y ago

munchbunny 10y ago

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.

kctess5 10y ago
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...
inimino 10y ago
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.

splicer 10y ago

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.