I often hear this reference banded around, but no-one has really been able to clearly define what a “Cowboy Coder” actually is. We have all seen behaviours in our IT experience of “cow-boyish behaviour” or even know a few “cowboy coders” ourselves. You may even be one yourself, and not realise it, and I am sure most of us have displayed cow-boyish tendencies in the past … ;-).
My simple definition of a cowboy coder is:
someone who writes code according to their own rules, ideals or what they are feeling like at the time.
This unfortunately expands to:
someone who interacts in the whole software lifecycle according to their own rules, and therefore is rather difficult to control, lead and encourage to be an effective part of a working team.
no real cowboys should be hurt in the making of this blog
Cowboy disclaimer. I love cowboys, who work a very difficult job in a disciplined manner in teams. I loved Stephen King's "The Dark Tower" series, I loved the Good the Bad and the Ugly and I thought "Once upon a time in the west" was terrific. I think its a poor analogy that poor quality people of trade get labelled as cowboys.
Intellectual Intimidation over working as a team
I have seen some IT professionals sadly behaving in a cow-boyish manner by using intimidation. Essentially they know their topic really well, usually its their programming language they specialise in, but unfortunately decide thats the only thing that matters and their focus is onto personal performance rather than team progress. Typically expressed in disdain and intimidation of other ideas from colleagues and a lack of wanting to help others, which spirals into a real intolerance.
Eg. “Harry is useless at design patterns he doesn’t even understand the decorator that I designed…” … well why don’t you explain the decorator pattern with him, and exercise your communication and patience skills until he also understand it…..?
Now some of us enjoy a steeper learning curve than others, but the Dreyfus model of skill aquisition (http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition) (and my own experience) teaches us (sorry not directly mentioned in the reference) that competancy will always be achieved by someone over time. For some people its faster, for some not. Which means if you have someone who is not grasping things that quickly, guess what, give them time, they will do, unless you have been completely mad in your hiring strategy.
For example someone who has blagged that they are a dev lead but really they are a junior developer, can still gain competency in the dev lead work, but it will take time.
A lot of the issues stem from thought and behaviour patterns. We are of course working in an industry that is very volatile, especially with the .com bubble bursting at the turn of the millenium as well as the current financial crises.
1) People want to keep their job, if they make other people look good they feel that they would become less valuable. That’s pretty much the opposite of teamwork and against every corporate “value” in the book, yet people still do it.
2) People with a win/lose mentality, thinking there is a fixed reward, or that they can only profit from someone else’s expense. Snuffing someones candle out does not make yours brighter, it might seem brighter to you, but the room is darker.
3) People who retain knowledge for selfish reasons, they become like wizards and warlocks.
Essentially it all boils down to selfishness.
other types of cowboys leave a painful legacy
I have also seen individuals who would rather “reinvent the wheel” rather than use a standard library or design pattern just for the enjoyment of it. Guess what, often its a slight improvement on the existing code, however, the way its written, and then handed over can cause complete confusion for the rest of the team. Sometimes its better to have a slightly less efficient piece of code that’s easily maintained than a slightly better piece of code that is impossible or extremely expensive to maintain and understand. Often this stems from a lack of discipline in a developer to follow through on what was a good idea and embed the knowledge in the team leaving a good legacy rather than legacy code, which if you are or were a developer we have all had to deal with ….
Something else I would loosely put into the cowboy category, is someone who will talk ill of a fellow team member without really trying to help them, or rather will make a show of helping them without actually helping them. Guess what? Sometimes its the failure of the teacher rather than the pupil, a teacher hasn’t taught until a pupil has learned.
Remember someone being “not good enough” could simply be the fact that going from a novice to competent is taking longer than you thought. Now not everyone gets to “Proficient” or “Expert” but that’s done via demonstration not remonstration.
is really really poor quality code cow-boyish code
I actually dont see a huge deal of this, maybe in the dot.com side I saw more of it, but really really poor quality code I don’t see as really cow-boyish these days, bad quality code is just bad quality code, it has no personality; I would be more interested in the behaviour of the team that allowed that quality through.
Its not a black and white definition, and nor are people who display cow-boyish behaviour cowboys all of the time, and all of the way through. But its always good to do some self examination from time to time. One thing that will be obvious is that cowboys, although may be able to understand the workings of a team, and understand team playing are not team players while in cowboy mode.