During the dot-com boom of the late 90’s, much ado was made about the many perks offered by companies used to attract developers: ping pong and pool tables, catered lunches, video game rooms, alcohol, sign-on bonuses, and oh yeah, stock options! Today, some of those perks are just running gags, but others have become standard to the modern tech company.
A lot has changed in the past fifteen years, but not the need for good developers. The big companies still offer all the crazy benefits to attract top talent (just think of every story you’ve heard about what it’s like to work at Google), and sometimes they just buy companies to acquire the developers therein.
For the sake of argument, let’s assume you represent a smallish company which has established itself to some degree and you’re looking to bring on new developers - and by “new developers”, I mean developers who care about the work they produce (i.e. hackers). With so much demand for these developers, how do you compete?
It should come as no surprise that the first thing you must do is to understand how developers think. We’re a different lot. We don’t stop working just because we’ve left the office; we hack on our own projects, we do side work for more experience, and we attend user groups and contribute back to our technical communities. We live and breathe technology; it’s who we are. Understand this, and you’re halfway there. Learn to encourage this in us, and you’re home free.
Attracting developer interest really isn’t hard, it just requires putting your name and support behind what we’re interested in. Here’s just a sample of things you can do:
Although developers are generally thought to be introverts, we do enjoy getting together to share ideas and new technologies. One of the ways we do this is by going to user groups, and companies which support user groups are generally seen in a favorable light.
Supporting user groups is cheap and easy. The simplest, and possibly the most appreciated, thing you can do is provide snacks, food, and/or beverages. It doesn’t have to be extravagant, snack trays, pizza, sandwiches, or soda is good enough.
Another way you can support local groups is by providing a place to meet. It’s not easy to find a meeting place once a group begins to grow, and providing that meeting spot will be greatly appreciated. What better way to get your name out there and scout new talent than to open your offices to these groups?
One last thing about user groups, they oftentimes need speakers, so encourage (don’t coerce) your own developers to speak.
Not only do developers get together to discuss technologies, we get together to play too. Most languages have some sort of competition (Rails Rumble, Node Knockout, Django Dash, etc.); major open source projects often have bugmashes leading up to new releases; and new projects or releases may announce hackathons to build excitement in a product or release.
Support for these sort of events is similar to supporting user groups. Providing snacks and beverages, a place to meet, and your developers would all be welcomed. Your support and name will be remembered.
Unlike user groups and hackathons, involvement in technology conferences requires a greater investment in money, time, resources, or a combination therein. With the increased expenses, however, comes an increase in visibility.
Running a conference is expensive, and the organizers are usually really good about promoting sponsoring companies. Blog posts, “Sponsor” pages, Twitter and Facebook posts, T-shirts, and in-conference announcements are just some of the ways sponsors get promoted.
Whereas user groups may average ten to twenty developers, conferences often have 150 or more (some of these being “rock stars”). By supporting the conference, showing genuine interest in the developers, and by being available to talk, your company should have no problems attracting developer interest.
Like I said, attracting developer interest isn’t hard, but drawing us in is a little different, because we need to know that who your company appears to be lines up with who your company really is. There are at least three things your organization can do to show that you are developer-friendly: Give back to the community; Encourage a hacker culture; Support your current developers.
Chances are, your organization is using open source software, but chances are also that your organization is not giving back to those same projects. I’m not necessarily talking about money, although open source projects are always happy to receive contributions, I’m talking about giving code back to the community.
In his post, “Why Open Source Company Culture is Important”, Michael Bleigh expounds upon why it’s important for companies and organizations to open source as much as they can. For our purposes, this one quote says it all:
Why do you care about happier developers? Well, every company should care about happy employees, but software development is a black magic mix of science, artistry, and craftsmanship. While some work can be done by “forcing it”, a good deal of that work requires inspiration and passion, something you won’t be getting out of developers that feel stifled and isolated from the development community at large.
Open source makes developers happy. You want happy developers. When you open source your code, you are showing that you “get” the community and that your organization is developer-friendly.
Creating a culture within a company is no small feat. In many companies, culture arises naturally, but in others, such as Apple, culture is actively developed and nurtured. And while there is not enough room in this post to describe all that goes into defining company culture - and I am in no position to speak to that - I would like to provide some tips which can allow a hacker culture to be born and grow.
I have worked in companies in which there was no room for failure. It’s stifling, it’s demotivating, and it’s a horrible condition to work in. “When there is no room for failure, there is no room for creativity.”
Failure happens a lot in computer programming. It happens because programmers are human, but it also happens because we’re trying new ideas and we’re growing in our discipline. Failure is a part of growth, so continue to support your devs when they stumble, and celebrate them when they succeed.
Technology is changing rapidly, and nowhere is that more clear than in programming. By allowing your developers to experiment with new technologies, they get a feel for what direction the industry is going and how the organization will inevitably need to respond.
Besides allowing your developers to test out new technologies, encourage them to try out new development techniques as well. Pair programming, standing desks, test driven development, Agile software development, and open seating arrangements can all ignite developer excitement.
Let’s face it, we are talking about getting your developers to try to be more productive, should there ever be a reason not to do that?
You probably already knew this, but Google has the concept of 20% time. The idea is that employees are allowed to use 20% of their work time to work on side projects they find interesting . It is estimated that 50% of all of Google’s products have come out of “twenty percent” projects, including Gmail, Orkut, Google News, and AdSense. (source)
20% is a lot of time, and Google can really only do that because they are overstaffed compared to many companies. But what if you took a couple days a month (10%) to allow your developers time to work on something completely new?
Red Nova Labs, a local Kansas City tech company, recently embarked on what they called Operation Launchpad. The whole company took an entire week off and organized themselves into smaller teams to work on completely new business ideas. The result, as I understand it, is two completely new products which are already close to launching. What could your company do in a week?
Finally, support the developers you currently have on staff. Are we the most business-savvy people? No. Do we know technology and where it is going? Unquestionably. If you really want to support your developers, then listen to them. Yes, we’re nerds and geeks, but as John Stewart recently noted, “I believe the term you are looking for is ‘expert’.”
I can’t stress how important respect is. Most developers I know would rather take a cut in pay and be valued, than be payed well, but whose voice went unheard. If you do not value your developers, one of three things will happen: 1) they’ll leave (most likely); 2) they will work less on work, and more on their own interests; or 3) they will become the replaceable cogs you imagine them to be.
Unfortunately for your organization, it is a seller’s market. We know we are in demand and we use that knowledge to leverage what we want. What is fortunate for your organization, however, is that most competing companies don’t know how to make developers happy - pool tables and free beer just aren’t enough. Furthermore, developers don’t always know what kind of environment they be happiest in. But if your organization can show outwardly that it at least tries to support the community developers live in, and internally provide an environment in which developers can thrive, there should be no lack of good developers from which to choose.
Update 20120306: So what do you do once you’ve attracted developer attention? Jeff Atwood wrote a great post on “How to Hire a Programmer”. You should go read it; he’s wicked-smart.