Well I’m cruising 36,000 feet above the Atlantic cramped in economy class with better things to do. I came across this article in CIO about developers and what they get up to.
The gist of the story is that developers usually have their own agenda which is at variance with the employer’s interests. I looked back on my experiences in this line and saw many occurrences of this.
Many years back I had a realization: most developers (programmers in other words) don’t really know what their jobs are!
This may sound a bit alarmist or snide, but I have found it to be an actual fact. After handling this stumbling block in my business I started to get more reliable and usable systems developed. Our company actually started challenging companies 10 times larger and winning! I had overcome the so called ‘Technology debt’ or main stumbling block in development: developing effective, re-usable and maintainable code.
Software devellopement companies don’t get it, but one of their biggest stops is what I call developer inertia and employee individuation.
These two things are the bane of software development.
By developer inertia I am referring to things like: ‘It needs to be rewritten in Java’, ‘I don’t do C++’, ‘It’s very complicated to do’, ‘I can’t tell how long it will take’, ‘It’s not object oriented’ and so on. You see in my mind any programmer who comes up with one of these is not a programmer but a ‘Hobbyist’! I hope that doesn’t offend anyone but if you look at it that’s what it shows. A professional gets the job done, he or she creates a solution that fulfills the business need because he actually gets what is needed and sees the bigger picture.
By employee individuation I am referring to the guy (or gal) who seperates himself from his team, his employer. He is the one who tries out the latest fad in some development because he will learn something new, not help his employer by delivering an effective solution. He is also the one who says it can’t be done, but then shoots down an external contractor who is willing to actually do it! Any of these sound familiar? I’ve had my share, both as the employer and the external consultant trying to get a good solution.
Well behind these two is just the fact that the employed programmer or consulting programmer does not know what his job really is! It’s that simple. The moment you sign your employment contract you are agreeing to not be a hobbyist but someone who helps the company by creating effective and maintainable/reusable code. It’s no longer just for your fun. The fun expands to being fun to make your employer/company win! That is the difference. That’s the no individuation. That’s being a part of the team, part of the group and so on.
This is not necessarily the programmer’s fault. It’s the employer’s responsibility to make the programmer part of the team and inform him clearly of what is wanted. Here also the employer needs some knowledge as well so he is not hoodwinked. The programmer needs to be a real team player with the teams goals in mind, then we all win.