This is great advice. Just today I had a similar issue. I wrote some code a long time ago, and a new coworker who started about a month ago comes up to me and proposes an alternate solution. He asked why we didn't do it this way instead of the way we were doing it now. In his mind, his solution made perfect sense.
I knew I was right, and I knew my solution was the best solution, because I'd spent months thinking of all the possible ways to solve the problem, and this was the best of them all.
But the point is that he asked, and the point is that I had to revisit that decision. I considered what he said, and I explained my rationale for going with my solution. By the time I was done, he was nodding along and saying "Yeah, that makes perfect sense."
I think it's okay to be right and to know you're right, but if someone questions you, or if a test fails, or if conversions go down, you should be willing to stop and re-examine your assumptions, and if necessary, explain them again.
I'm very glad my coworker brought his ideas to me, because it validates that my solution was, in fact, correct. And if my solution hadn't been the best choice, he would have brought a better solution. So in the end, it's a win-win...
Assuming you're wrong at first blush is almost always the right move. It lets you consider alternate solutions, and hopefully rebuild your defense of your current solution. If it still holds up, you're good. If not, your new assumption is right (that you're wrong).
I think I have a headache now.
I also have a similar rule, but from a slightly different perspective. I credit it as one of the reasons for me being as successful at my company as I am.
When someone comes to me and says there is a problem with the app, I assume it's my fault. I assume it's a code problem. I rule out any responsibility on my part (or that of my team) before I go back to the complainer and ask them for more information. I never, ever, ever say "it works for me."
Remember: people don't complain about things that work. Even if it's their fault, even if they screwed something up, even if it's not your code that's broken, something isn't working for them. If it's not working for them, then it's up to you to figure out why. It may be that your instructions were unclear, or maybe it's a client-side issue (like an ad-blocker) that you can't reproduce. Or maybe your customer really is a moron.
But before I ever go back to someone and tell them I'm good, I make sure all my ducks are in a row. The last thing I want is to belittle someone else's problem because I think I'm awesome.
I knew I was right, and I knew my solution was the best solution, because I'd spent months thinking of all the possible ways to solve the problem, and this was the best of them all.
But the point is that he asked, and the point is that I had to revisit that decision. I considered what he said, and I explained my rationale for going with my solution. By the time I was done, he was nodding along and saying "Yeah, that makes perfect sense."
I think it's okay to be right and to know you're right, but if someone questions you, or if a test fails, or if conversions go down, you should be willing to stop and re-examine your assumptions, and if necessary, explain them again.
I'm very glad my coworker brought his ideas to me, because it validates that my solution was, in fact, correct. And if my solution hadn't been the best choice, he would have brought a better solution. So in the end, it's a win-win...
Assuming you're wrong at first blush is almost always the right move. It lets you consider alternate solutions, and hopefully rebuild your defense of your current solution. If it still holds up, you're good. If not, your new assumption is right (that you're wrong).
I think I have a headache now.
I also have a similar rule, but from a slightly different perspective. I credit it as one of the reasons for me being as successful at my company as I am.
When someone comes to me and says there is a problem with the app, I assume it's my fault. I assume it's a code problem. I rule out any responsibility on my part (or that of my team) before I go back to the complainer and ask them for more information. I never, ever, ever say "it works for me."
Remember: people don't complain about things that work. Even if it's their fault, even if they screwed something up, even if it's not your code that's broken, something isn't working for them. If it's not working for them, then it's up to you to figure out why. It may be that your instructions were unclear, or maybe it's a client-side issue (like an ad-blocker) that you can't reproduce. Or maybe your customer really is a moron.
But before I ever go back to someone and tell them I'm good, I make sure all my ducks are in a row. The last thing I want is to belittle someone else's problem because I think I'm awesome.