views:

264

answers:

5

While I'm not a bad programmer (well, err, by MY standards :D), I'm never really content with the code I produce. I always think about better ways to solve this or that problem, I search the Internet for similar problems, read books etc.. While this improves my coding and is fun, it consumes far more time I have at my disposal.

Sometimes, after a week or two (sometimes even a year) I look at some older code and am impressed how good it actually was (while I received it lackluster at the time of creation).

Is it just me or are you facing similar problems? Is this tied to programming in general or may it be some sort of mental problem?

+3  A: 

I know that problem from myself. The easiest solution is to just be done with the code: Once it passes all its tests (and satisfies all requirements), mark it done in your head. Then you may revisit it after one or two weeks. This will fix the problem with perceiving it as better after some time. Refactoring is a good thing in itself, but you shouldn't do too much, especially when you're writing the code in the first place.

OregonGhost
+9  A: 

I think perfectionism is a mental trait that is closely linked to the kind of formal thinking and attention to detail that makes people good programmers and interested in programming. As such, it is indirectly tied to programming in general, and the problems caused by excessive perfectionism are very commonly seen in programming projects:

Michael Borgwardt
"Not Invented Here Syndrome": This is not only driven by perfection. A self-made component has several advantages: you have full control over the roadmap (extensions and bugfixes); the features match your need exactly; there is as little code to understand as possible; evaluating a ready made module is *very* time consuming; etc...
Dimitri C.
I did write "among other things". The main problem is that people tend to strongly underestimat the *disadvantages* of doing it yourself - in my experience evaluating and learning to use a third-party component is almost always much, *much* less time consuming than rolling your own.
Michael Borgwardt
@Michael: I posted my comment because I've heard the "reinventing-the-wheel" remark a lot, whereas in my opinion there are indeed often strong arguments in favor of the DIY-solution. But you are right, as with all software tasks, it is very easy to underestimate the development cost. It is just not a simple black-and-white issue where the DIY option is a definite NO-NO.
Dimitri C.
@Dimitri: yes, DIY can make sense, but many programmers seem to prefer it instinctually without examining the pros and cons, while far fewer have an instinctive preference for reusing existing solutions. The result is that you see misapplied DIY far more often than you see third-party components used where a DIY would have substantial advantages.
Michael Borgwardt
@Michael: Agreed! :-) Thanks for the clarification.
Dimitri C.
The best argument against DIY is that 3rd party software is tested (by applying it) in real world scenarios, though I agree that there are times when DIY makes perfect sense.
Helper Method
Great answer btw
Helper Method
+1  A: 

I think that it is a mind-set, programmers that stop learning go bad - they get stuck in a way of doing things, get bored and before they know what happened their skills don't pay the bills.

Stay inquisitive - but sometimes you do need to get the job done regardless.

Most good programmers are self-critical and worry that they will be 'found out' - this is a mental driver. Its the ones who have no concerns that are in trouble!

amelvin
+1  A: 

Generally you get past perfection in a business setting very quickly. For every perfectionist messing around with perfectly valid code there are two people who have to make up for it so the project stays on schedule. And they'll hate you for it. But this applies to pretty much any aspect of business and isn't exclusive to coding.

fbcocq
+1  A: 

No, I think that's perfectly normal.

I know I've hacked on code until it's as "pretty" as I can get it and I know I've wasted time doing this well beyond the need to do it.

There are usually multiple solutions for a given programming problem and in that sense it really is an art. As the artist, you're always going to think this and that could be better but you do need to recognise that perfecting every line might not have as big an impact as could putting time into building new things.

I think it's important to note that while I definitely have chunks of old code that make me feel like a genius, there are probably more lurking out there that would make me throw up a little.

We have all written good, bad and ugly code. Anybody who disagrees either spends far too long micro-refactoring or is just a liar.

Oli