I spend most of my days designing and writing software. I actually get paid to do this. That makes me a professional. And as a professional my job as a developer is evaluated at least once per year in what is affectionately known as an annual performance review. Much to your potential dismay, I'm not writing about human resources nor the performance review paradigm at Microsoft. There are plenty of other passionate people to tackle those problems. This is a post about the very essence of being great.

When I first thought about this question -- what makes a great developer? -- I started to draw a mental map of associative attributes. Well, that's not entirely accurate. I actually started off by thinking about all the great developers that I knew and tried to reason why they're great. The first problem was that I don't really know that many great developers. Now there are plenty of unbelievably talented and intelligent people at Microsoft. There's no question about that. The problem was not with the developers but rather with the definition of great. This was probably the wrong way to go about this question since I ended up with a list of meaningless attributes:

• They understand the difference between covariance and contravariance.
• They use phrases such as referential transparency and idempotent in daily speech.
• They can quickly and seemingly effortlessly point holes in designs and implementation.
• They rarely execute code to see "if it works" but rather just write code that just works.
  

In essence, it was my understanding that great developers write great code. These days I'm not so sure. I suppose it is almost self-evident that great developers write great code. But I think I have willfully found this to be untrue. Great developers write solid code. It's not great but it works. In fact, I can often times find various problems with code written by great developers. This is not because I am a great(er) developer. I'm far from it. It's actually because I operate at the implementation level. This is suboptimal. The greatest developers operate at a conceptual level. The distinction may be subtle but it's impact is unquestionably vital.

In other words, although the code may not be optimal from an implementation perspective, the overarching solution -- from a great developer -- more closely maps to and reflects the conceptual problem domain. The implementation can always be improved or optimized (here, optimization is not necessarily a function of performance but likely completeness, correctness, conciseness and clarity). However, the design and problem solving approach provides unparalleled longevity and code quality. It becomes in many ways invisible.

Yes, great code is often code that you don't see or even think about. It's code that feels and operates naturally as part of the problem domain. It is either well encapsulated from predicted variation or it is seamlessly open for extension to satisfy new requirements. In many respects, great code goes unnoticed and unappreciated. We take great code for granted. This is likely why you get groans and mumbles when you ask any developer what they think of their existing codebase. It's not just because the entire codebase is poorly written, poorly architected or poorly documented. It's predominately because that's the only part of the codebase they are actively thinking about or forced to think about. Writing great code is a thankless job.

Next time you sit down to design a feature, a class or even just a sub-component: think about the abstraction you are providing and how to make it invisible. This is of course difficult and according to some virtually impossible. Nobody said that being a great developer was easy. Now, I know I certainly have not stated anything revolutionary or extraordinary here. You could even argue that I've simply restated the obvious: design is likely one of, if not the, most important part of the development process. But it's not the greatest developers that write the greatest code; they architect simple solutions to complex problems. Their simplicity often camouflages their natural ingenuity and, they are, consequently considered merely self-evident.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare

Adieu. Navid.