I’ll never forget the first time, I made a gaffe. I had no clue what my colleague was actually doing in his role of a web developer.
I had no experience in web development and somehow I just said: ”That cannot be that difficult, right?”
Ups. I just made a big mistake.
My colleague on the other side, simply looked annoyed. And a bit frustrated. So, please do me a favor, and avoid the following phrases. Simply avoid saying these things. Please.
1. “How hard can that be.”
I guess it’s one of the most-used phrases non-developers use in order to annoy developers. That can’t be that difficult. How hard can that be. Similar phrases are (which of course I also recommend avoiding):
- Why does that take soooo long?
- Can’t you just speed it up a bit and do it faster?
No matter, which kind of phrases you use. If you try to be the development expert as a non-developer, you won’t have any chance to win that game. Trust your developer’s expertise and rely on strategic HR management to ensure you have a capable and skilled development team in place to drive success in your projects.
What to say instead:
- Could you please give me some insights on how the resource calculation was done?
- Which sub-tasks need to be completed in order to finish that project?
2. “I don’t know how to code, that’s your job.”
Well, ok. Obviously, you do not know how to code and it’s definitely not your responsibility in your project or company.
But I heard this sentence quite a few times when people don’t feel confident talking with a developer. And the main reason is that people don’t know enough to feel confident.
“I don’t know how to code, and that’s your job” often simply describes the shortcut non-developers try to go. Instead of actually thinking and dealing with the task.
What to say instead:
- I do not know how to describe that problem. Would you mind helping me out?
3. “My neighbor’s son can do that for $10 an hour.”
Well, that’s great. Please go to your neighbor’s son and hire him. He might even be a great developer. But chances are high that he’s not doing it on a professional level.
Don’t compare your developer to a 16-year old geek.
What to say instead:
- There’s nothing to say instead. Simply don’t say this to any developer working in a professional environment.
4. “So, you’ve only written these few lines of code in … days?”
This is quite a common mistakes a lot of non-developers fall into. Judging the work of a developer by the amount of lines of code written is truly a big one.
You don’t judge your project manager by the amount of emails she wrote, right? So, better do not judge your developers by the amount of lines of code they write.
It’s even the other way around. The less code, the better.
Developers spend a majority of their time actually not writing code but doing other things than programming.
What to do instead:
- Instead of judging developers, find ways on how to gain insights on the key metrics of developers. Learn the basic concept and technologies in order to understand what a great developer actually achieves.
PS: This also can be applied the other way around. Developers claiming to have written a certain amount of code can’t be taken too serious.
5. “You haven’t done your job. There are bugs.”
If a developer spends 90% of his development time debugging his own code, it usually means that the codebase is not that good.
However, a statement like ”I found a bug – you haven’t done your job” is quite a harsh one. Bugs can and will always occur in your software. It’s just a question of culture on how you deal with these bugs and errors.
What to say instead:
- I found this critical bug and filed a bug report. Could you please investigate on this one?
6. “You just need to copy this app and make it a bit fancier.”
As non-developers find it hard to communicate their requirements and ideas, they tend to downplay their requirements hoping that the task doesn’t take too long to be executed by the developer.
Similar phrases go like this:
- “I just have this tiny little change request”
- “It’s just a minor design change, you don’t need to change the whole system.”
And sometimes change requests from customers and non-developers sound pretty weird and remind me of this video.
Wrapping it up.
There’s a lot of miscommunication out there. Especially with technologies becoming more widespread (and sometimes more complex), the communication between developers and non-developers has become quite a challenge.
Bringing everybody on the same page isn’t that easy if you speak different languages.
Resolve issues faster with visual bug reporting.
Simplify and reduce issue & bug reporting efforts with screen recordings, screenshots, and annotations.
And if you’re ready to try out a visual bug tracking and feedback solution, Usersnap offers a free trial. Sign up today or book a demo with our feedback specialists.
