Don't Be Too Smart

From Programmer 97-things

Jump to: navigation, search

Soo, you are a good programmer? Maybe even a great software developer? You even might be top notch and see yourself as one of the best programmer in your team. But even if you are one of the best programmers in the world this is important.

You are probably given the most difficult problems to solve in your project. After a good night sleep you figure out a cleaver solution. You are very proud of your smart implementation. This is based on advanced mathematic calculation and some recursive call chain. You show this too your team lead and architect and they are really impressed. This makes your self steam even better. The time goes by and suddenly you realize that there is some duplicate implementation in the code base. Another sign could be that someone introduced bugs in your smart solution. Maybe your smart solution is “too smart”? Nobody in your team understands your code!

Is this a good thing?

If you see coding as a competition that you want to win by writing the perfect code you might be on the wrong track. In the real world other programmers will change code initially written by you. Perhaps you moved to another project or another company. You are not there when the code need to change. Another programmer is assigned that task. He/she might not be as smart as you and probably don’t know as much about the initial problem that you did when you wrote the code. If they don’t understand your code they might ask someone before trying to change it. They ask one of the more senior programmers. Nobody wants’ too look stupid and they might end up with guessing rather the actually understanding your code. They totally ruin your “smart” design and this piece of code becomes the most error prone in the system. It ends up with a totally new implementation and you getting a bad reputation.

The solution might be a bit depressing but very pragmatic. You must write code that other programmers understand! Other programmers have to have the possibility to maintain the code base. Discuss your design with others before implementing it. Write clean code and keep it as simple as possible (but not simpler). But some problems are hard to and aren’t solved by junior programmers. Your goal should be to never write code that isn’t understandable for about 50 percent of the team! If a task is assigned to one of the 50 percent that don’t understand your code, he/she has a pretty good chance to find someone to ask! Your code will be live and kicking. People will admire your ability to simplify a difficult problem.

by Mattias Karlsson

Personal tools