On my life as a developer, I have been in several stages. On the beginning I was mesmerized with what I could do with code. I really thought I was an excellent developer. Until I found out is was only my narrow perception. I started hiding my code, afraid of what others would think. I developed a big personal code ownership. Time taught me I would learn immensely from others opinion and the final result would be much better, if I listen to others. More recently, TDD and books such as “Clean Code”  completely changed my opinion on what great code is.
If you would asked me, on each of those phases, what was the best code I have ever written or what is great code, my answer would be completely different. Changing our mind is not necessarily bad, but never changing it is. If you look back on time and still think exactly the same way, it means you didn’t evolved.
What is great code anyway?
I had many job interviews, more than I would like. I find amusing the myriad of “by the book” questions I get: “What is agile?”; “What was the best code you have ever written?”; “What was the worst code you have ever written?”; “What is great code?” All those questions are great… for a conversation between co-workers on a slow afternoon by the coffee machine, but not for a job interview. First, Google gives you excellent “by the book” answers. Second, a great answer depends on the interviewer’s opinion.
“What is great code?” If I try to enumerate all characteristics I can think off, I end up missing most of them. Most importantly, it depends on one’s opinion and opinions change all the time. I’ve caught many discussions online about what is great code. It is great being proud of the code we produce. Not too proud, or you develop a strong code ownership. Pride is what makes us go the extra mile and improve the status quo.
Great code takes long time to write?
The bad side of trying our best is feel it’s never good enough. “Perfection … may be spelled PARALYSIS” (Winston Churchill). There is always something that could be improved. The line between improving code and wasting time is very blurry.
I worked in a company where there was this guy implementing a simulation system, alone. He took pride on being perfect (his own words). His code had no bugs (his own words). He had been working on it for years and yet no release had been made. No one apart from him had used the system.
Software is supposed to be used or else it is useless. Doesn’t matter how good code, design or ideas are, if it’s not used, it has no value. Time taken to write code has nothing to do with its quality.
Great code doesn’t have bugs?
Every code has bugs. When a project is signed off, one of the agreements is the number of bugs the software can have to be considered accepted. KLOC is a quality measurement that means number of bugs per thousand lines of code.
Tests are not a proof the software does not have bugs. Tests are a proof it works to the best of our knowledge.
Legacy systems can have little bugs. The tricky bit is to change it without introducing new ones.
Great code has great value?
Only users can determine the value a system has. Users know nothing about software development. They can spot bugs and bad performance, but not bad code or bad design.
A great software is the one users keep on using because of the added value it brings. It has nothing to do with code quality. Legacy systems can have great value. Why do you think companies keep working on them? Code can look great, but have no value or not work at all.
Best code ever written – now opinion
Once on a job interview I was asked “What is the best code you have ever written?” – “All code I write is awesome, can’t make up my mind”. Imagine saying that on a job interview. I answered not long ago “The best code I have ever written was the code I never wrote”. Have no idea of the interviewer’s first thoughts. Maybe “The code he writes is not that good” or “He is constantly evolving, so his present code will always be better than the one he wrote before”.
I explained saying I payed great attention to understanding the problem up front before writing any code. I would go as far as questioning what I was told. It happened often the real need to be something completely different. In extremes cases, it was not needed at all.
Code you don’t write is code without bugs. It takes no time to understand, test nor maintain. Is highly performant. Last, but not least, doesn’t increase complexity. You can’t get this from any code you write. I’m not the only one thinking this way.
The more complex a system is, the harder it is to maintain, no matter how well design or written. Lehman’s law Increasing Complexity says “complexity increases unless work is done to maintain or reduce it” . When I avoid writing code, due to good analysis, I always do a better job, no matter how excellent the code would have been if I had wrote it.
It is important for the code base to be healthy. In other words, to have great, clean code. The system will be easier to understand and change. Developers enjoy it more. Productivity is higher. Systems change more easily and rapidly, increasing competitiveness of the business.
Simpler systems are easier to understand and change. Nothing makes code simpler than low complexity. Complexity can be kept lower by removing unused features or even better, not adding them on the first place.
A developer’s job is to produce solutions with value for the users. Quality software and code is important, but value is even more. Keep the priorities sorted at all times, it will make you a better software developer.
 “Clean Code”, Robert C. Martin, 2008, Prentice Hall
 The Best Code I Have Ever Written Is No Code At All, Matthew Jones
 “Lehman’s laws of software evolution”, Wikipedia