Title: Professionalism in Programming #30

Author:

Date: 03 February 2005 13:16:10 +00:00 or Thu, 03 February 2005 13:16:10 +00:00

Summary:

Body:

Code Monkeys (Part One)

We are just an advanced breed of monkeys on a minor planet of a very average star. But we can understand the Universe. That makes us something very special. - Stephen Hawking

As time marches relentlessly onwards we're drawing near to the 2005 ACCU conference (you have booked your place, haven't you?) I've been preparing this year's presentation, and so I thought that this would be a good opportunity to review what I presented last year.

In a previous article I asked the frivolous question: how many programmers does it take to change a light bulb? There could be any number of answers, but it really depends on who is doing the work. Different programmers work in different ways and will have their own individual approach to solve the same problem. There is always more than one way to do it^[1], and different programmers' attitudes will lead them to make very different decisions.

In this series of articles we'll look at this; we'll investigate programmer attitudes, good and bad, and identify the key ones for successful programming. This includes how we approach the task of coding, and also how we relate to other programmers. We'll come to some surprising conclusions about what makes the best coders.

Monkey Business

The software factory is inhabited by a strange collection of freaks and social misfits. Any serious software system is built by a bunch of these people, with their different skill levels and attitudes, all working towards a common goal.

The way we work together and the kind of code we write will inevitably be shaped by our attitude to the work. If everyone was a diligent, hard working genius then our software would be a lot better; delivered on time, to budget, with no bugs. We're not perfect, and unfortunately it shows in the code we write.

To work out strategies to deal with this I'll lead us on a guided tour through a gallery of programmer stereotypes. We'll see the different types of code monkey. These are all directly based on the types of people I have met in the software factory. Of course it's a necessarily general list; you'll know programmers who fall into categories other than those listed here, or even fit several descriptions at once.

Even so, this shameless categorisation will highlight the important facts and show us how we can improve. We'll see:

what makes different types of code monkey tick,
how to work with each of them,
how each code monkey can improve, and
what we can learn from each of them.

As you read each code monkey description, ask yourself:

Are you this type of programmer? How closely does the description match your programming style? What lessons can you learn to improve your approach to coding?
How many people do you know like this? Are they close colleagues, and can you work with them better?

Without further ado, meet The Code Monkeys...

1. The Eager Coder

We'll start with this guy, because he^[2] probably embodies the traits of most programmers. The Eager Coder is fast and fleeting; he thinks in code. An impulsive, natural born programmer, he tends to write code as soon as an idea forms in his head. He's not good at standing back and thinking first. So, although an Eager Coder does have very good technical skills, the code he writes never shows his true potential.

The Eager Coder often tries to use a new feature or idiom because it's fashionable, the best thing since the last big new idea. His desire to try out new tricks means that he applies technology even when it's not appropriate.

Strengths:

Eager Coders are productive, in terms of code quantity. They write a lot of code. They love learning new stuff, and are really enthusiastic - even passionate - about programming. The Eager Coder loves his job, and genuinely wants to write good code.

Weaknesses:

Due to his unfettered enthusiasm, the Eager Coder is hasty and doesn't think before rushing into the code editor. He does write a lot of code, but because he writes it so fast, it's flawed - the Eager Coder spends ages debugging. A little forethought would prevent many silly errors, and many hours ironing out careless faults.

Unfortunately the Eager Coder is a really bad debugger. In the same way he rushes into coding, he dives straight into debugging. He's not methodical, so he spends ages chasing faults down blind alleys.

He's a poor estimator of time. He'll make a reasonable estimate for the case when it all goes well, but it never does go according to plan; he always takes longer than expected.

What to do if you are one:

Don't lose that enthusiasm - it's one of the best characteristics of a programmer. Because your joy lies in seeing programs work, to stand back and admire the beauty of code, work out practical ways to do this.

It mostly boils down to this simple piece of advice: stop and think. Don't be hasty. Work out personal disciplines that will help you, even something basic like writing THINK on a post-it-note stuck to your monitor!

How to work with them:

When they work well, these are some of the best people to program alongside. The trick is to channel their energy into productive code rather than mindless flapping. They are great to get pair programming.

Ask an Eager Coder about what he's doing each day, and what his plans are. Show an interest in his design - it will encourage him to really think about it! If you rely on an Eager Coder's work, ask for early pre-releases, and ask to see their unit tests too.

