The Number One Trait of a Great Developer

So I'd go so far as to redefine elegance in software programming and engineering as "simplicity perfected." The simple fact is that where requirements change, a well engineered simple solution will usually turn out to be more agile than a heavily engineered, complex one (whether programmed with "agile" methodologies or not).

When one takes the idea of trying to perfect simplicity in the art of programming (and software engineering), it becomes easier to recognize foot-guns and inherent problems, and tradeoffs often become more conscious and controlled.

So while my view is slightly different from the article, it's difference is perhaps one of nuance rather than substance.

First of all, the story about Jack & Dianne doesn't illustrate much. Why Jack ended up with unmaintainable code and Dianne didn't? And what does it have to do with the tools they've chosen? You can write unmaintainable code in any language.

It sounds like Dianne did a better job of understanding requirements. Okay, fair enough, understanding requirements is important (though I wouldn't call it "judgement"). But requirements change. They always do, that's why software has to be maintained - to reflect changing requirements. Which means that whether the code is maintainable does not depend on the code per se - it depends on how requirements change (unless the code is so bad that it can't be changed at all).

Say, if tomorrow the new requirement is to add a new API to the backend, Dianne's solution is probably more maintainable because it's simpler. But if the new requirement is to scale to 10K users, Dianne's solution might have to be rewritten from scratch, and thus completely unmaintainable.

So, to write maintainable code developer has to anticipate future changes in requirements and make tradeoffs based on those predictions. Now, that's a hard problem, that's where we need judgement and experience. This kind of judgement makes a great developer - mere conservatism in selecting tools and technologies does not.

As seen in a Slashdot sig some time ago, "Light travels faster than sound, which is why some people appear bright until you hear them speak." Unfortunately appearances win to those who cannot understand what is being said.

I think what you are saying sort of agrees with the post. A bad hacker will make a mess, a great hacker exhibits judgement - and brings in new technologies because they are the right solution.

Indeed, the post says nothing about the great developers experience with Sinatra... perhaps it was what she always used. Or perhaps she knew a little about it, and realised it was the most effective tool to use (and therefore used it for the first time).

What the post is talking about is the bad rockstar hacker who doesn't ask the right questions (lacks judgement), trys to over engineer the solution (lacks judgement), uses new technologies for the sake of it (lacks judgement).

I can't embrace a definition of a great developer, where the primary quality is to avoid causing trouble for the company, the project, the team or their boss. That has almost nothing to do with the discipline. You're describing a "great employee" or a "great team player".

The post is talking about the aspects that make a great developer.. working in a company.

I think they are right; they need a developer with the judgement to find out what the company needs, build a solution with effective tools and who has the ability to iterate as the spec develops. All of that ties to having good judgement.

Not someone who gets all enthused with the latest tools and delivers a much more elaborate solution :)

From the perspective of hiring or contracting a new developer someone who doesn't cause trouble in that way is a good thing. Especially as what the post describes is someone who actively produces solutions instead!

Both of those people can push the envelope...