Is there no hope for stoopid programmers?

despair.com

Recently, we (on the Interblag) have gone through another wave of controversial discussions about people who shouldn't be writing code and should consider choosing a different career that is not in Technology. There has been heated debate and a lot of elitism expressed but what we have not talked about is if there is some other way for these developers to be used. I would like to consider and work my way through this idea.

There are many different levels of developers. My usual way of dividing up developers is in to two groups: Software Engineers and People Who Waste Air. This is the result of years of running in to and over people who don't belong in my profession.

On my long commute to and from my current engagement (in south-Brisbane/Chatswood), I've had the time to wonder...

• Why don't some programmers belong in IT?
• How do we encourage them go somewhere else?
• and if we can't then what can be done to make them useful and less destructive?

Let me work through this in a slightly more succinct way than I have on the train and without the interruption of smelly passengers who like to rub up against my leg. That's another blog post for another time or just follow me on twitter for my daily #TrainTalk.


Why don't some programmers belong in IT?

This is not a new list of reasons. Most discussion seems to settle on the idea that there are people who are always learning and adopting new ideas. They do this in order to hone their craft and improve the journey - the journey from idea to software for the builders and the clients. These people are probably you. Yes, you reading this blog. You are a small minority of people who are constantly learning and thinking.

There are also people who don't learn or they once did and that was enough. That usually means that they don't know what's going on now. I've heard people say...

nothing has changed since the 70s in computing

...and I really want to slap them with the Internet.

Then there are those people who have brains but they've blue screened or they just don't think the way you need to think to do this job. If the idea of expressing something in code is difficult every time then that's not good. One highly paid contractor I worked with in 2005 said

programming is a matter of trial and error. You write it and then you try to get it working over and over again until it all of a sudden does.

That's not how it works if you have a clue at all about what you are doing. If this is how the job looks to you then look for another job.

The other prevalent characteristic that rears it's ugly head and hisses at us, is the unwillingness to alter the way things are done. Change is difficult for everyone. I struggle with it in many ways, every day. Change is not worth it just for the sake of change and that's not how I like to do it. I like the idea of learning from what I've done before. Retrospection and learning are reasons for change. Many programmers I've worked with who probably should not have been there were not open to adjusting their ways in any form at all. It was the way they were comfortable and any motion made them very insecure.


How do we encourage them go somewhere else?

The solution I usually see to getting rid of people who are making a mess of their career in IT or making a mess of your project, is to have the team push them out. First assumption here is that the rest of the team is able to judge that a person is not worthy. The Dunning Kruger effect describes when people who don't know much think they know a lot, while those who know a lot realise how little they actually know. What if your team really believes in themselves but don't have the ability to judge up? What if they don't know enough to know if an engineer is good?

indexed.blogspot.com shows the Dunning-Kruger effect visually

Sadly, I have seen that a lot. Teams of people who have decided that they are brilliant and have nothing more to learn. Anyone who disagrees with their team is collectively declared an idiot. Wrongly usually but the mob prevails. They have little chance of realising this about themselves so self-culling won't occur. Other teams and organisations do it quite well. I guess you need to find smart people first or bring in smart people who can make this judgement.

There is one other way to deal with this and it is to have as good a firing policy as your hiring policy. I've worked in a situation like that. The people manager was one of the coolest chicks you've ever met but one of the scariest if you happened to suck at your job. In her previous company, she was known to come up to the desk of people judged lacking with a moving trolley so they could be marched off the premises wheeling their belongings. It got to the point that people would run and hide if they saw her pushing a trolley. The thing was that she did something about people who were not meant to be there. She didn't let them cluster or build up political power. If you were wrongly hired, your were rightly fired. Trolleyed out!


If we can't get rid of them then what can be done to make them useful and less destructive?

This is where the arguments start. If you've had to spend the time undoing and fixing what these people produce then you just don't want them there. That is fair. If you have had to work with people who you have to constantly direct and correct then that consumes time and good resources. You could write the code in the time it takes to hammer it in to their heads. That frustration is understandable.

While writing this post I asked if these people are the same as junior developers who need to be mentored and taught and there was a resounding "NO WAY!" in response. Juniors with potential are more productive and encouraging than the useless types.

People suggested that it's best to keep them out of the way all together. Give them the jobs that no good developer wants. I'm not sure what those jobs are. Won't they just screw them up too?

At a start-up I worked at recently, the most unproductive and partially comatose person in the business was allowed to do the repetitive Flash work. He was a flunky for the graphic designer. Someone to write the script the designer wasn't interested in but had to be done. He was happy doing that and it kept him out of harms way, mostly.

The conclusion seems to be that these non-developers should be kept out of the way or removed completely. Is this valid? Is this how we all see it? Maybe there is no conclusion. I still need to ask...

Is there no hope for stoopid programmers?