Most developers enjoy their work, whether they are part of a development team, a free-lance developer or a single, in-house developer for some company somewhere. Developers are usually very clever and creative people, solving complex problems never solved before and coming up with new innovative ways for people to do things more efficiently.
The one thing developers don’t do particularly well is read the minds of the people they develop solutions for. This might seem an obvious observation, but most developers will tell you of the people they deal with that expect them to be mind readers.
The first problem is that most people struggle to convey their thoughts and requirements in a meaningful way to the developer, expecting the developer to instinctively know how you want a certain solution to work or behave. This isn’t the case. Work with your developer before they start work on your solution to make sure they understand what you want. Create a statement of requirements to outline the key features you want, how you want them to work, and how you want user interfaces to look, even if it’s just a rough drawing to show layout and some crayons to show the colour scheme required. Your developer will thank you, trust me.
Secondly, don’t try to pretend you know all about development when dealing with the developer, even if you do. You might well be, or have been, a developer yourself, but at the end of the day each developer does things their own way and you trying to tell them how to do it just gets their back up. Don’t forget, you are asking the developer to create something for you, not paying them to listen to how you would do it.
Another way to piss a developer off is to provide a statement of requirements, and then proceed to change your mind once the developer has started working on the delivery of your requirements. It doesn’t matter that you are paying the developer for his or her time, changing a software solution half way through development usually involves deleting code that the developer has spent a lot of time writing, and always leads to delays in delivery. It might mean more money for the developer, but what if the developer has booked his or her time out to another project or customer and your “tweaks” means they are unable to start the next piece of work.
Now you might be thinking why you should care if your developer is pissed off if you are paying for his time. I’ll tell you. A pissed off developer is a stressed developer, and a stressed developer makes more mistakes in the code, leading to bugs. This isn’t a deliberate act of vengeance for all the times you did successfully piss your developer off, its simple psychology. When people get stressed, they try to get out of the stressful situation as quickly as possible. This can lead to lapses in concentration and even corner cutting to get the job done quicker, meaning more bugs in the end product.
Don’t get me wrong, bugs happen. It’s impossible to write software without bugs (except maybe print(“Hello World”);). All I’m saying is there is an increased probability of bugs if you piss off your developer.