The colorful wolf

I've been watching some presentations made by famous programmers / software engineers recently. The thing I noticed most is that all of the really good programmers seem very confident, almost up until the point of arrogance. I think that in programming, the more knowledge you gain, the more you realize how much you really know about programming. And when I say programming, I mean all aspects of it, starting from use-casing through design all the way to implementation. The more you program, the more you know which things you don't know. The amount of uncertainty about your skill level decreases as you get better. One might say that this also holds true for other professions, especially when dealing with the exact sciences, but I think programming in particular stands out as a good example of this. 

Taking pride in your work is very important, also for a programmer. But sometimes there are occassions when there are conflicts with what you want to do and what should be done, or what you think should be done and what the company thinks should be done. These conflicts could be ethical. Perhaps not as world-shocking as Einstein's dilemma concerning the atomic bomb, but just concerning personal ethics instead. A couple of years ago I was working on a program in Java related to networking and web sites. I won't go into details here, but it was the kind of program that went completely against the netiquette. The actual effect of the program was pretty harmless, but it was made with evil intent. In retrospect I think I should not have worked on the program at all, but at the time I was just very happy that I could put all my programming experience to good use. It was a chance for me to develop myself as a professional and I took it. I am no longer in touch with the people I made the program for, but I suspect the idea behind it failed, or perhaps they saw reason. 

That's an example of when personal ethics can conflict with programming. Another example is one that most programmers have faced or will face in the future: the company and you both want something different. Maybe they want you to spend less time on your program design, or they want you to write your program in a different way that, in your opinion, makes less sense than what you think yourself. There's many ways to deal with such a situation. The worst programmers do as they like and defy the company's will, setting up a bad image for themselves. Good programmers know how to balance their own needs and the company's needs, and they will find the perfect compromise. The best programmers just quit and start their own company. 

I'm guilty of over-engineering. I have a 'little baby' in the company and I want to protect it. I can't stand the thought of having a released product that has bugs inside. Every time someone reports a bug I want to fix it as soon as possible. As a consequence, I tend to release less and less frequently because I want things to be perfect before I release, and I end up spending way too much time on a 'perfect' design, when in fact an adequate design will do. Never forget the key rules:

• Release early, release often
• Keep it simple, stupid
• Not every problem needs a perfect solution

I thought of adding a fourth rule to that; "Write all your code to be as generic as possible", but it doesn't to carry the same weight as the other three. Still, the fourth rule is perhaps the one I care about the most. The longer you work at a company, the more you realize that you're actually going to have to maintain the code and the software that you wrote. And that's when you find out just how much every line of code really matters..

Opinions? Comments?