What motivates programmers?
I will start with a question, if you have a spare £400 in your development budget do you A) Reward your star programmer with a £400 bonus or B) Buy him a 24 Inch 1920x1200 LCD screen?
If you answered 'A' then you need to read on. If you answered 'B' then you understand what motivates programmers but I suggest you still read on and comment later if you have any ideas beyond what I cover.
One of the things that they never teach non-programmer managers is how to motivate programmers. You may think the programmers are motivated by the same things as the rest of your staff, you are WRONG. Programmers tend to be counted within the higher IQ brackets and are therefore harder typically to second guess.
The average programmer may be projecting an image of superiority but non-programmers miss-read this and think it is aimed at them. It is not. You have to understand that programmers rate themselves against other programmers not against anyone else.
This is important when making any decision about how to reward them. If you purchase some new equipment for your sales staff the likely reaction will be ... nothing. If you purchase new equipment for your programming staff they will immediately start analyzing who has got what and by reference who is being rewarded more than others based upon the quality of the equipment. If you think this is not relevant think again.
What this comes down to is that the work environment is generally more important to a programmer than any kind of financial reward (within limits). But managing who gets what within your company is not easy.
You can just take the view (and if you have a big enough budget) that everyone is standardized and that you all get the same equipment. This in practice within a development environment never works because each programmer may require a very specialized setup which breaks the standardization rule and your back to 'who gets what'.
Hardware Cascade
Programmers outwardly will try and give the impression that they are a loose nit bunch who care nothing for standard business practices and certainly not give any importance to the usual office politics of who is above who. This all goes out the window with new equipment because the hardware is seen as a status symbol within the 'non-existent' programmer hierarchy.
So when upgrading machines it is vitally important that you understand the structure of this invisible hierarchy. I typically upgrade at the top of the tree and push machines downwards, this can mean lots of re-installing but most programmers will be very happy to put in extra hours to perform the re-install if the reward is a new machine (or at least a faster machine)
The appeal of solving a problem
Programmers program because they love to solve problems. Remember this rule:
“"If you give a programmer a job that does not involve solving something they will become unhappy."”Solving can mean many things and it is easier (and more important) to understand what classes as a 'non-solving' task. Typically asking a programmer to go fix something would be classed as 'non-solving' as the solution has already been found and you are asking them to re-solve it by having to look at the code again.
What is important is that you find ways of making 'non-solving' tasks into 'solving' tasks. A typical example would be the difference between asking one of your programmers to put together a report (e.g. some usage statistics) by hand or assigning him more time so he can 'solve' something and produce an automated system that will email you the report every day/week/month. Other typical non-solving situations
•Writing documentation
•Creating schedules
•Writing reports
•1st Line Support
All programmers have to perform non-happy-non-solving tasks and some cope better with dealing with a higher 'non-solving' ratio of tasks than others. Understanding your programmers and who can cope with what level of 'non-solving' is important to keeping an overall smooth operation.
Meetings
Programmers see meetings as wastes of time. Most communication between programmers is done via email or by a quick wander to another desk to clarify something that is beyond the scope of an email. Therefore any time within a meeting room is 'unhappy time' and unhappiness increases exponentially with the length of the meeting. So at all costs if you do need to drag your development team into a meeting either include some form of Lego to play with (I am serious) or keep them very short.
If you answered 'A' then you need to read on. If you answered 'B' then you understand what motivates programmers but I suggest you still read on and comment later if you have any ideas beyond what I cover.
One of the things that they never teach non-programmer managers is how to motivate programmers. You may think the programmers are motivated by the same things as the rest of your staff, you are WRONG. Programmers tend to be counted within the higher IQ brackets and are therefore harder typically to second guess.
The average programmer may be projecting an image of superiority but non-programmers miss-read this and think it is aimed at them. It is not. You have to understand that programmers rate themselves against other programmers not against anyone else.
This is important when making any decision about how to reward them. If you purchase some new equipment for your sales staff the likely reaction will be ... nothing. If you purchase new equipment for your programming staff they will immediately start analyzing who has got what and by reference who is being rewarded more than others based upon the quality of the equipment. If you think this is not relevant think again.
What this comes down to is that the work environment is generally more important to a programmer than any kind of financial reward (within limits). But managing who gets what within your company is not easy.
You can just take the view (and if you have a big enough budget) that everyone is standardized and that you all get the same equipment. This in practice within a development environment never works because each programmer may require a very specialized setup which breaks the standardization rule and your back to 'who gets what'.
Hardware Cascade
Programmers outwardly will try and give the impression that they are a loose nit bunch who care nothing for standard business practices and certainly not give any importance to the usual office politics of who is above who. This all goes out the window with new equipment because the hardware is seen as a status symbol within the 'non-existent' programmer hierarchy.
So when upgrading machines it is vitally important that you understand the structure of this invisible hierarchy. I typically upgrade at the top of the tree and push machines downwards, this can mean lots of re-installing but most programmers will be very happy to put in extra hours to perform the re-install if the reward is a new machine (or at least a faster machine)
The appeal of solving a problem
Programmers program because they love to solve problems. Remember this rule:
“"If you give a programmer a job that does not involve solving something they will become unhappy."”Solving can mean many things and it is easier (and more important) to understand what classes as a 'non-solving' task. Typically asking a programmer to go fix something would be classed as 'non-solving' as the solution has already been found and you are asking them to re-solve it by having to look at the code again.
What is important is that you find ways of making 'non-solving' tasks into 'solving' tasks. A typical example would be the difference between asking one of your programmers to put together a report (e.g. some usage statistics) by hand or assigning him more time so he can 'solve' something and produce an automated system that will email you the report every day/week/month. Other typical non-solving situations
•Writing documentation
•Creating schedules
•Writing reports
•1st Line Support
All programmers have to perform non-happy-non-solving tasks and some cope better with dealing with a higher 'non-solving' ratio of tasks than others. Understanding your programmers and who can cope with what level of 'non-solving' is important to keeping an overall smooth operation.
Meetings
Programmers see meetings as wastes of time. Most communication between programmers is done via email or by a quick wander to another desk to clarify something that is beyond the scope of an email. Therefore any time within a meeting room is 'unhappy time' and unhappiness increases exponentially with the length of the meeting. So at all costs if you do need to drag your development team into a meeting either include some form of Lego to play with (I am serious) or keep them very short.
Comments
Post a Comment