My Code or Someone Else's Code?

Most software developers if given the choice of maintaining their own code or someone else's code, will choose their own. That's unfortunate. Editing other people's code is one of the best things that can happen to a developer. It's a great way to see what works and what doesn't.

Especially early in a career it's not always obvious what practices are best. Fixing problems in ten year old code is very revealing. My own coding style has become simple, spartan, structured and well documented. I didn't code that way in school or early in my career. I learned it as result of many, many hours of maintenance coding.

Working in someone else's code base is also good for the code. As I noted in my previous post, hacking in new code can be a very destructive process. When editing my own code it's very tempting to hack new features because I know where all the easy attachment points are.

It's not nearly as easy to hack in someone else's code without risking nasty side-effects. That forces a full re-evaluation of the code and often significant restructuring. The result is that the code ends up containing the best of both developers.

Coding is Bad For Your Code

There is nothing as destructive to a computer program as a good day of coding. An afternoon can wipe away a week's supply of simplicity and clarity. Gone are the clearly defined functions with well commented logic. In it's place is mess of IF and WHILE logic addressing all those special cases that didn't come up in the initial design.

We all know we "should" refactor. But the clock is a remorseless taskmaster. It's so easy to just hack in the feature we need and "design it better next time". Of course, there is no next time. Only now. There is no "design once, write once". Only design and re-design. Code by design, or hack without one--there is no middle ground.