In today's episode, we talk aboit disambiguation and using clear words during feedback sessions.
In today's episode, we talk aboit disambiguation and using clear words during feedback sessions.
Today's episode is sponsored by Rollbar. With Rollbar, you get the context, insights and control you need to find and fix bugs faster. Rollbar is offering Developer Tea listeners the Bootstrap Plan, free for 90 days (300,000 errors tracked for free)! Head over to rollbar.com/developertea now for the free 90 day offer!
If you work in an environment where you go through multiple rounds of feedback, especially if you go through multiple rounds of relatively unstructured feedback, then you probably have dealt with what we're talking about today. Basically, the symptom of what we're talking about today is that you're having multiple rounds of feedback seemingly with no light at the end of the tunnel. And even though you're listening intently and you're trying your best to accomplish whatever it is that the feedback is asking you to accomplish, there's still some lost in translation issues. There's still something that isn't quite making it from the person providing you the feedback to you, the developer or designer. Something isn't quite translating. That's what we're talking about on today's episode of Developer Tea. My name is Jonathan Cutrell. You're listening to Developer Tea. My job on this show is to provide you with the insights and the information, the inspiration, the interviews, all of these different types of conversation really in this podcast that we do. All of this is pointed at helping you become a better developer, to help you level up as a developer. Regardless if you are a developer or not, you can listen to this show and still gain something from it. Something that we wanted to do from the very beginning is try to make most of the episodes applicable to people who are coming to the show who aren't necessarily a full-time developer and especially focus on people who are working in the digital space. So if you're a designer, today's episode for example is still completely applicable to you. But of course the goal is to help you developers who are working in this industry become better at what you do, build better products, build better experiences for people. But we aren't just focused on your output. We're also focused on your life, the quality of your job, how you are seeing your life, the perspective that you have, the values that you hold. Our goal on the show is to help you become better in all of those things. So that is one of the things we're talking about today. And really today's episode is like many episodes before it, language. It's about language. And it's about how we talk about what we do and how we talk about the things that we make, not only when we are presenting the things that we make, but also when we're working on and iterating on the things that we make. So I presented this scenario at the beginning of the episode, the constant round of feedback, the seemingly endless tunnel, no light at the end of the tunnel, kind of feedback rounds. And there's something that all of these endless feedback loops, or at the very least the majority of them, they all have this in common. And that is loaded words, loaded words. So one of those loaded words, for example, is creativity. When one person in the room says the word creative, every other person in the room has their own preconceived notions of what that word means. We may have some culturally shared definition of that, especially if you've been working with another person, or if you have a relatively close relationship where you're talking with this person quite a bit, then you may have some overlap in the word creative. But for the most part, everyone is going to have their own version of what the word creative means. For some people, it means thinking in an unconventional way, or solving problems in an unconventional way. For other people, it means having aesthetic vision, being able to imagine something that is visually pleasing. For others, it is the ability to think in terms of abstract thoughts, or in terms of symbolic thoughts. For example, creating a design system that best expresses the brand's cultural values. Some people view creativity as being able to connect those cultural values to actual visual output. And the reality of this is that there are so many other definitions that you may fill in the blank with here. For some people, including myself, creativity means something entirely different. It means the ability to create something that quite simply previously didn't exist. And that's as simple as I've made the term in my own mind. And sometimes that causes problems. When I'm talking about creativity with a client, when I'm talking about creativity with a coworker. And so this is a loaded word. And that is not the only loaded word that causes problems. We've talked about feel back in a previous episode. And feel back is really pointing towards what this episode is discussing, these loaded words that don't have specific meaning, but instead are open to quite a bit of interpretation. Another word may be another loaded word may be effective. This is very much so an open-ended word. In what way is the thing that you're describing effective? Without reference, the word creativity or the word effective, both of those really become open to interpretation. And ultimately, if you're trying to accomplish something based on this kind of feedback, then you're shooting in the dark. So how can we fix these loaded words? How can we avoid them? Let's talk about a few more loaded words. And then we're going to take a quick sponsor break and I'll come back and give you what I think is a pretty good antidote to the loaded word problem. But another couple of loaded words first. One would be user. User is a loaded word because we may be talking about multiple types of users. We may not have necessarily a perfect archetype for a user nailed down. So a user is a loaded word because it's representing a large group of people usually. Another loaded word is design. Design is an ambiguous thing for most people. And we do have, once again, culturally shared representations of what a designer does versus what a programmer does. And very often we reduce the word design to the visual representation of design rather than allowing the word design to cover, for example, the software or architecture design. That makes the word ambiguous because it very well could extend and be more meaningful if we had a collective understanding that design extends beyond one aspect or another of the design implementation. Another loaded word that we use very often as software developers is the word bug. This is something that we need to be educating our clients about and we need to be educating anyone who has any kind of stake in a project. Whether that's somebody who is participating as a non-developer or are other developers on a project or a client or an actual product owner, these are all people who need to know very clearly what a bug is. And this actually brings us to today's sponsor. Today's sponsor is Rollbar. And with Rollbar, you can uncover errors that are working in your code. That's what Rollbar does. Now you'll note, if you're a good developer, you'll note that an error is not the same thing as a bug. An error will help you find bugs, but errors are not always caused by bugs. If you, for example, are integrating with a third party service, then if you can catch those errors from the third party service, now you can start to understand a little bit easier about what is causing problems in your application. You see, problems, bugs, and errors are three separate things. If you can't catch your errors, if you can't find your errors, then you may find yourself on a bug chase in something that's not even wrong in your code. This is what makes Rollbar so powerful. You can find the errors in your production code, and dealing with those errors typically has been very difficult on the past. You rely on the users to report the errors. Of course, they can't tell you the difference between a third party error and an internal error on your service. So you end up digging through the logs, you try to debug those errors yourself. That is really difficult to do, and it's not going to be working at 2 a.m. when the next instance of that error occurs. So Rollbar will do all of this for you, and it works with all major languages and frameworks. You can start tracking production errors in just a few minutes. Of course, you can integrate it into your existing workflow. You can send error alerts to Slack or Hib chat. Of course, you can link your source code in GitHub and Bitbucket or GitLab, and you can even turn the errors that you're receiving into issues in JIRA and Pivotal Tracker and Trello. Some of the big customers that work with Rollbar include Heroku, Twilio, Kayak, Instacart, Zendesk, and Twitch. These are all massive, massive companies who rely on Rollbar to help them find and remove their errors. You can go and get started for free, though. So these massive companies are using this, and you can get started with the same service by going to rollbar.com slash Developer Tea. That's rollbar.com slash Developer Tea. So how do we deal with these loaded terms? We've listed quite a few, and there are plenty more than you will encounter at all varying degrees of specificity. Sometimes are far more loaded than others. For example, positive user experience. Does that mean that positive user experience is not something that we should talk about? Absolutely not. But what it does mean is when we talk about positive user experience, we need to recognize that unless we have a shared definition, unless we're talking about something that we have discussed before, then other people are going to bring their definitions to the table. They're going to bring their previous experience of what it means to have a positive user experience. They're going to bring that information into the discussion. So how do we fix this problem? How can we avoid loaded words? Well, we've already started by saying we need a shared definition, but how do we find a shared definition? I want you to ask the question, what does that mean until you get to atomic terms? All right, so let's break this down. What does that mean? You're going to ask that question about each of the words that you don't have a clear understanding of to disambiguate the meaning of that word, right? And this should result in atomic terms, atomic terminology. All I mean by atomic terminology is a word that can't really be reduced any further, right? A word that means exactly what it means. Sometimes this is going to be a very technical process. This may be a very technical definition, this is really kind of the core of converting feel back to feedback, right? What does it mean for something to feel exciting? Well, you may end up with a list of hex colors as your atomic terms for describing that meta idea of exciting, the colors that make you feel excited. What does it mean to have a positive user experience? Well, it may be that you start out by saying, well, it means that the web page is loading fast, right? This is one characteristic of a positive user experience. But then I want you to ask again, what is fast? Of course, you know what the web page loading means, right? But you could also ask what constitutes the web page having loaded? Is it the first thing that you see on the web page or is it all of the assets are completely loaded, including everything below what you see initially? What you'll start to realize is that when you ask these kinds of questions, you open the door to new possibilities to accomplishing the same goals even more efficiently, right? So with that exact problem, loading a web page fast, determining the technical aspect of this is really not the question. It's determining what exactly does it mean for a web page to load fast? Because really what we're after when we say we want the web page to load fast is we want the user to have this sense that the web page has loaded fast. So what does it mean for the user to have the sense that the web page is loaded fast? Well, it means that they see something very quickly. So the process of disambiguating and finding atomic terms may ultimately lead you to a better solution. And it certainly will lead you to shared definition. So a web page loading fast or a web page feeling like it loads fast, if that constitutes positive user experience, then now you know the actual steps that you need to take. I need to make that first visual appear as quickly as possible. This is something that you can go and implement rather than discussing in very broad terms how to create a positive user experience. So hopefully this process of disambiguation will help you in your projects and more specifically it will help you steer your feedback mechanisms, steer those discussions towards more actionable outcomes, more actionable and shared definitions. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Rollbar for sponsoring today's episode. You can get started with the Bootstrap plan for free by going to rollbar.com slash Developer Tea. Thank you again for listening to today's episode of Developer Tea. A couple of quick notes. I will be taking off a few episodes this week and next week as I prepare for my son Liam who arrives his due date is June 28th and he should be arriving around that time. But we will be back with new episodes very, very soon. It should be no later than next week towards the end next week. So thank you so much for listening for being a part of this process. I thank you to all of you by the way who have congratulated my wife and I on Liam's impending arrival. Thank you so much for listening. If you don't want to miss out on future episodes of Developer Tea, make sure you subscribe and whatever podcasting app you use. Thanks again and until next time, enjoy your tea.