Finding A Developer To Hire

In my opinion hiring is a challenge for one reason: Good employees keep their jobs. It’s hard to find people that aren’t looking!

How and who to hire has been beaten to death. I will only touch on specific gems I’ve learned in my time.

Don’t Hire A Warm Body

“This person isn’t so bad”, you think. “They’ll do for now, we just need a warm body.” Bullshit. This has bitten me in the ass every single time I’ve done it.

Time

Hiring people is a full-time job. Writing the job up, posting it to various outlets, handling candidates, performing phone screens, conducting interviews, conducting second interviews and negotiating hiring can become a huge time sink. It is vitally important that you set aside plenty of time for this process. How can you expect to get a great hire if you don’t spend the time?

If you task someone in your organization with finding talented developers then please give them adequate time and patience.

Skill Level

Hire the best person you can find and afford. Many companies get sticker shock at developer salaries. It’s a highly skilled and high demand job. As a result they try and skimp by hiring juniors.

Juniors are junior for a reason. They still need to learn. They do this best at the hands of a more senior developer.

Hire the best developers you can find and work your way down. It’s very hard to build a solid structure on a weak foundation.

Sources

Where can you find great developers? Lots of places!

Recruiters

Recruiters, job boards, friends and peers. Your network is always a great place. Use your LinkedIn network!

Boutique Job Boards

There are lots of great job boards these days that are focused on developers. Using one of these boards helps to show that you’ve done some research and hunted for your quarry where it lives!

• Authentic Jobs
• GitHub Jobs
• Gun.io
• Stack Overflow Careers

Conclusion

Reading this should’ve helped you see the work you need to do. Hiring good folks is hard. Be prepared!

Laying A Foundation

Previously I asked if you needed developers. We'll now cover how to lay a foundation for hiring those developers.

Note: This guide is meant for hiring developers, but most of the advice is useful for hiring any position. Learning your employees and treating them properly is just a damned good idea.

Make A Plan

Read through this and all my other advice. Get a plan together that your organization can pull off.

Get Your Mind Right

Have you ever been talking to your mechanic and realized that he's asking you very specific questions all you can do is make noises at him? Talking to a specialist in any field often works this way.

We'll stick with a simple explanation for developers: Developers think in a different language.

Learning the innards of computers and the magic that drives them makes fundamental changes in your brain. Developers tend to ask hard or obtuse questions about the tasks you give them. You need to prepare for this. It's no different than talking to a doctor or mechanic.

Simple advice: Spend extra time with your developers. Learn how they think, talk and act. As with any relationship it pays to invest in it. Expect that they will do the same for you. Teach your developers about your business so that they can help you with better solutions.

Space

I have scaled advice for making space for developers. I will present the options from best to worst. Choose the best you can manage:

• Give every developer an office. Folks smarter than me have been saying this for years.

• Let developers share offices. Be careful who you pair. Encourage open, honest communication and basic neighborly behavior.

• Isolate developers. Give your developers quiet space to work so they can focus. Show me a noisy, distracting environment and I'll show you unproductive and unhappy developers.

• Create cubicles with some privacy. High walls, sound dampening, etc.

• Basic human decency: Enforce headphones, ban speakerphone, discourage phone calls.

I also highly encourage you create some common space for your developers to meet, hack as a group or just to hang out in. Fill it with whiteboards, some Nerf guns and some Red Bull. Use this space for everyone, not just your developers. Encourage this space to be used for hallway meetings, impromptu discussions or phone calls. This will keep your working area quiet.

Telecommuting

It's never been easier to telecommute. Combinations of Skype, IM, group chat (Basecamp, HipChat, Flowdock) and cloud-based systems mean that folks can work together from anywhere in the world.

That being said telecommuting has it's own problems. It's definitely not for everyone. Employees need a quiet, dedicated work space and a close attention to how they spend their time. If you can overcome these challenges then you open yourself to a huge number of talented developers and cost savings. I'm planning to write an entire article on telecommuting in the future.

Gear

Developers don't use computers the way normal people do. Imagine a race car driver hopping into your car and taking it onto a track. The driver would not have the equipment they need.

Developers need to perform tasks with their computers that are very intense. They need powerful processors with lots of cores, lots of RAM and big hard drives. They also need to install and fiddle with lots of software. Your current purchasing and IT policies may not fit. They may also need to be mobile. The best advice I can give is to give your developers a short list of approved hardware and let them choose. Pick a powerful desktop and a powerful laptop.

Big ass monitors. The biggest you can afford and as many as you can plug in. This is pretty much universal.

Policies

A lot of your policies will depend on your business. Many organizations have to worry about compliance with various regulations. You should already know how this works, so I won't help. Start with this advice and prune it back: Give your developers freedom. Teach your developers about the policies your company or industry must adhere to. Developers want to know why they must do things.

