Software geeks work in mysterious ways, also in strange hours. That they are also highly paid makes others wonder if this is just a big scam. These people created all those bugs and then demand high compensation to fix them! At the same time, the products are never ready or good enough in time for selling. Besides, they come in late and disappear in the mid-afternoon. This is just anarchy.
Can you ask a musician to work 10 hours a day so that he can compose more music than 8? Preferably, 25% more? In fact, can you expect the same for any professional or creative jobs? Sales, lawyers, doctors, painters, writers, etc. Is “hard working” a valid concept for these jobs? If so, what does it mean?
There are many indicators for productivity: hours of working, lines of code, number of “check-in units,” amount of discussions, schedule of projects, etc. Then there are various ways to measure quality of work: review comments, bugs found, customer feedback, support cases, etc. Over the decades of this software industry, we have pretty much concluded that none of them are definitive but all of them are partial indicators. Therefore, if willing, a manager can track several of those mentioned above and arrive at a very reasonable metrics for productivity and quality of work for any individual software engineer. At least those not yet in pure architecting roles.
But so what? If I have concluded that individual is not productive enough, what can be done anyway?
The most effective way to motivate a software engineer is to challenge him/her with an interesting project. The best way to find interesting projects is to ask the person, “What can be done to make … better?” (Insert managerial creativity.) The variation of that is, “What else can we use … for?” (Insert something you have abundance: computing cycles, spare parts, expertise, etc.) After getting answer, offer some thoughts and opinions, send the person to talk to some more people, and request to chat with him/her again in a couple of weeks. In that second meeting, encourage some prototypical or experimental works to be done. The rest will be automatic.
Of course a manager can always demand more professionalism from the works. Be direct and make the request:
- How was it documented? Was training considered?
- How thorough was error checking? How was that part unit tested?
- How diagnosable when things go wrong?
- Is it scalable? Multi-threaded? 64-bit safe? Internationalized?
- How does it affect system performance? How do you know?
- How testable is it? Can that be automated?
Not only these questions make the code better, they also make them better engineers. If the answers to them are all positive, then you can promote the engineer and ask him/her to inspect others’ work.
This is why good engineers work that much harder and average ones are bored.