There are two main reasons for which developers may be bad.

They may lack intrinsic motivation, the fire that lives inside good developers and that only them know how to stoke up when it grows weak. You can't set that fire.

They may have worked in dysfunctional environments that snuffed out their motivation. They may have developed flawed habits presented to them as virtuous. You may still be able to repair the damage, provided there still is intrinsic motivation in them, that the fire is not completely extinguished.

The fire

I know very well how warm and bright the fire of intrinsic motivation can be.

I was so passionate that I had the patience to enter words (for us, the geeks, a word is 16 bits) in a computer that had 16 buttons, one of each bit.

I had to lookup some hexadecimal codes (more geekery, definitely machine-friendly only), transform them into sequences of bits and enter a bit at a time.

Managers design working environments that trample on that fire smothering it and than complain that quality is poor, productivity is low and projects fail.

You can spot bad developers asking them to talk about the projects they love. They won't have any. To them writing software is a chore they need to do to pay the bills.

It's more likely that they will talk about deadlines they respected, how they fixed bugs, how they worked in team, everything that is supposed to make others happy, not them.

It's possible that their fire is in quite bad conditions and needs time to rekindle. They may have been working in bad places.

Ask them about any open source or personal project they have been working on. You may still see some fire burning there.

Tech test

Bad developers will happily do tech tests requiring them to remember syntax by heart. Good developers will resist them, they don't waste neurons remembering syntax. There are tools for that.

If a developer finds herself at ease doing a timed test that wants her to produce code against a very strict time limit, here it is a red flag.

You don't want developers who run, they are a disease. You want people who think and ask questions.

Can you invite a candidate to your office and have a bout of pair programming with a future co-worker?

You can see how the candidate communicates, if he is proactive and how she proceeds to find solutions.

Are they naturals?

You don't want developers who bang so fast on the keyboard that you think they are in danger of life. They are not being more productive, they are disseminating the foundations of the building with mines that will eventually explode destroying it.

You want to make sure that they are at ease with the process of finding solutions, that it comes natural to them.

You don't want to see a puzzled look wander on their face for long or never leave. It should be evident that they are in their element when they have code to write.

Communication

Communication is probably even more important than producing good code easily.

Internal and external clients rarely, if ever, know what they want and don't have a clue to what they really need.

The developers who created the Agile Manifesto were well aware of this.

Good developers know that the quality of their work is as high as the quality of their questions.

Bad developers may not give a damn or may be victims of awful work organizations that want them to shut up and do what they are told. They wanted to communicate, but they eventually renounced. Their motivation got the colour of ashes.

Do they fit?

There are companies that are obsessed with cultural fit.

It's very natural to want to work with people who think, behave, dress, feel like us. We enjoy the almost complete certitude that we will never disagree with them. It gives us a warm sense of control.

It's the same thing we get when we micromanage people.

Unfortunately both micromanagement and obsession with cultural fit are bound to suffocate motivation to some extent.

Have your candidate developer talk about past experiences and try to guess how oppressive were the cultures he worked in.

Is still there a sparkle of motivation in his eyes?

If yes, you might be able to repair the damage with your diversity-friendly environment.

Are they perfectionists?

Who will ever find it motivating to ship a sloppy product? Motivated developers want to be proud of what they produce.

They may go through a process of incremental improvement. Initially they put together some code to see if their idea of solution actually works. This code won't be good and it's not meant to be. They are just experimenting. As they see that the idea looks good, they want to refine it and write better code.

As they get more experienced, they will enjoy implementing an idea in new, more efficient and smarter ways.

Trouble begins when they internalise an obsession with perfection. Schools — they are famous for being effective at dousing motivation — may have caused this type of damage.

A developer who writes perfect code to please some authority figure — a teacher, a boss — will neglect the fireplace of his motivation.

Extrinsic motivation, of which fear of judgement is a good example, distracts developers from intrinsic one, the one that matters.

Did they have to pass psychometric tests?

Ask your candidates if they had to pass psychometric tests in the past.

These tests are another way to enforce uniformity.

Teams made of clones suffer twice: they are more likely to compete against each other and don't enjoy the problem solving power only diverse teams have.

Competition is a notorious motivation quencher.

More ways developers may have had their motivation suppressed

Here they are a few well-known demotivators:

• rewards
• punishments
• performance review
• competition
• deadlines

 

Photo by Annie Spratt on Unsplash