Loreleen Mae Sablot

Never assume the other party is wrong. I think developers have a tendency to blame everyone else for their code not working. You become protective over the code you write, to the point where you are convinced it can’t be wrong. If QA tells you they’ve run into an issue, they have a reason for doing so. It won’t cost you much to give them the benefit of the doubt, and they’ll appreciate it more than being shut down.

Never assume someone understands what you’ve told them, even if they say they do. This is one I learned after progressing in my career to the point where I was helping to mentor more junior developers. I found that I would rifle through instructions, and follow up the next day to find the developer in question hadn’t made much progress even though they had said they understood perfectly what was required. Instead, get the person to give you a walkthrough of what’s been discussed so you can be certain they understand. This applies to more than just mentoring developers, such as explaining something to BA’s/QA’s etc.

Never assume that someone will do something just because you’ve asked them to. Always get an explicit agreement. Haven’t received a reply from someone you asked to check something? Send a follow-up. If something is important, it’s important enough to follow-up on.