Developers can usually fix their own machines and they are little risk for viruses or malware. They often need to install crazy software that requires total access to their machines.

Conclusion

Don't stress getting everything in this list perfect. Getting even a few of these criteria in place makes you very attractive to developers.

If you think all of this is crazy then I suggest you go back and determine if you really need to hire developers.

Do You Need Developers?

Hiring any employee is a big deal. Most of us spend more time working than any other activity. We are around our co-workers more than our families. Developers require special infrastructure and maintenance just like any other employee.

Why Are You Hiring Developers?

What are you looking to accomplish by hiring developers? Are you really a technology company? Will you be able to properly care for and nurture a group of developers?

Hiring developers brings a whole new angle into your company. These people think, act and work differently. If your entire company is currently marketing or sales then you may be in for a real culture shock.

Outsourcing?

You should almost certainly outsource.

There are lots of consultancies and outsourcing shops that would love to have your business. These organizations make it their business to hire and care for developers. They save you the hassle! If you are really a marketing company or a manufacturing company you might save yourself a lot of headaches by outsourcing.

This is good advice for any person you are looking to hire. Do you have enough demand and enough desire to hire a full-time person or group to do a job? It's especially important when you are looking into a discipline that isn't your core business.

Another problem: Are you qualified to interview and evaluate developers? Most people in the technology business aren't. It's daunting.

A Note On Outsourcing

Your problems aren't likely that unique. There is almost certainly something out there that can do what you want. Would you build your own car? Your commute isn't that special. Neither is your problem.

If you need a simple website then use Squarespace and get your social on with Twitter. It's never been easier to have a web and social media presence without a CompSci degree. Very, very few companies need a custom solution. This is usually what gets them into trouble!

Use a consultancy to help you find something that fits. They might try to steer you the custom route for more billings. Keep an eye out for that.

If You Do Need Developers

You still want to hire developers, eh?

Fine. Maybe you do need developers. That's great! Tune in next time and we'll cover how to go about hiring what you need!

Thoughts on Scala

I’ve been spending a lot of time with Scala lately. I’m quite enamored with it. Me being a Perl guy might make this new love affair seem odd. What you may not know is that I’ve been programming in Java off and on since college. My day job has been Perl for many years but that work has all been in shops using Moose. This combination of JVM and modern OO with heavy external influence (CLOS!) has brought me right to Scala’s doorstep.

Since newbies are the best source of information for improvements I thought it would be good for me to document some of my frustrations:

• The documentation is impervious to normal people. I don’t know shit about expressing myself in the way the Scala documentation does it. Some of the docs are decent but others are much harder to read. I’m getting better at this but I still regularly bang my head trying to find examples. Shout out to Stack Exchange for being a great source of help.
• sbt is great. It even has a helpeful Getting Started Guide. Unfortunately there is still a lot of hairy shit going on there. My project is a cobbled together mess of other people’s work.
• The interaction with Java is very helpful but complicated as fuck for new users. I spend a lot of time groping around trying to get JavaType[A] into ScalaType[B]. JavaConversions apparently helps, but I never have any idea what I’m doing.
• I don’t know how anyone ever figures out what release of a library is current and where to get it. Ivy? Maven? What the fuck?
• When I do find a library it’s either undocumented or barely documented. This I can live with, as it’s a young community.
• What is Scala’s infatuation with punctuation? How does anyone keep up with the meaning of all of these things? It even extends into libraries. What the fuck is all this? Perl has deservingly been catching shit for years for the overuse of sigils. But at least there are variable names to help. This more than any other thing makes me want to throw a brick at the nearest Scala dev.

It’s easy to complain. So if you are reading this and taking offense please realize that I am powering through and trying really hard to learn. I’ve yet to feel like Scala isn’t worth my time and I hope someday I can contribute to the Scala community and make it better.

Conclusion

Scala is great. I am still reading a book about it and enjoying everything that I am learning. I love it’s features and it’s interoperability with the JVM. Keep up the great work!

Development According To Me

I’ve been developing for 16 years. That’s nearly 20. That’s a lot of years. I’ve been managing developers for about 5 of those years. Before I was the manager I was being managed. I’ve been lucky enough to work for some great managers and as a result I’ve acquired strong opinions of how to structure and manage development groups.

I’ve managed to convince a few companies they should pay me to do this.

I’ve decided to take some time to write up my thoughts on these matters. I got into management so that I could make development groups that would be great for people like me. Since most developers are like me, this works out.

Over the coming weeks I hope to cover this list of topics:

• Do You Need Developers?
• Laying A Foundation
• Finding A Developer
• Hiring Developers
• Orienting Developers
• Keeping Developers Happy
• Helping Developers Work With Others

Addendums

I’ve got some other material that I’d like to cover in more detail, but that I feel should be separated so as not to burden the reader with too many details at once:

• Telecommuting

I’ll keep this list updated with links to the articles. Here’s hoping they help some folks!