An Eager Coder benefits from appropriate management, to help with his discipline. Make sure his time is carefully placed on a project plan (you don't have to plan his time yourself).

2. The Code Monkey

If you ever need an infinite number of monkeys, these guys would be your first choice. (I wouldn't advise it though, you'll be picking monkeys for a loooong time!)

The Code Monkey writes solid but uninspired code. Given an assignment, they'll faithfully plod through it, ready to be handed the next one. Perhaps it's a little unfair, but because of their menial work these guys are also known as grunt programmers.

Code Monkeys have quieter personalities. Afraid to push for good jobs, they tend to get sidelined on unglamorous projects. They carve out a niche as maintenance programmers, keeping the aged codebase going whilst the pioneers are off writing exciting replacements.

A junior Code Monkey will learn and progress given time and mentoring, but is given 'low risk' assignments for now. An older Code Monkey has probably stagnated, and will retire a Code Monkey. He'll be quite happy to do so.

Strengths:

Give them a job and they'll do it, reasonably well, reasonably on time. A Code Monkey is reliable, and can usually be counted on to put in extra effort when it comes to crunch time.

Unlike an Eager Coder, a Code Monkey is a good estimator of time. They are methodical and thorough.

Weaknesses:

Although a Code Monkey is careful and methodical, they don't think outside of the box. They lack design flair and intuition. A Code Monkey will follow the existing code design conventions unquestioningly, rather than address any potential problems. Since they are not accountable for the design, they don't accept responsibility for any problems that arise, and won't often take the initiative to investigate and fix them.

It's hard to teach a Code Monkey new stuff; they're just not interested.

What to do if you are one:

Do you want to explore new areas and broaden your responsibility? If so, start to strengthen your skills by practicing on personal projects. Grab some books and study new techniques.

Push for more responsibility, and offer to join in the design work. Take the initiative in your current work - identify possible failure points early, and work out plans to avoid them.

How to work with them:

Don't look down on a Code Monkey, even if you have stronger technical skills or greater responsibility. Encourage them - compliment their code and teach them techniques to improve their work.

Write your code thoughtfully to make the maintenance programmer's job as easy as possible.

3. The Guru

This is the fabled mystic genius, a program wizard. The Guru tends to be quiet and unassuming, perhaps even a little odd. He writes excellent code, but can't communicate well with mere mortals.

The Guru is left alone to work on the fundamental stuff: frameworks, architectures, kernels, and so on. He holds the deserved respect (and sometimes fear) of his colleagues. Omniscient, the Guru knows all and sees all. He turns up sagely in any technical discussion to dispense his expert opinion.

Strengths:

Gurus are the experienced magicians. They know all the new magic, and understand why the old tricks are better. These are the guys that created magic in the first place. They have a wealth of experience, and write mature maintainable code.

A good Guru is a wonderful mentor - there's so much to learn from him.

Weaknesses:

Few Gurus can communicate well. They're not always tongue tied, but their ideas fly so fast and at a level beyond mere mortals', that it's hard to follow them. A conversation with a Guru either makes you feel stupid, confused, or both.

A bad Guru makes a fantastically bad mentor. They find it hard to understand why others don't know as much, or don't think as fast as them.

What to do if you are one:

Try to step off your cloud and live in the Real World. Don't expect everyone to be as quick as you, or to think in the same way as you. It takes a lot of skill to explain something simply and clearly. Practice this.

How to work with them:

If you cross paths with a Guru, learn from them. Absorb what you can - and not just technical stuff. To become established as a Guru takes a certain temperament and personality - knowledge but not arrogance. Observe this.

4. The Demiguru

The Demiguru thinks he's a genius. He isn't. He talks knowledgeably, but talks a load of rubbish.

This is probably the most dangerous type of code monkey; a Demiguru is hard to spot until the damage is done. Managers believe he's a genius, because he sounds so plausible and sure of himself.

A Demiguru is generally less quiet than a Guru. He's more boastful and full of himself.

Strengths:

It's easy to assume that a Demiguru has no strengths, but his great asset is his belief in himself. It's important to trust your own abilities, and be secure that you write high quality code. However

Weaknesses:

The Demiguru's great weakness is his belief in himself. He overestimates his abilities, and when left to make important decisions will jeopardise your project's success. At worse, he's a serious liability.

The Demiguru will haunt you, even after he's moved on to new pastures. You'll be left with the consequences of his bad decisions, and his overly clever code.

What to do if you are one:

Right now, take an honest appraisal of your skills. Don't oversell yourself. Ambition is a good thing; pretending to be something you're not isn't.

You may not be doing this on purpose, so be objective about what you can and cannot do. Be more concerned about the quality of your software than how important or clever you look.

How to work with them:

Be very, very careful.

5. The Arrogant Genius

This guy is a subtle, but significant, variation on the Guru species. He annoys the pants off of you - he's the killer programmer. Fast and efficient, he writes high quality code. Not quite a Guru, but he's hot.

But because he's all too aware of his own skills he's cocky, condescending and demeaning. The Genius is often terminally argumentative, because he's so used to being right and having to promote his correct view over other's wrong opinions. He's become used to it now.

The most annoying thing is that most of the time he is right, so you're bound to lose any argument with him. If you are correct, he'll keep talking until the argument moves on to something he is right about.

Strengths:

The Genius has considerable technical skill. He can provide a strong technical lead, and will catalyse a team when everyone agrees with him.

Weaknesses:

The Genius doesn't like to be proved wrong, and thinks that he must always be right. He feels compelled to act as an authority; the Genius 'knows' everything about everything. Even if he has no experience at all, he still tries to look knowledgeable. He can never say I don't know, suffering from a full humility bypass.

What to do if you are one:

Not everyone achieves God-like status, but there are plenty of good programmers worthy of respect. Recognise this. Practice humility, and honour other people's opinions

Look for people who might have a more experienced viewpoint, and learn from them. Don't pretend - be honest about what you do and don't know.

How to work with them:

Do show a Genius respect, and show respect to other programmers around him. Don't come up against him, and don't enter into unconstructive quarrels. But stand your ground - assert your reasonable opinions and views. Don't be daunted by him. Discussing technical issues with a Genius can make you a better programmer; just learn to detach your emotions first. If you're sure you're correct, gain allies to help fight the stance.

Take heed and avoid being cocky yourself.

Next Time

We'll look at some more programmer stereotypes, and work out what the 'ideal programmer' looks like. Stay tuned.

^[1] The Perl programmers' mantra.

^[2] I'll describe all code monkeys as male, for no other reason than clarity of prose.

Notes:

More fields may be available via dynamicdata ..