Separating junior developers from the experienced When I was a junior developer there was a certain saying people knew me for. I repeated it again and again. It even bothered me that I had to say it so often. I said it when customers encountered bugs. When customer support claimed something I “fixed” was still broken. When new features released with poor feedback. It works on my machine! When customers faced issues, my default reaction was to blame them. I would never release something to production that I knew didn’t work. I would have noticed something as obvious as that. This is your fault. Go back and try again. It took me a long time to recognize that a pattern was forming, though. There were a handful of times where it was user error. But most of the time, the user would come back to me and claim they were still experiencing the problem. “It works on my machine. Let’s go see what you’re doing wrong… Oh.” It Doesn’t “Work” if the User Doesn’t Understand When comparing my user’s workflow to mine, I often was able to deduce that their issue wasn’t actually a problem. They were doing something wrong. I would tell them what their problem was, give them instructions, and call the issue resolved. This is wrong for many reasons. First, you’re telling the user they were wrong. That it’s their fault. No one likes to be wrong. They’ve already had a poor experience using the product, and now they’re told it’s their fault. It takes a lot of patience to stick around after all that, and most users don’t have it. Second, if one user had a problem, odds are they are not the only people that think this way. Two issues will come from these users. The problem will keep popping up. So either you or customer support are going to be stuck answering the same question over and over again. Others will think the it’s a broken feature, and not say anything about it. These guys are not going to stick around for long. And unlike the complainers, you’ll never know why. User experience problems are just as important as bugs. They separate great products from mediocre ones. It doesn’t matter if you agree with how the user got to their error state or not. Our goal as developers is to get the software out of the way of the users’ goals. Process All User Feedback Over the years I have realized how valuable user feedback is. More importantly, I’ve realized we must deal with every piece of user feedback in some way. No doubt, some feedback is going to be garbage. They want something no one else wants. By implementing their change it would cause issues for the majority. It’s not worth the time. But we should still document and quantify it somewhere. This way we know what our users are saying. More than that, it encourages the user that their feedback is helping improve the product. This is much better than telling them they were wrong. That the developer had no problem getting it to work, and that it’s their fault. To be clear, this goes for customers and internal teams such as QA alike. When someone is testing your feature, the last thing they want to hear is how great it works for you. Work with your testers to iron out user experience issues before they get to production. Your customers will thank you. This is a Junior Developer Saying From Don’t Hit Save Source As I’ve progressed in my career, I’ve come a long way from the guy whose computer worked so well. It can be difficult to swallow sometimes. But I know that if someone had an issue with something I worked on, I made a mistake. I missed something. I didn’t take a certain use case into account. And as I’ve worked with more and more developers, I see that this is not a saying experienced developers use. They realize their users are not liars and have valuable feedback. Junior developers, though, use it frequently. Part of the reason junior developers are so apt to disagree with feedback is that they take it personal. Bad feedback is an attack on them, not their product. They get defensive. What do we do when get defensive? We deflect. It’s not my problem, it works fine for me! This is on you. What did you do? We all have to realize that feedback, good or bad, is not about you. Feedback is for a feature or product. Us developers are not defined by a bad feature. Nor are we defined by a good one. Developers are defined by how well we solve problems, no matter who it is that is experiencing them.
