In a code review, the lower the number of WTFs/minute is as good a metric as any other. The highlighting in the quote below is mine.
Which appears facetious at first, but perhaps hints at a deeper truth: high quality code should not surprise us; we should be able to quickly and easily discern the structure and intent of the code. But doesn’t this then place software quality in the eyes of the beholder? What if the person evaluating the code isn’t familiar with the patterns used by the original developer? (Or – to be more cruel – what if they just aren’t competent enough to recognize the patterns used?) Are they not likely to harshly judge the code based on miscomprehension? (A similar suggestion to this measure is that software quality is inversely related to the amount of time required to make a modification; again the major problem with this is that it depends on the capability of the person making the change).
On Code Quality « SourceForge.net: Project ogsa-dai
Too many developers are overly impressed with their own cleverness. I’ve found this more often in “classically trained” developers than self-taught developers, and I’ve found it in myself, too. Regardless the source, resist the temptation to implement cleverly… you’ll wind up writing bugs you can’t fix. Ask me how I know. Heh.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
"The Elements of Programming Style", 2nd edition, chapter 2, by Brian Kernighan
Not a good plan. A better plan (to paraphrase Einstein) is to write the simplest code possible, but no simpler.
When I have been a hiring manager in previous work lives, the question frequently came up: Is it better to hire a few rock stars (aka prima donnas) or a few more really competent people who know how to play well with others? In many software engineering circles, the conundrum is known as the Myth of the Heroic Programmer.
It’s always nice to see someone with quantitative research that backs up and validates the decisions that you’ve made in the past, and help to inform similar decisions that you’ll make in the future.
For the answer to that question, we don’t have to rely on hunches, or instincts, or a handful of individual cases. It turns out that some careful research has been done on this point. Data were gathered from a wide range of companies in an effort to settle the question of which is more important in generating superior performance: teamwork, or "stars?" The answer, hands down, turned out to be teamwork.
Caseplace: Teams, Not Stars, Are the Key to High Performance
Of course, if you can hire rock stars who are great team players, that’s the best of both worlds! However, in my experience, the personalities who gravitate toward building a “star brand” for themselves are generally the antithesis of team players. C’est la guerre.
I’m looking forward to growing Glacier Peak and adding quality team members to the mix, because there is nothing more satisfying than results that a small group of talented and highly motivated people can produce who are kicking ass, taking names and producing great products together.