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.

In house

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.