“You do what?” comes the question in the kitchen at parties.
“I write software, I’m a programmer” comes the reply.
At which point the audience divides into two groups … those who glaze over and reach for another drink or wander off into the front room wiggling their hips as if they are about to start dancing, and those that are interested and start asking questions.
And then these questions are then sub divided into two groups … those that understand what programming is, and those that have a problem with their computer who think that a “programmer” must know everything about computers and related topics, and is possibly free next Saturday to pop over and mend their printer.
So these two groups are now fairly distinct and have totally different ideas about what this person actually does for a living.
Group A, the people who understand, start asking questions about the development tools they use, what database they use in their applications, and this is where we start to see the shapes and sizes emerge based on their questions.
Some of these people are evangelists and will ask loaded questions so that they can tell you what is right … and anything you say will be wrong, even before you answer. A good example of these is the free OS, free database, open source community who are basically in open defiance of anything Microsoft or Apple, and whatever you say cannot be bettered. Rather than talk about the merits to the business of going in this direction it will be out and out war.
Some of these people are fairly open minded about any development environment and work in whatever the customer requires. And others are not really programmers … but they have built some applications in the past using MS Access or FoxPro (3GL/4GL languages) and to be honest get lost fairly quickly with real developers.
Group B, are the people that do not really understand what programming is, but they have unrelated questions coming thick and fast. They have no concept that Microsoft had to have a team of developers to build MS Word, they simply think “it comes on a disk”. They think that their 12 year old son is a budding computer geek because he spends all night on his computer and can “magically” reconnect their new printer when the old one died and they purchased a replacement. Or that he knows how to connect to the wifi when it breaks.
So what I am trying to say is that these people are another breed.
If you are a developer then your brain works slightly differently to others.
Programmers enjoy a reputation of being “peculiar” people in the good sense of the word. I often say developers are binary rather than analogue. It is either “yes” or “no”, not “maybe”. If it is “maybe” they will want to normalise this “maybe” down to a rule of “yes’s” and “no’s”. They will tend to clear a Su-Doku fairly quickly but struggle with the “greyness” of a crossword. But these are more of a generalisation, and are not always the rule.
But there are several types of developer … let me give them all a title. And at the same time emphasise you need the qualities of all of these in your team somewhere. Some of these traits can be dangerous on their own for a project delivery … but within a team are a must, and cannot be missed.
Well usually the look gives at away. Could they really be mistaken for a wizard? Beard, long hair, the clothes they wear. I did know of a guy called Gandalf who was a Unix programmer … I’m sure his path was destined as soon as he was born and named! Great people to have on your team because these people are low level … but be prepared for the stories about punch cards and the history of computing.
The 24 hour Worker
These developers start working again at home … usually just to convince others in the team that they are not up to the job, and really need to switch off and have another life.
But, when a project needs delivering and the weekend is the only time to finish the work … they are the first to put their hand up.The Game Player
These people go away at weekends to play 24 hour online gaming, they know why one game machine is better than another and only stop playing a game when they reach 100% completion and everybody knows about it.
But when the architecture of a development project needs a higher more logical level of thinking, these people are the ones you turn to. They will treat the complication like a logical game play solution.
Rock ‘n Roller
Normally listening to heavy metal all day long on headphones, these developers are “hard core”.
Don’t take them onsite. I did this once in central London for a very large investment bank. He turned up on his Harley, dressed in leathers and a “manga” t-shirt of a couple in a sexual position. When he was asked to show us his ideas on the whiteboard instead of walking around the table … he got on the table and walked up through the table in his biker boots!
These people are normally great to be with, enormous fun and really do get the job done.
These developers can be a force of nature. They are like whirl winds. They start developing before you end up describing the project. Code just seems to churn out so fast you cannot get a grip on where the project really is. Consequently testing can fall by the wayside, and code can get messy. They tend not to check their work in frequently, struggle with a change here can break the application over here.
But, do you have a “proof of concept” that needs completion just to test functionality? Do you have a “bug” you need to find quickly? These are the people for you. Managed well and really closely they can turn out code faster than the rest of the team … just be careful when “mopping up”.
The Stealth Merchant
These people work under cover. When an issue is on the table for working on tomorrow … you find that they cleared it, found the problem and checked the code in last night at 11:30pm. They may have any traits of the above, but also are working in “stealth mode”.
Trust them, work with them. Bring them into project meetings. They will rarely contribute anything at the meeting … just take it offline and do it.
The Little Professor
This people have the answer to everything. No matter what question you ask them they have an answer, even though you know they are guessing and making things up. Quite a lot of the time they are knowledgeable responses, but they don’t know everything. And because of this you tend not to trust the responses when they do know.
In business terms they are dangerous, and a lot of organisations have a means of filtering these people out at interview stage.
What you need them to say is “I don’t know, but I will go and find out”. Acknowledge that no one person knows everything.
These people need careful management but if you can train them correctly, they will be the font of all knowledge … once they understand that owning up to not knowing is a good thing … and is an opportunity to go and find out.
And so it goes on … there are many types of developer, and in the end you need all of them in differing proportions.
A good development team has all of these types of people but also understands that there is quite a management task here.
Choosing who accompanies you on site from the development team can also be a challenge. Most of them just want to sit in the corner quietly and produce code.
Understanding that there is a marketing and sales process before them that is responsible for getting the development project in the first place can also be a challenge unless they are part of an in-house development team.
In which case they need to understand the business reason for them being there. If they are not productive and value for money, then the development could easily be outsourced.
But to not have been in development for many years, and working with developers of all traits and experimenting with new technologies? I wouldn’t change things for a minute.
Ask me what I do in the kitchen at a party … no I’m not part of a development company, I’m anything else. I want my Saturday mornings back please!