不要對一個程序員說：你的代碼有Bug。

他的第一個反應是：1. 你的環境有問題吧；2. 傻逼你會用嗎。

如果你委婉的說：你這個程序和預期的有點不一致，你看看是不是我的使用方法有問題。

他本能的會想：操，是不是出bug了！

Despite the urge to immediately dismiss this for being biased and protective of engineers, there are some really valuable lessons for anyone dealing with the delicate engineering crowd.

Based on the meme above, here are 4 tips on how to get an engineer's support and achieve what you want with product issues.

Tip 1: Assume that it's you who don't know how to use a feature / product.

A lot of times there are some non-obvious reasons and use cases for why a certain feature / product is developed the way it is. That reason or use case might be far off from your own expectation of how to use the feature but it doesn't mean there is a bug. By always having this assumption, you can prevent a lot of nasty arguments with engineers.

Tip 2: Try to replicate the issue.

As much as possible, if you cannot replicate the problem / issue, do not report and ask for help. Try to replicate the issue on your own testing account or environment first before escalating it. When escalating it, always remember tip 1 and assume it's you and your customer who don't know how to feature.

Tip 3: Package your words.

No one likes being criticised. As a marketer or product person, if others criticise you of your copywriting or product idea, you'd immediately have your guards up in defence. Similarly, if you criticise engineers of "creating bugs", that's also a direct attack on their hard work. Regardless of your good intentions in trying to help clients or improve the product, it's hard not for engineers to feel attacked with such a direct criticism.

A better way is to package your "issue / bug" as expectation not matching with reality. You or your clients expect a feature to work a certain way to achieve a desired result. But when using the feature, the expected result didn't arrive. First, refer back to tip 1, if you can confirm that you know how the feature works, try tip 2. If you can consistently replicate the issue, then try escalating it to engineering team in a nice expectation ≠ reality way and don't assume it's a bug immediately.

Tip 4: Dumb down.

This tip is especially useful for type A personalities who like to tinker with things and figure things out alone. Stop. It will backfire when used with engineers.

Do not assume you know the reason behind why a feature didn't produce the expected result. Do not tell engineers your assumptions. Just tell them the expected result and how you replicated the issue.

You didn't develop the feature, they did. What makes you think you know how it works and why it failed? This tip will save you from looking like a clown in front of engineers.

That's it — 4 easy tips on how to earn an engineer's trust and get what you want.