Excellent Developers Are the Best Hires

7 comments:
I recently read a post wherein the author was condoning the hire of excellent programmers with abrasive personalities over bad programmers with cordial personalities. Superficially, I agree with this advice as it is ultimately better to have an individual who does their job well and delivers over an individual who you get along with very well, but who cannot produce.

A false dichotomy

The notion that you must choose between great developers with bad personalities or bad developers with great personalities is just plain false. The dynamics involved are far more complex than that, but let's assume for a brief moment, that there are only two criteria any company hires on; raw skill and congeniality.

The author posits that most companies do not have the luxury of hiring based on both skill and personality. He suggests Google has this luxury and yet they are always looking for good developers. His conclusion is that there are too few developers who are both excellent at the craft and reasonably compatible with the rest of the human race. I submit that perhaps Google's growth rate has contributed to their continual search for developers. I haven't any idea what their turnover rate is, but I do expect it also contributes to the demand.

Let's not forget there are far more developers in the middle of this continuum than on either end-point. I would surmise the majority of developers fall somewhere comfortably in the middle; decent developers with decent personalities. Neither excellent nor awful. Neither completely congenial nor damagingly dissonant. The choice between only the two extremes is invalid.

What makes for an excellent developer?

What are the criteria for excellence when it comes to developers? If we agree that a developer's role is ultimately the consistent delivery of software, then what atributes do we expect an excellent developer to have?

I think there are many facets to what a developer does, but I think we can all agree on three things an excellent developer must be; Knowledgable, Skilled, and Efficient.
Knowledgable
An excellent developer is certainly knowledgable.

Knowing not only a particular language, but multiple languages. An excellent developer knows that the idioms, extractions, and constructs of one language enrich their ability to write code in all languages.

An excellent developer knows that they are not an expert in all languages they use; perhaps (and most likely) in none. An excellent developer knows there is always more to learn. An excellent developer knows lessons can come from anywhere, not only from those they hold in high regard.

An excellent developer is knowledgable in the business domain. An excellent developer can speak with others about the problem at hand in terms everyone is familiar with. An excellent developer knows they should not make unilateral decisions, should not accept decisions from others made in isolation, and should not expect all decisions to be made by committee.
Skilled
Equipped with the knowledge there is always more to learn and always room for improvement, an excellent developer hones their skills. An excellent developer practices their craft. Not just working the same problem with the same tools day in and day out, but working different problems with different tools simply for the pleasure of learning.

An excellent developer does not wait for their employer to approve the budget and time off. An excellent developer takes the initiative and attends conferences, user groups, and weekend gatherings where other practitioners talk, share, and practice.

An excellent developer practices because they want to. An excellent developer improves themselves a little bit every day.
Efficient
For an excellent developer, efficiency is more than writing code quickly. Efficiency is writing code that is easy to maintain in the future. For an excellent developer, efficiency is writing only the code you need today without sacrificing the ability to make alterations tomorrow.

Efficiency is working in a manner that allows any developer on the team to pick up precisely where you left off and see the work to completion.

Excellence Precludes Unsociability

Excellence requires knowledge, skill, and efficiency.

Knowledge requires open mindedness in that one considers what multiple languages have to offer and recognizes that lessons can come from anywhere.

Knowledge requires humility in that one knows they are not expert in all tools they use and that lessons can come from anyone, regardless of status.

Skill requires discipline and commitment in that one must apply themselves not only at work, but outside of work as well; in divergent skills and tools.

Skill requires initiative. An excellent developer does not wait for training to be scheduled and budgets to be approved.

Skill requires social interaction for the best lessons come from the social interaction we have with other developers at conferences, user groups, and weekend events.

Efficiency requires wisdom. The wisdom to know what to build and what not to build. The wisdom to know when the extra effort today is worth the payout of tomorrow and when "good enough" really is.

Efficiency requires teamwork. Developers working in groups, covering each other's back, and sharing ideas as the solutions unfold before them.

If an excellent developer is knowledgable, skilled, and efficient, then an excellent developer is open-minded, humble, disciplined, committed, initiative taking, socially engaged, wise, and team-oriented.

It is, therefor, impossible to hire an excellent developer who has a bad personality.

Roshambo Estimating

No comments:
This is a quick post. I just want to share a technique we've been using for initial story estimating. I first used this technique at ThoughtWorks when we were working on a project that required a lot of estimating. I think it came about because 1) we did not have any estimating cards immediately available and 2) that is the kind of place ThoughtWorks is. I later came to discover that the technique is not only fun, but it actually has a few additional benefits.

My recall is fuzzy, but I believe it was Greg "Hippie" Warren who first suggested it. As many of you know, Robshambo has a bit of a tradition at ThoughtWorks (not normally associated with estimating), so it just seemed natural.

How it works

Set-Up
Roshambo Estimating requires no special equipment, only your hands and some partners.

When estimating a story, get a brief overview of the story and acceptance criteria. Ask whatever high-level questions come to mind in order to get a good general sense of the effort required. Do not try to nail down every last detail. It is perfectly acceptable to make some assumptions or leave some unknowns.

Any team member may ask for an estimate at any time. When the team is comfortable giving a rough estimate, throwing may commence.
Throwing
Each team member begins with one hand balled into a fist and resting on the open palm of their other hand. One team member counts to three. At the counts of one and two, team members bang their balled fists into the palm of the open hand. On the three count, all team members "throw" their estimates. Estimates are represented by the number of fingers showing on your hand.

I prefer a Fibonacci sequence as it appropriately represents the proportionality between estimate size and accuracy. So, for the teams I work with, we usually throw a 1, 2, 3, 5 or a thumb.


A throw of 1, 2, 3, or 5 indicates the point estimate for the story. A throw of thumb indicates the story is too large to estimate on one hand.
Evaluation
If the throws are all the same, you have your estimate; move on to the next story.

If there is a significant discrepancy, provide each of the outliers an opportunity to briefly explain their thinking. The team then decides to estimate again or continue discussion. If discussion continues, any team member may ask for an estimate at any time. When the team is comfortable giving a new estimate, throwing may commence. 

Typically, the discrepancy is small. Half the team throws a 2 and half the team throws a 3. A quick discussion should resolve this. Often the low estimates round up and the team moves on.

So... what makes this better?

This is not significantly different than a number of other estimating techniques already floating around. So why adopt this one?

In my experience, I've found this to be the fastest and most efficient way to do estimates without sacrificing the quality of the estimates. It can be done at any time, any place. No extra materials required. There is no shuffling of cards, no cheating, no anchoring.

The idea is to get to an estimate quickly and to put primary focus on stories that have discrepancies, therefor requiring more discussion.

It is fun and it looks silly.

This technique implicitly mandates that no stories can be larger than a 5. I recognize every team has their own set of practices around story sizing, but it has been my experience that estimates larger than 5 are significantly less reliable. Effectively, there is minuscule discernible difference between an 8 and a 13 in terms of actual effort required to complete. If I had my way, no stories could be larger than a 3; at which point, we don't need to estimate and can just count cards. - but that is another post for another day.