I've been asked a number of times how to improve the quality of the software developers on my teams. It's an interesting thing to think about. How did I get good (assuming, of course, you think I'm good)? What do I recognize in others that makes them better or worse? Are good developers' qualities intrinsic or learned? It's naive to think that simply knowing more C# or WCF makes you a better developer. Surely pure knowledge is critical, but knowledge alone does not make a good developer.
For example, I worked with a guy who seemed to know all the compiler switches by heart. I was stunned and assumed this guy must be a rock star. However, it turned out he couldn't get any work done and was an anchor to the team instead of an engine. Joel Spolsky also summed it up well: "Smart and gets things done". This guy had only the first half. As another example, I've worked with people who were experts in their subject area, but simply could not take a step back, reframe the problem, or look at the big picture. Here, I think Einstein said it well: "The gift of fantasy has meant more to me than my talent for absorbing positive knowledge."
So following are my [unscientific and opinionated] thoughts and extensions on these premises about what it takes to become a good developer.
Analytic
I think being analytic is core. When you get down to it, the process of developing business software is essentially taking the chaos of human beings' work and turning it into logical code that automates that work. There's no way to do this other than through decompositional analysis of large problems into smaller problems and into yet smaller problems that can be logically handled in code statements. It was an clever analyst who quipped, "How do you eat an elephant? One bite at a time." A developer's job is determining a good first bite, and second bite, and so on until the elephant is eaten.
But the analytic quality doesn't end with being able to decompose business problems. A good developer must be able to make good analytic decisions, evaluating the pros and cons of different options. If one line of reasoning leads to a certain dead-end, it's foolish to keep trying that approach. But it's equally foolish to prematurely determine the situation is a dead-end. What if the developer's knowledge had simply been maxed out, and there was actually an approach the developer didn't know? Knowing when to move on, when to ask for help, when to keep digging - these are more intuitive facets of analysis that are equally important.
Creative
Some people who don't know anything about software engineering, who view it as some form of technical wizardry, often think it must be dry stuff. Programmers simply fill their heads with bits and bytes and gotos and gosubs, and through proper application of magic/engineering, produce software. I have to break it to these people, creativity is essential to being a good developer. Without creativity, a developer is locked into rigid, narrow thinking. On a recent project, I saw a legacy database where I could just imagine the conversation that occurred prior to implementation. Lead Developer said to someone, "Set up the new tables with a unique ID." The outcome? Each new table has a column named "uniqueid." Ugh. (And for the morbidly curious, no, primary key constraints were not in place.)
The creative mind nimbly and constantly changes focus from the details to the generalities, to the future and back to the present, from fantasy to reality. It asks "why?" a lot. It considers the business implication of a technical decision and the technical implication of a business decision. It is not constrained by precedent or mandates and thirsts for inventing new and better ways of doing things. As much as analysis, creation is foundation of the development process, and the stronger these skills are, generally, the better the developer.
Honest
I think honesty is a big deal. More than anything, good developers must be honest with themselves, and then in turn be honest with their colleagues. I think the first and essential thing to admit is you can't know everything. If you think you do know everything, or that you "should," you're not being honest. As technology advances, it's non-linearly harder to keep up with it. You are one person, and the whole of technology is driven by a growing global brain trust. Keeping pace is a more intractable challenge every morning. Admit to yourself what you do and don't know, and honestly commit to learning something new from time to time. You can expect no more.
The other aspect of honesty to me is summed up as "Don't talk s***." I've met more folks than I can count in this field who (because I think they're not honest with themselves) refuse to say "I don't know" in response to a question. I've never understood this, and I guess it's some form of machismo. Some of these s***-talkers are really good at it, i.e. they are assertive and convincing, and it takes a while to learn that what they just spewed was just that: spew. My advice to them is to learn "I don't know." Say it a lot, because there is a lot you don't know. If nothing else, consider the damage done to the business because you wouldn't admit ignorance, yet you asserted something anyway, and people wasted time doing the wrong thing. If you're in a situation, say in front of a client, where "I don't know" is a politically poor response, try "let me get back to you on that."
Disciplined
I've heard "developer discipline" called an oxymoron. Sadly, I think this may be true in general. There's something about the left-brainedness of the analytic and the right-brainedness of the creative that tends to lead to scruffy-brainedness, which is to say, undisciplined. Not all is lost though: discipline can be learned. I'm a bit lucky in that my college education was in English, and across the board, my professors were sticklers. One-inch margins, double-spaced, MLA-formatted, no spelling or grammatical errors. I learned discipline in writing because it was required to get As.
Professionally, I have habits, maybe even reflexes or twitches. These are intentional habits, such as formatting code (Ctrl-K, Ctrl-D *twitch*), consistent naming, letting people know about breaking-changes, asking/understanding before coding. I find that creating habits helps me be disciplined, since I'm prone to forgetting to be disciplined. Some discipline can be aided by tools (I'm looking at you, ReSharper), but some require a change in habit. I've heard various numbers on how long it takes to form a habit, somewhere between 10-30 regular repetitions. That's not really a lot of effort to move a good behavior from conscious to unconscious.
Inquisitive
Good developers ask a lot of questions. When they don't know, they ask "how can I find out?" When someone gives them vague requirements, they ask a barrage of follow-ups until the requirements are clear in their minds. Conversely, a weak developer takes vague requirements and writes vague code, code that's a partial solution or that's buggy, ignorant of a whole array of use cases. It's important the questions asked are on target, so I'm assuming the developer is a good listener and capable analyst. If those are in place, there's no such thing as a bad question. In fact, I find most SMEs love (and I mean love) to talk about their subject of expertise. If you're getting it, they'll keep talking and thank you for the result.
Inquisitiveness also leads to research and play. Someone gave me the words "recreational programming" many years ago, which I thought was great. I wrote code in my free time (utility apps and games) because I loved writing code, and suddenly I had professional-sounding words for it. I always want to find out more. I got the beta-bits of .NET in 2000 and started messing with .NET Terrarium. I wrapped some System.Net classes into simplified packet-handlers for a business idea I had that required networking. I wrote a Mancala-playing program to explore AI and GDI+. Inquisitive people love to learn.
Developer Psychology
So what I've set forth is a brief essay on developer psychology. Entirely my own opinion, but based on a number of years of professional development and a decent breadth of experience. I think most of the good qualities I described above are able to be learned, though if you happen to have them natively, you're better off. Creativity, especially, seems hard to learn, though I don't see why a determined person couldn't set some creative exercises for themselves. The Dr. Ecco series is full of fun programming problems to stretch your brain. Discipline seems a close second on difficulty, but without it, you'll never be more than a hack, so start training up some habits.
If ever a college motto applied to what I think makes strong developers, it was my alma mater: non satis scire.
