Sunday, October 23, 2011
Puzzling Hiring Problems
So, you can't find a decent software developer to join your team? It should not be a surprise. Good developers are rare birds; very intelligent, introverts, detail minded, problem solvers, independent. I don't want to put people in a slot, but this is how developers often are. There just aren't that many sufficiently "brain damaged" people around who like to torture themselves with menial and time consuming problems that take deep concentration. You know, the kind of book worm stuff that people hate when they go to school etc.
You often see a a category of applicants who claim to know programming, but they don't. They usually fail even rudimentary tests that you put in front of them. They are just fishing around, thinking that they can just grab a job and do a bit of good ole hacking on the side. These people don't really want to be software developers on the long run, even for the money. This group of people are a waste of time for anyone who wants to hire a software developer. They won't get much done, and what they get done, sucks.
We have software developers who tend to be careerists. They go to work and write software to get a pay check. They might be introverts and have some of the characteristics of good software developers, but they are only marginally committed. Nothing bad there. Most people you hire are probably like this. They get things done, but it's just not going to be anything more than average. They also mostly expect the work to be handed to them with full requirements and instructions what to develop.
And then there is the group, who is above the average. They care what they do, and they want to write software. They want to learn and they are motivated. These people are good hires, because they also get things done, and over time, they can do things that careerists just won't ever do.
The problem with the last group is that the ones that really have honed their skills are just not out in the open for the grabs, unless you are lucky. You simply rarely see them.
Engineer vs. Designer
Perhaps you have then hired someone suitable enough. They might be talented, and eager to do the job. They produce results and get things done, at times. But something just does not really jive. This seems to be true too; some developers enjoy the theoretical aspects of the profession, and some just like to slap things together quickly.
Either extreme does not work well. You don't want the architecture astronauts, or the cut and paste hackers, but you do want something in the middle range. This is because theory matters when it is put to good practical use.
You sometimes see people get stuck designing all kinds of lofty ideas that are not really relevant to the problem anymore from the practical perspective. It can be fun to think about, but it's a disaster waiting to happen in real life. It can take different forms; mindless use of tools that do not solve the practical and real problem (because in theory it could work), stuffing layers to software that only add to complexity (because it's what the best practices are). This is the designer trap that people sometimes get into.
Opposite can happen. Software is getting done fast, and quickly, but it is all in the name of getting it out the door in what ever way. It's bad software, hacky, copy pasted, sloppy, not well thought out, without any decent structure. Sure, it can work but only in small scale. Bigger software, critical software, and long term maintenance of software are those key areas where this kind of "getting it done" approach will create a disaster. It's perhaps what happens more often than over-architecting because things are being done and there is the feel of great progress. Managers especially love these kinds of people who turn around on a dime and "get things done".
To a significant degree these two kinds problems emerge from lack of experience. People are just good enough to produce results but the wisdom, intuition or true skill is not there to reign in the bad behaviors. Experienced people are simply far more balanced and know how to manage the outcomes.
Introverts and Extroverts
Some people are more social than others. Some people are more detail oriented than others. Some can solve problems better than others, and different kinds of problems. Some people are glib, some are not. What do you really want to emphasize in a developer?
There is the argument that now that we are doing all this Agile stuff that developers need to be really social and engaging, eagerly embracing the business, while at the same time you want them to produce brilliant, well thought out software that comes out like clock work, and never misses a deadline. Well, easier said than done.
I mentioned that most good software developers are really introverts. It's still true, in my opinion. It does not mean they are not social enough, but they are not the ones with the gift of the gab and "social engineers". They mostly focus on solving "non-people" problems that are eternally boring to the vast majority of people. These people stay focused on the technical aspects of getting things done, formulating complex things and making it real in terms of good software. It requires lots of concentration, free from unnecessary interruptions.This regardless of all the buzz about agile pairing etc. I don't think it always works; have never seen it work for real, in fact.
I think you want some kind of mix here as well, slanted towards the introvert types. If you want a good reliable software developer, you need that quieter type who gets things done with good workable design skills, who can still interact successfully with business and product owners when required. The onus for successful interaction is often put on the developer, but I think this is wrong - why not require equal attention and skills from business/product people when interacting with developers, to be able to understand enough what the developer is saying. IT functions are now so central to businesses that having business people who do not understand their IT operations is really a bad thing.
There are places for extroverts as well, in the agile realm of things. A good Scrum Master is often someone who's an extrovert, but they necessarily do not or should not lead software development from the trenches. Their focus tends to drift away from what is required to produce good software in practical terms. These kinds of people tend to jump around from one thing to another, relishing the opportunities to get things done quickly and moving on. Software development might interest them, but not in the sense that is required to become good at it.
The bottom line - don't expect developers to be socially gifted, while at the same time being great at building good software. It just does not work that way. We do not elect, nor often see politicians who are introverts, so why put unrealistic expectations on software developers? Brain, and the way it works matters when it comes to different kinds of jobs.