The job of a developer is complex and sometimes confusing. In order to keep your developers sane, here are the top ten things not to say.
In this modern digital world, where bits are replacing atoms left and right and software is eating everything, software developers have become worth their weight in gold. Bill Gates once said, “A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” He couldn’t have been more right.
In the book, The New Kingmakers, author Steven O’Grady explains that power developers transform a business and drive its success (or failure) more than ever before. Yet, with the overwhelming evidence that shows we should be treating our developers and engineers as our most precious assets, businesses still seem to infuriate them off on a regular basis. The time has come for an intervention.
Avoid uttering the statements and questions below, and you may never piss off your developers again!
Related Article: Completely Own Your CEO in Six Steps
“Can’t we just…?”
Assuming you understand the complexity of a problem and suggesting how easy it should be to solve, when you likely don’t understand the implications, drives developers crazy. Statements like this serve only to breed resentment between developers and business.
“Sorry to bug you, but...”
Interruptions are the worst! Software development requires organizing many complex pieces of information in your head simultaneously. Context switching due to interruptions is probably the quickest way to disrupt that process. It’s been estimated that around 25 minutes of productivity are lost from each interruption, according to a NY Times article.
Tip: if the headphones are on, back away. Send an email rather than an IM or just walking up to interrupt.
“Whatever is the fastest solution.”
An ever expanding technical debt ceiling drives developers mad. Taking short cuts in the short term almost always result in more work and pain plus interest in the long term. Trust your developers to make good recommendations about what technical debt is acceptable and what is unacceptable.If they’re pushing back on a short cut, it’s likely with good reason.
Developers who never push back on short cuts are either not worth their salt, or not in it for the long term. Just as important as avoiding technical debt is affording them the time to clean up debt later when they need to.
“This isn’t what I wanted at all!”
Successful software development is highly dependant on cooperative, available, and engaged stakeholders. Make sure you’re giving feedback during the development process; not just at the completion of a project. Good developers will be checking in with you during the build to make sure they’re on the right track. Make sure you give quality feedback and if you’re not hearing from them, check in.
“You did a great job, but we’re going in a different direction.”
Spending all the time and effort to complete a project to never have it see the light of day will turn your devs into a racecar driven past the red line. In some cases, these scenarios are unavoidable, but make sure you do your due diligence to confirm that you’re asking for something that will deliver value to the business. If there’s a change, and you need to change direction or you’re building the wrong thing, communicate the change as early as possible.
“We need this completed by next week.”
Deadlines pulled out of thin air will drive any developer mad. Software development is not like building a house. It’s more like creating a work of art; each piece is unique and different. Focus on delivering small incremental value to the business. Big projects with a large cone of uncertainty can not be estimated accurately. Human beings are notoriously bad at time estimation and developers are probably even worse than the average (due to the complexity of their work), so cut them some slack.
Related Article: Hiring? 10 Interview Questions to Ask a Software Engineer
“This design looks great, let’s build it.”
Not thinking past the visuals is among the worst infractions you can commit. Designers often create visuals based on best case scenarios. Make sure you’re thinking through the implication of real world scenarios and focusing on functionality, not just design.
“How does this work again?”
Not understanding your product isn’t going to cut it. If your developers have built features for you, they expect that you’ll understand why they were built. Be interested enough to learn how to use them. If you’re not sure, it means you’re not using the product and it was a waste of their time to build.
“We definitely have feature X.”
Repeat after me, “Don’t sell vaporware”. Selling your customers on features that don’t exist will lead to rushed projects that aren’t planned, thought through, or executed properly. Even worse, you might end up building something that only one customer cares about and waiting precious development cycles. Selling futures is one thing, but never make promises about functionality you don’t have.
“Can you fix my email?”
I’m sure the kid down the street who can build websites, also did a great job getting your new computer setup. That doesn’t mean your developers should be solving your general tech issues. If you don’t have an IT helpdesk, get one. If you can’t hire for it in house, contract for support with a 3rd party. While your devs probably can solve your issues, it’s the last thing they want to do. Expecting them to do so will encourage them to start looking for the door.
Bonus: “We ‘Dress For Success’”
If you have a more than casual dress code, give the developers a break. You may want your client facing staff to be dressed to a higher standard, but don’t ask the same of developers. No one wants to write code in a tie!