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?
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 visuallySadly, 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?
15 comments:
"You can't fix stupid."
When you consider that programmers can have an order of magnitude difference in productivity, but not in salary, it just doesn't make sense to keep stupid developers around. They are way too expensive.
Props for your post! Your post voices a much whispered concern. I too have seen variations of the types of people you have mentioned. I'm a big believer in having good team leaders who can provide "extra help" for those who may not have what it takes, but I'm afraid the best approach is a "strong firing policy." Maybe strict "procedural" work (data entry, or basic system administration), if such exists, could be given to these people with "blue screened" brains.
I'd take a junior, inexperienced or possibly even "stupid" programmer over an egotistical one any day. I can find ways to keep unskilled programmers busy without harm, and some eventually learn under good leadership. Many turn out to be great Analysts or Testers.
Ego is much harder to snuff out and causes greater damage both to the team and the software.
I've met fantastic developers without degrees who have chunks of egotistical "Software Engineers" in their stool.
I think it's the responsibility of senior developers to identify limitations in their peers and help structure their tasks as much as possible.
I think it's only fair to persevere with such a situation for a time - you may be surprised what someone can learn with good guidance. Having conscientiously spent extra time with a 'struggler', if they do not improve then complement them on their co-operative spirit and kindly show them the door.
I think the key thing is to help someone realise the limits of their abilities in the kindest possible way, so as to help them make objective choices about their careers.
Hope that makes sense
A
Agree more or less, but of course you got it wrong with the seventies. Things have not really changed. Lisp had been around for a while. Not that that the stoopid programmer ever cared about lisp...
Preach!
+1
I think strong opinions are really good to get things out in the open, and people talking about the issues.
I was working under one of these blue screen guys as a junior and it was the worst thing! Plus there was another junior junior who just followed his example and it was such a pity.
Suffice to say, "If you can't change your company, change your company" - and that's what I tried, and what's what I'm doing.
I've often thought about this very topic. Not so much the stupid programmers but more about the average programmers. No one can know everything, and the worst kind is the people who think they know it all. Then you have the people who just don't care. It's a job that pays the bills and thats enough for them. And why not? They have families and bills too. Perhaps their priorities lay elsewhere like spending time with their families or whatever. If everyone hires the gurus where are the average programmers going to work?
If you can't fire them and they mess your project you can create a repository just for them. If they are so stupid they will never realize it. This has happened twice in my experience in two different companies.
"If everyone hires the gurus where are the average programmers going to work?"
The government.
OMG! I was enjoying the post until that "trolley girl". Do you seriously think, that this atmosphere could cultivate anything else but ants, who afraid to raise their head above the average level?
The very first occurrence of such a disrespectful behavior should kill any morale in anybody with a slightest spark of dignity.
I know that I would be spending 60% of my awake time looking for another company.
While there are certainly people who really just do not cut it, most people who are in the profession have the potential to be proficient.
There are always some people who are exceptional but only a very few. The industry has to be able to deal with a lot of people who are average programmers just as a fact that will not likely ever change.
Most 'poor' programmers just never had the luxury working with leaders who can teach and mentor and grow other developers around them.
I have also made an empirical observation about the ego issue. If you want great people, be prepared to deal with egos. There is a limit when it becomes unreasonable, and more often than not you can not put these people in the same team. These people hold strong opinions, are sure of themselves. It is bound to happen to anyone who has poured enough arterial blood on the altar. Just be civil when those disagreements happen, and sometimes it is good be challenged. You do not always get that honest feedback from junior programmers and it can be a problem for your own growth.
"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".
Unless your are a top world class software engineer with a ultra significant safety critical background, your consultant is damn right. Bugs are a natural thing in software writing, and the vast majority of code around is pretty full of bugs. You can't write perfect code from scratch, you make a first version, then it goes through the different checking stages until it arrives in production. You corrected a lot of bugs, but it can still not working as it should (perfectly). And you do it again and again (and again). That's how it works in real life and that's what is the most difficult thing to manage.
"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".
Unless your are a top world class software engineer with a ultra significant safety critical background, your consultant is damn right. Bugs are a natural thing in software writing, and the vast majority of code around is pretty full of bugs. You can't write perfect code from scratch, you make a first version, then it goes through the different checking stages until it arrives in production. You corrected a lot of bugs, but it can still not working as it should (perfectly). And you do it again and again (and again). That's how it works in real life and that's what is the most difficult thing to manage.
In the real world even bad programmers or engineers have mortgages to pay and children to feed. Maybe it'd be useful worry about how to help them or at least re-deploy them instead of conspiring to have them fired so as to minimize their impact on our software engineering nirvana?
If you are in a restaraunt and you get bad service, you can get mad at them or you can "train them up" as to the service you would like. If you were a regular there they would learn what your expectations were and you'd get them. Or you could stay mad and not go there again. Go for the win/win scenario.
Same deal can be applied with programmers on your team. Train them up. Take responsibility for what they deliver and communicate your expectations. They may not get it right away but over time everyone wins. You get the programmer you want and they get to pay their bills and feed their family. Its all about attitude.
Post a Comment