Finding passionate developers.

Passionate developers are very easy to find. I'm always puzzled when I hear the perception that they are rare. The only explanation I can offer is that people have preconceived ideas or they artificially restrict their search. Great developers come from all places and in all forms. This diversity may make it challenging to find them, but the Internet brings developers together into a few specific places. Developers congregate on the Internet. We use GitHub, StackOverflow, mailing lists, IRC, and meetups to communicate and learn. Learning is critical, the importance cannot be understated. Passionate developers are passionate learners; we all want to learn, but not be recruited.

Understand first.

My favorite habit from the 7 Habits of Highly Effective People is, "Seek first to understand, then to be understood". Taking the necessary time to humbly enter into a new world, to learn and to understand is the easiest path to success. That is a universal truth, but passionate developers, as individuals, are different than most others. I don't mean unique, just different. Especially when compared to the average person. Passionate developers are a group of people who devote hours through nights and weekends, discuss and experiment the latest programming languages, techniques, operating systems, and hardware. It is a dedication to the craft that extends far beyond working hours.

To begin to understand simply set aside an hour of time to begin to learn and understand. In this hour explore GitHub. Focus on the people behind the projects, read the issues and pull requests (pull requests are code changes). GitHub makes this trivially easy. Read how they respond to issues and to others. Are they prompt, or do they let things sit idle, or talk condescendingly? After that, do the same thing with StackOverflow. Write down names, map to projects they work on, identify languages they tend to use. Find people in your area that seem very helpful, knowledgeable, and generally nice.

If a developer can say why they're not participating, it's ok to let an issue sit. Ignoring issues is a bad sign.

If a developer can say why they're not participating, it's ok to let an issue sit. Ignoring issues is a bad sign.

Chat before recruiting.

Most developers, regardless of quality, have jobs (it's a good market for the time being). Passionate developers tend to have jobs they enjoy. When asked about an exciting new opportunity for a venture-backed change-the-world startup, they reply with the delete key.

However, when asked what they're interested in most will love to talk. Invite them to coffee to talk about their projects. Preferably craft an invitation that shows a bit of research, and maybe even some questions. Make sure to have some questions about their opinions about technology. Ask why someone would choose Ruby over PHP, or what separates Scala from Java (you should know these terms by now!). Ask good questions and just listen. Don't recruit.

If you like learning about technology, this will be a lot of fun. If you don't like learning about technology, you probably shouldn't be finding great developers. There is nothing wrong with partnering with a consulting firm. But even a great, interesting and informative conversation won't likely lead directly to that person joining your team. If you have a great conversation, that person will know, and refer, people who will. 

After this, if all goes well, you will be known as someone who genuinely wants to learn about the craft. This will be a distinct and powerful advantage. Trying to get someone interested in a job comes after being interested in them. At the very least, this exercise should prevent job listings requiring 8 years of iOS experience (this is a joke,  you should invite a developer for coffee and ask them to explain it!)

Show appreciation!

Express thanks and gratitude, even if you bought the coffee. Then watch how they respond. I'm fortunate to have met and worked alongside a lot of really great developers, and without exception they are all gracious people. Some of them may lack other social graces but they are all polite. When I am interviewing a candidate I always make a note, and every great candidate has expressed gratitude and appreciation. It's only reasonable and right to show this behavior to them as well.

Find the other interests.

Another thing I've found that has served me well is to find the other interest. Aside from technology, there is some other subject that passionate people throw themselves into. John Resig, the creator of jQuery, loves Japanese woodblock prints. The best developer I know taught himself Japanese, and another knows more about shoes than I thought a human could (or would ever want to).

It's less important to learn about the side interests and more important to simply discover it. Talk to them and see how they light up. The passion they have for this in most cases will match building software products. Passion is a personality trait, not specific to any topic; neither is it always presented through visible excitement. This will give you another gauge of who that person really is. Knowing the person is more important than their skills. They may be amazing, but inconsistent and unreliable. Learning about their other interests is the gateway to better understanding.

Reject traditional ideas of what a developer is.

Software development is a very interesting field. It's part craft, part art, and part engineering. Various aspects are more skewed in other ways, but I've yet to encounter any other profession that allows such a breadth of skills. Because of this, I believe many traditional ideas about what makes a good employee don't apply.

Experience doesn't always matter.

One of the great things about developers is that the capability to produce defect-free code quickly doesn't correlate to years of experience or even what college they went to. The Coding War Games revealed a 10x gap in performance, measured by defects and time to completion, between worst and best performing developers. Even average to best was a 2.5 times difference!

It was more surprising to see that what did matter wasn't experience or the university. The mindset of the individual, the work environment, and colleagues are what bring out the best developers. Jeff Atwood, founder of StackExchange, has an excellent post on this.

Great people have great goals.

Nearly every amazing developer I've met has a strong, insatiable urge to create. This doesn't mean they're entrepreneurial, though. They may devote huge amounts of energy to open source projects or even volunteer groups. They all want to create, but what they want to create will vary. If you want to attract the best talent, you not only have to understand they want to create and often times this will be outside of the company. It is a requirement to nurture the capacity to create. 

Restricting what people do, writing in clauses that try to claim after-hours work, or forbidding Open Source participation is going to be the most damaging to your hiring process. I'm fully convinced that a company that allows developers more freedom to grow independently will benefit, as those employees become more valuable to the company itself. What I've done on nights and weekends has almost always directly benefited the company's products.

Remote may be better.

Many people I respect and admire don't agree on this, which is fine and everybody has to determine this on their own. Allowing developers to work entirely remote has many perks. I'm a fervent believer in remote work. It does require enough social capital built up amongst the team members to maintain healthy communication.

For best results, this requires either previous working experience, or an introductory period of onsite work where people really get to know one another. That doesn't scale that well, and many companies have simply hired people remote and moved on and done well. Make a deliberate decision about remote work early on, and have guidelines for how remote work works. I recommend reading Remote: Office Not Required and Quiet for more reasonings on why remote work can be good.

A note on gender

I debated about including something about gender. If anybody needs to be told that women can be, and are, amazing developers they probably have a hostile workplace and this is a lost cause. I earnestly hope for a time when this note is entirely unnecessary.

Key takeaways:

Want a real HOWTO? Follow this list and it should work out fine:

  1. Browse the websites programmers hang out on. GitHub or StackOverflow are best.
  2. Create a short list of people who are active and have a suitable personality.
  3. Really get to know their projects and identify what languages and projects they work on.
  4. Invite them to coffee if they're local, if not ask them for a Skype call or Hangout. If remote, find if they have an Amazon Wishlist and buy a book off it.
  5. Engage them in seeking advice and opinions. Not to hire!
  6. Learn about their non-technology interests, identify with them as a person first.
  7. Become known in the community as an interested person who is fun to talk with.
  8. Get referred the best developers around.
  9. Get more developers because birds of a feather flock together.
  10. Build something amazing with amazing people.

Photo Credit to Ben Scholzen, photo of the GitHub offices in San Francisco.

1 Comment