Title: Professionalism in Programming #31

Cowboy code works, but isn't particularly elegant. Cowboys like to learn new things, but seldom get around to it (it's too much like hard work).

You'll spend ages cleaning up after a Cowboy. Their aftermath is not a pleasant place to be. Cowboy code always requires later repair, rework and refactoring. They have a limited palette of techniques to use, and no real engineering skills.

Learn to hack code in the right sense of the word. Take a pride in your work, and spend more time over it. Admit your failings, and try to improve.

Never go into a Cowboy's house; if their code's anything to go by, it'll be a DIY disaster! Understand that they're not a malicious breed, just a little lazy. Organise reviews of their code. Get them pair programming (they might work well with an Eager Coder, but if you want to see fur flying pair them with a Planner).

They do design. They do think. They don't hack out thoughtless code.

When a Planner sets to work there is a very real danger of over design. He tends to create very complex systems. Planners are the key cause of analysis paralysis - where development gets more focused on methods and modelling than on prototyping and creating a solution. The Planner likes to generate endless documents and call meetings every other hour.

He spends ages thinking, and not enough time doing anything. He knows a lot, but it doesn't all make the leap from theory to practice.

It is important to create careful designs up front, but consider incremental development and prototyping as methods to verify your design. Sometimes you can't commit to a design until you've actually started to implement it. Only then will you appreciate all the problems.

Try to establish a better balance of planning and action. Console yourself that it's better to spend too long designing than to write awful code - the latter is far harder to fix.

Ahead of time, agree all milestones and deadlines for a Planner's work. Throw in a design complete milestone; they'll be happy that it has been recognised as an important task, and encouraged to complete their design work on time. This is usually enough to crystallise a Planner into action.

Avoid meetings with a Planner. You'll spend an hour arguing about how to decide the agenda.

He's been programming for years, and so has considerable experience and wisdom. The Old Timer has a mature approach to coding. He has learnt what qualities make good and bad programs, and how to avoid the common pitfalls.

The Old Timer won't willingly learn new techniques. Fed up with fashionable ideas that promise much and deliver little, he's slower and more resilient to change.

He has little patience thanks to years of corporate ineptitude. He's been at the receiving end of countless tight deadlines and unreasonable managers.

Don't be too judgmental of younger more enthusiastic programmers. You were once like them, and your code wasn't awful.

You don't know how easy you have it, you young programmers. Don't mess with an Old Timer, or you'll find out how he survived this long in the software factory. Choose your battles with him wisely. Show him respect, but treat him as a peer, not a deity.

Understand the Old Timer's motivation. Check if he's programming because he loves to do so, or because he can't scale the promotional ladder any higher.

He knows BigCo's products inside out, and will produce genuinely good designs based on them. He is productive with that technology, but not necessarily maximally productive - other unfamiliar approaches might be more effective.

Being a Zealot, he's neither objective nor pragmatic. There may be better non-BigCo designs that he will miss. Worse, though, are the Zealot's continual rants about BigCo.

No one expects you to turn away from your beloved BigCo. It's valuable to understand their technologies and know how to deploy them. But don't be a technology bigot. Embrace different approaches and new ways of thinking. Don't look at them with an air of superiority, or prejudge them.

Don't bother getting into philosophical arguments with a Zealot. Don't try to explain the virtues of your preferred technology - he won't listen. Watch yourself - one conversation with this guy can turn you into a Zealot. He's contagious.

Zealots are generally harmless (and amusing to watch from a distance), unless your project is at a critical design stage. At this point, provide a clear, unbiased perspective on the problem domain and insist on a thorough evaluation of all implementation approaches. Remember: he might be right.

If you encounter silly arguments, counter them with well prepared, accurate, detailed information about the strengths of your approach and the weaknesses of his.

At least he knows how to have fun.

A Slacker is an obvious liability. It's hard to prove he's slacking - some hard problems do take a while to sort out. A programmer might not be slack, just not skilled enough to solve the problem quickly.

Work on your morals, and start to put some effort in. Or learn to live with the guilt.

It's best not to bitch about a Slacker - you have your own flaws. In good time he'll get his come-uppance.

Take measures to prove that you are working effectively, and that delays are the Slacker's fault. It might help to keep a methodical diary of your work. A clear set of deadlines is generally enough to get a Slacker working. Don't start writing his stuff too, even in desperation. He'll only expect you to do this next time.

Avoid burnout yourself, try to have fun as you work. Perhaps you should hit the bar with him one lunchtime.

The Reluctant Team Leader has a real sympathy for the programmer's plight - he's been there, and now wishes he was back. Often he is far too willing to take responsibility for late software delivery, to prevent the programmers being picked on by management. Just as he's not good at delegating work, he's not good at apportioning blame.

When a Team Leader tries to write code it will be awful. He never has enough time to write, design, and test carefully. He naively plans himself a full day's coding alongside team leading duties. He can't fit it all in, and so the Reluctant Team Leader spends longer and longer in the office, trying to keep up.

He can't organise well, can't explain things to managers, and can't manage his team members properly.

Get training. Quickly.

If you're not happy in this role, push for a career move. This is not admitting defeat; it's pointless to burn yourself out doing something you hate and aren't good at. Not everybody has the skills or passion for management. Move to the area you do have skill and passion for.

If you like herculean tasks, try to sort out the promotion path at your company. Get them to recognise that a managerial position should not be the next step up from senior developer. Few programmers make decent managers; their brains aren't wired up the right way.

Be sympathetic, and do everything you can to help the Team Leader. Give him reports on time, and try to get your work done to schedule. If you might miss a deadline, let the Team Leader know early on, so he can plan around it.

They must be diplomatic, able to deal with all of these weird code monkeys and the many, many more creatures that inhabit the software factory - managers, testers, support, customers, users, and so on.

They work well with others. They aren't territorial about their code and aren't afraid to get their hands dirty if a task is for the common good. They communicate well - they can listen as well as talk.

They can design elegant solutions, and appreciate the aesthetic aspects of a high quality implementation.

They write solid, industrial strength code. They have a broad palette of technical skills, and understand how and when to apply them.