How to ruin your software engineers
Why am I writing this article? Well… recent developments in my company made me think that there is a need to state the obvious for us (call it software engineers, developers, programmers or whatever you want), the decisions made by the business department that can lead us into decay…
A business director’s dream is to have people specialized on their field that know their applications inside out and can perform changes in a few nanoseconds… Ok, that’s not bad you might say, but what happens when you have this person occupied on this project for a few years? He has (hopefully) created a solid system that needs a few minor adjustments here and there. If you leave him responsible of this system you will end up with an experienced engineer who ends up doing such minor jobs as changing a few texts or colors in a view. While he/she could be used in order to create another major system on the company, he is occupied with tedious tasks, and as a result he loses any interest to job and the company loses a valuable asset for the development of other projects. Solution: Get a Junior Developer to learn how to do these tasks and free the main developer of his duties and let him offer his potential to other projects. Can’t afford a new developer? Establish a rolling scheme between the various development positions in your company in order to avoid (simply put) boredom. As a plus there will be always some kind of fail over if on of the developers decides to move on and leave the company.
No matter how good a developer is, there will always be something on the output he provides that should be corrected… Sometimes this is due to incorrect specs, sometimes he has made something wrong, sometimes the specs changed somewhere in the way and he never was informed. First of all, if he doesn’t get correct and up to date specs, he shouldn’t be blamed for this output. Second, if there is something wrong, there is no use in catching minor errors and going back and forth between him and the testing team. The latter should gather ALL the errors and only then provide feedback to the developer. If the people performing the tests aren’t educated enough (i.e. having account managers performing the test instead of a qualified QA team) the testing phase can be turned into an infinite loop leading to the same consequences described above. (btw saying “there is something wrong, fix it” is not enough… please spare a few seconds to describe what the issue is and what step you have performed in order to come into this state)
Have the developers speak their say. Consult them whenever you face a problem. They will be more qualified to present a solution and even if it’s not viable, if they see that their opinion counts they will be more content in their position. They are not just tools upon your disposal, they are important and make them feel so. Even if you don’t see a problem, let them propose ways to improve the way things are done. They can foresee things a business person can’t.
Last but not least, give them room to breathe. Let them experiment in the way things can be done. Let them have their precious side projects. They can make them keep up with latest technologies (which they can latter on use for the company’s projects) and even provide you with your next hot project. Whenever you see them buffed with their everyday responsibilities, cut them some slack and let them work with something more interesting. Maybe even provide it to them if your time schedule allows it… tell them to experiment with x/y/z on the next project.
Contrary to what some people may think, developers are some of the most creative people I’ve met… If you kill their creativity having them do tedious tasks, you are killing a part of them… There is a beauty in coding that most people can’t see. If you see one that doesn’t appreciate it and sees it just as a job, maybe you have found the one destined to perform these tasks, he might be good at his job, but he will never be a great programmer. The ones who do though, have the possibility of becoming great programmers. Let them express their selves.