In reading about agile development, I've been struck by the fact that both traditional software development techniques and agile methods rely upon highly skilled developers to ensure success. It's no wonder that there's a focus on the best developers given that it's generally accepted that the level of performance for developers with similar experience can differ by a factor of ten or more. A great deal of development is still done in what is called "hero mode" development, where a developer or a small group of developers essentially will the software into existence through their dedication and tenacity.
So while the evidence is overwhelming that you need good developers, the question remains, where do you get them?
I've been involved with recruiting processes for more than a dozen years and I'll tell you with out a doubt that finding the best developers is possible – but it's not probable. It's a difficult process and even after reading through a thousand resumes you may find only one or two developers who are truly the best.
But when you get right down to it, the best way to acquire the most talented developers for your project is to build them not buy them.
What makes the best developer?
Certainly what makes the best developer is subjective. Both agile and traditional development techniques need something slightly different from the developer. However, to boil what a developer practicing either technique should have down into a word – Thinking.
At the very bottom of Bloom's taxonomy of educational objectives for cognitive skills is knowledge. That is recall (or recognition) of data or information. Applied to development terms this means recognizing the C# syntax or recalling the correct syntax to execute a loop.
At the top of the cognitive taxonomy is synthesis and evaluation. Synthesis is to be able to bring together diverse elements to form a new whole solution. Evaluation is the ability to make judgments about the value of ideas, approaches, or materials. Developers need to consistently apply these higher levels of cognitive ability to effectively perform their work.
Most people find the idea expressed as thinking more natural than describing the difference as cognitive process. In general, the more thinking that is being done about higher level ideas, such as how to integrate pieces to form a solution, the better the developer.
Finding the needle in the haystack
Before giving up completely on hiring (buying) the best developers, let's walk through the hiring process for developers by first examining technical skills. I routinely give a verbal test to candidates I interview for development positions. Since most of the developers that I am interviewing need to be able to operate effectively with a database, I ask them a simple question:
Given a customers table with a customer id field and a name, an order header table with an order id, a customer id, and other details, what query will return a list of customers that have no orders?
The answer requires correct knowledge of an outer join. (In SQL-87 syntax you can use a *= but that answer is getting less common.) My unofficial tally of the number of folks who gets that question right—less than 10 percent. On average, I'm speaking to developers with college degrees and 1-2 years experience. However, my observation is that years of experience has little to do with whether they answer this question correctly or not.
To me, the lack of the ability to answer this question is indicative of a developer who doesn't fully understand the set-based logic that SQL demands. This is a baseline skill that I expect out of good developers.
Another question, which is much more fun because there is no right answer, is:
What is the thing you like most about Microsoft .NET?
Obviously, you can insert any technology you want into the question. The answers are very telling of what the developer is thinking about. If the developer tells me IntelliSense (The Visual Studio feature that helps you remember the interface of objects and methods) I know that they're primarily concerned with getting code into the editor—this isn't the kind of thinking that makes a good developer. By the way, if they give that answer they get a mulligan. (Another shot – i.e. "What else do you like?")
I'm looking for a class of answers that indicates that they're thinking about more than the text editor. I'm looking for something like, "The ability to write flexible code because of the run-time type information." Answers like show a depth of thought about what they are doing that is essential to becoming the best developer.
This question is equally informative when flipped over into "What do you like least?" Answers like forgetting to do semicolons in C# lead me to suspect that the candidate developer doesn't have the right level of thinking about what they're doing. Answers like "The inability to adequately influence the garbage collector," indicate both a level of thinking about what they need from the platform and experience with complex problems.
The results of questions, "What do you like/not like about …" are substantially better than the SQL question, but still depressing. More than 70 percent of the developers I interview are answering with very trivial issues. Another 10 percent or so are answering with responses that either indicate their low-level "get the code in" centric view or a lack of higher level thinking.
The net result is that finding developers—the best developers—is nearly impossible to do. In fact, I've probably only hired two or three people that I would say were some of the best developers when they were hired.
Building a better developer
It is far more common to find developers who have potential; developers who express an inquisitive, learning-based personality. These developers really want to make a difference in their own lives and in the lives of others. They may not understand relational databases yet but they're honestly willing to learn. They bring an enthusiasm to the learning process that energizes the people around them.
In most organizations this enthusiasm is squashed in the name of conformity. A mentality of "We've always done it that way" squeezes out any attempt to try to do things better. As a result developers are often left confused between the statement that the organization wants a world class development team (every organization wants this) and the reality that they're unwilling to change to get there.
However, there are things you can do to ensure that this drive and desire doesn't get squashed out of new developers. Here are a few tips to starting the process of building a better developer.
- Mentoring – Assign a mentor to help the developer. This person should be a senior developer, development leader, or architect who is concerned with improving the team, the processes, and in helping others. This should not be the developer's direct supervisor or manager (if possible). The mentoring conversations should be focused around what the developer wants – not what the organization wants or needs.
- Code reviews – Code reviews are an effective way to move someone's knowledge of development forward in a positive direction. They're done too infrequently in most organizations. In addition they're rarely approached as an opportunity for learning. They are instead an opportunity to bash the developers. Do code reviews and approach them as a way to train and educate rather than to beat down.
- Progressive experience – Provide meaningful incremental assignments for developers to foster their growth. This is perhaps the most difficult tip to implement since we have minimal control on the incoming projects. However, providing as much structure as possible around progressive assignments will pay off in the long run.
- Challenge to learn – In addition to assignments find other ways to appropriately challenge and engage software developers so that they learn as much as possible – even if it's not directly useful. For instance, if you're a Web development shop, encourage developers to learn about Smart Client technologies so that developers formulate a learning character.
Despite the lure of finding developers when you need them for your next project, there are no easy answers. The success of your projects rests largely on the shoulders of the developers on the teams. The better they are the better your chance for success. Finding solid people with the skills and drive you need is necessarily difficult. The only real way to get the developers you need is to develop them yourself.