The BCS is currently pushing the concept of professionalism in the IT industry. This is an attempt to move the industry a step closer to being one of the recognised “professions” – like accountancy, medicine or the legal profession.

This is to be encouraged and should be welcomed by software professionals everywhere.

A couple of weeks ago I was watching one of BBC Four’s documentaries about Edwardians. It discussed how in that period, the middle classes started joining professional bodies in great numbers – particularly engineers, whose various industries had boomed over the previous century (although the the Edwardian link is tenuous – at least the Institution of Civil Engineers was nearly 100 years old by then).

One of the main reasons for the rise of the professions was to protect standards. “Professional” engineers wanted to recognise those people in the industry who had training in mathematics and physics and engineering principles, who had served their apprenticeships, did proper calculations before building things and worked to a high standard.

The professional bodies had barriers to entry based on knowledge and experience, with a disciplinary procedure if you breached good practice, with the possibility of expulsion if you really messed up. Clients could choose to use unchartered engineers at their own risk, but if you wanted quality work, with escalation procedures if problems occurred, then you would use a chartered engineer. Eventually such bodies were recognised in law, and chartered engineers became viewed alongside the other professions.

Software is new. There are many discussions around what analogies are appropriate (see the recent debate at Code Craft for a start), but ultimately it’s new and there are no complete analogies – it’s not engineering, it’s not science, building software is not like planting a garden or building a house. It’s new. But there are many parallels to the existing professions.

Software is complex, to do it you need training and education, you need to be well read; to do it well you need to have served an apprenticeship, the subject is constantly changing and growing and you need to constantly learn. It’s as much a professional activity as law or accountancy or engineering or medicine – or at least, it should be.

When you go to a hospital you are treated by doctors regulated by a professional body, in a building designed by architects and engineers who are regulated by professional bodies. You are then hooked up to machinery using software written by… well, if the software fails (and you survive) you may have some comeback on the company that supplied it; but the people that wrote the code – they may just have been some Summer students or contractors whose names are long forgotten. I’m sure there are many checks in place to make sure this doesn’t happen, there may even be laws around it, but ultimately nobody is regulating the practitioners.

Sure, 99% of software isn’t about life and death. But it is complex, expensive and its failure can cause frustration and financial damage, lost time, lost data, lost business, legal problems – and sometimes worse.

So I applaud the BCS Professionalism in IT programme. There’s work to do – perhaps “IT” is too broad and non-specific; eventually I would expect the barriers to entry to be raised; the grievance procedures need to be tested; etc.

But eventually students graduating in Computer Science will strive to enter companies where perhaps they can serve their apprenticeships and achieve chartered status in a few years after passing professional exams (as is the approach in the legal and accountancy professions). And chartered status would be recognised by employers and buyers of software services, and afforded the same respect as that associated to the existing professions.

Ultimately it will mean greater and more general respect for reliable software practictioners; greater governance over the industry, and greater respect for software practitioners within their companies – where often technically skilled practitioners are treated as the equivalent to production line employees, inferior to those who (for example) may be in non-technical managerial positions. I suspect such issues do not arise in legal practices, and software practitioners need to raise the bar of professionalism to take control of their own industry.

This is the first in a possibly occasional series stating obvious (but oft-ignored) facts about hiring programmers. Today’s lesson applies equally well to hiring any technical staff, consultants, managers, lollipop ladies, whoever you want.

Some of this may sound obvious, but despite that, it’s exactly the sort of stuff you (or your non-technical manager) can easily forget when you’re under pressure to hire for that project which is running a bit late, and when you’re perhaps a bit too busy to spend time recruiting. It’s all too easy to forget the basics when confronted with a smooth-talking expert interviewee…

Main Definitions (no credit to Rumsfeld):

• Intelligent people know what they don’t know.
• Stupid people don’t know what they don’t know.
• Naïve people think they know but don’t really.

Secondary Definitions:

• Honest people say when they don’t know something.
• Egotists don’t say when they don’t know something, but quickly go and find out, hoping you won’t notice.
• Sneaky people don’t say when they don’t know something, but cover it with a flurry of technical terms.

Recruitment Advice:

• Everybody is a combination of intelligent, stupid and naïve (yes, including you). It’s best to hire people who are intelligent more often than they are stupid or naïve.
• Hire honest people. Egotists are timewasters, and will always turn sneaky before they turn honest.
• Don’t hire sneaky people. They can be alluring, giving you that warm feeling of saying “yes” a lot and sounding authoritative. You’ll want to hire them, especially if you’re under pressure: Don’t. As H. L. Mencken said, “It is the dull man who is always sure, and the sure man who is always dull.”
• If you interview someone who knows everything, then it’s possible you may be naïve.
• If you work with someone who says “yes” a little too often when arbitrary technologies are discussed, then it’s possible that they are sneaks.
• Nobody knows everything.

If you hire a sneaky egotist it’s quite possible you won’t realise until you find yourself in the office at 4am rewriting their code, so your interview process must find them out…

…Next Time: How To Know If They Know What They Say They Know.