I've just finished reading Dan Pupius' Medium article on Software Engineer Traits, where he lays out four characteristics of great software engineers. I agree with his assessment, and want to add one more quality to the discussion -- something I call "should sense".

In a nutshell, "should sense" is that thing which drives a great developer to dig deeper, to not be satisfied with the answers she or he has at hand. It manifests as:

• Should it take this long to read ten gigabytes of data off disk?
• Should we have to reach past the public API of this library to get it to do what we want?
• Should it require fifty lines of hairy code to solve this problem?
• Should this test be failing one in a hundred times?

I don't mean things like "should I add another branch to this long if/else block," or "should I extract this method to share it with the other place that's using it." Those are all questions that good developers ought to be able to answer, and that inexperienced ones can learn how to answer. Refactoring is both a skill and a sense of judgement in its own right (possibly one that deserves its own post). But that's not the kind of "should" I'm talking about here.

What I mean is a gut feel for when something is wrong with a working program. Should sense is associated with, and maybe drives, good habits like questioning assumptions, performance testing, diving deeper, and developing expertise with frameworks and tools. Or perhaps it's that engineers who have those good habits have or are on the road to building their should sense.

It's possible that Dan meant some of these things when he enumerated his four traits. In particular, it seems likely that some portion of "Curiosity" and "Awareness" are touching on some of the ideas I'm mentioning here, even if he doesn't spell it out explicitly.

Jesse Davis, who was kind enough to review an early draft of this post, pointed out that should sense is a lot like what Ira Glass' describes in his essay Taste. He desbribes how artists and creative workers start out with great taste, a sense of what they want to create, but that it takes a lot of hard-won experience to grow their skills to the point where their own work lives up to their taste, to what they know it could be.

In technology, I think the opposite happens: it's fairly easy to get started with programming (especially today in the age of a seemingly infinite number of online tutorials, coding schools, and MOOCs), and at first, the world seems your oyster, as you can make the machines do ever more impressive things. What I think we don't learn until we've fought the hard battles, probably many times, is the technical equivalent of good taste: knowing what your code should look like, and how it should behave.