I don't always hate these, but this one is especially nebulous:

These guys know what they’re doing but seem to be lacking something; somehow, everything they work on seems incomplete.

That's it? Just a vague feeling? A "smell"? In my experience developer smell doesn't correlate with ability.

After reviewing the attributes I identified that make up a great software engineer,

Wait, what attributes? None were enumerated.

I realized that they are in many ways common to all engineers.

Without any attributes, yes I think it's fair to say that for all engineering disciplines, some practitioners have a certain je ne sais quoi.

Car analogies work really well to conversationally describe software applications, but I’m going to use the metaphor of a carpenter to describe our quintessential developer.

Avoiding (but mentioning) the most cliched software analogy in favor of the second most cliched software analogy...

Software is exactly the same - only worse. It’s way easier to type rails superfluous-app than to fire up the saw and cut a piece of wood.

Up to this point no concrete thing has been said about actual software development. I guess that's why he feels safe saying that it is exactly the same as carpentry. However I would disagree that generating a Rails app is way easier than cutting a piece of wood, based purely on the numbers of people who have undertaken such ventures.

The master knows that the best cut is no cut.

This is a trite truism, yet still stands out as the best paragraph in the article.

As with the carpenter, a software engineer can fall anywhere on the skill ladder.

Mixing a ladder metaphor with a carpentry metaphor is daring in any context.

Think about the last time you saw a master at work. Someone that’s just qualified goes through often obvious and intuitive steps to get the end goal. But the masters ways are much more enigmatic, maybe skipping steps or starting with something that seems like it logically belongs at the end.

What does this even mean? What are the "intuitive steps" of software development? There is no such general case. That's what makes software development so interesting and challenging.

That’s how the get-its work. They’ll read a simple feature request and think through the ramifications it has on the whole project.

A programmer who doesn't think through global ramifications is incompetent in the most fundamental sense. The challenge is being able to make a good guess at global ramifications, and architecting systems so global ramifications are minimized. Exploring how great programmers approach those ideas might make a good article, but you'd definitely need some actual case studies or it would end up being just the same puddle of goo that this article is.

Get-its don’t just challenge the products their working on. They also challenge their tools. If it sucks, they build a new one.

Sure, but of course the real question is when does it make sense to take the time to build a new tool, and what qualifies a tool that "sucks".

They’ve got their heads up, listening to other get-its, and are always a little uncomfortable because they understand that the only definite is that something’s about to change. The best of them are the catalyst for that change.

Soo, what makes a great programmer is that they "are the catalyst for change"? This is gobbledygook. What makes a great programmer is that they are solving more problems, more elegantly, with less code, and more resiliency over time. That, in and of itself is pretty banal and hopefully broad enough that most programmers could at least agree that its not un-true, however it still doesn't find itself anywhere near "catalyst for change" which is awfully close to "change for change's sake" for my taste.

I am truly stupider for having read this article.