In this episode, I sit down with Chelsea Troy, a Chicago-based software engineer, to talk about giving and receiving feedback, something you have to do quite often when working on software, but which you don’t always get to do as a student. Besides talking about code reviews, the most common situation where you have to give or receive feedback, we also explore how to solicit good feedback and how to take feedback constructively. Chelsea has written extensively about this subject (and many, many others) and you can find all her writings, as well as videos of her talks, at chelseatroy.com.
In this episode, I sit down with Chelsea Troy, a Chicago-based software engineer, to talk about giving and receiving feedback, something you have to do quite often when working on software, but which you don’t always get to do as a student. Besides talking about code reviews, the most common situation where you have to give or receive feedback, we also explore how to solicit good feedback and how to take feedback constructively. Chelsea has written extensively about this subject (and many, many others) and you can find all her writings, as well as videos of her talks, at chelseatroy.com.
Hey everyone and welcome to conversations in software development, a podcast on software development intended primarily for students. I am your host for her Sotomayer. I am a senior lecturer in computer science at the university of Chicago where among many other things I teach a class on software development. Today we will be talking about giving and receiving feedback, something that you have to do quite often when working on software, but which you don't always get to do as a student. The feedback you do receive as a student is often in the form of graded work and you don't often have a chance to give feedback on other student's work. Uh, so to explore this topic, our guest today is Chelsea Troy, a Chicago based software engineer who works in a variety of projects including the Zooniverse citizen science mobile app and the NASA Landsat image processing pipeline. Uh, as well as being a lecturer in the master's program in computer science at the university of Chicago where she teaches mobile software development. Chelsea has also written and given talks on a number of topics including how to level up as a technologist, refactoring and feedback. You can find all of her writings and videos of her talks at Chelsea, troy.com. Chelsea. Hello. Hello. Thanks for joining us.
Speaker 2:My pleasure. Thanks for having me.
Speaker 1:Absolutely. Uh, so let's, let's dive in. Um, you know, we're talking about feedback and I think a lot of students listening to this may not realize how common it is to give and receive feedback as part of your normal workflow as a software developer. So, uh, before we sort of get into the nuts and bolts of how to give and receive feedback, uh, could you actually tell us about a bit about the situations where you have to give and receive feedback as a software developer? Like in what situations does that happen?
Speaker 2:Yeah, absolutely. So as you can imagine in software, it's extremely important that our software work, right. And that's one of the things we use feedback for. In addition, it's often extremely important that our software be maintainable and legible to other developers who are not us. Because ultimately for the vast majority of software projects, software development is a team sport. We have multiple people working on the same project at the same time and even in the situations where we don't, we often have situations where a developer is working on a project alone and then they move on to another project or even another job and somebody else has to take over what they've written. So we are constantly working on other people's code now. Because of that, when we submit code, it's important that we check that it's legible to people and that it works properly. And one of the most effective tools that we have for that in software engineering is code review. We'll have another developer look at the code that we've written. There are a number of different ways that a team might do this, so we might do it with poll requests in get hub or a similar tool, which is a type of asynchronous code review. The code is being written at a different time than it's being reviewed. We also have pair programming, which is a type of synchronous code review. Two people are working together. One person's typing. The other person is essentially reviewing and providing feedback as the first person types. Another way that we'll end up using feedback in an engineering environment is to talk to one another about how to work in our team effectively and how we like to work with each other. In software engineering. Communication is extremely important because in addition to writing code, we also need to be able to advocate for our needs and the needs of our software to business professionals and product managers who don't necessarily see the needs the same way that we do. They're focused on advocating for our users and clients who want to see additional functionality on our app. It is our responsibility to advocate for things like upgrading from one version of let's say one version of a programming language to the next version of a programming language, updating our framework and making time for refactoring because ultimately those things allow us to patch security holes, improve the maintainability of our software and do other things that are helpful for our clients in the longterm, but may not translate to immediate functionality like product owners might be advocating for at that exact moment that we do it. So those communication skills are something that we need to hone and we need each other's help in the form of feedback to be able to do it.
Speaker 1:So the, the, the, the kind of feedback that students typically receive, uh, you know, when they're taking a class is usually in the form of, uh, of grading, which is just a very like, specific type of feedback with the certain connotations, et cetera. Um, it sounds like the feedback that you're describing, uh, you know, when you do code reviews and stuff like that, uh, is very different from, uh, from, from being graded. Uh, you know, is, is that, do you think that that's an accurate sort of depiction?
Speaker 2:Oh, absolutely. So in an environment like an academic environment where you're being graded, the goal of the feedback is a little bit different. In the situation with the feedback is a little bit different. So as an instructor, I am instructing you on various skills and asking you to improve on specific metrics that I've laid out before class that I've included in the course description and the syllabus and the course goals so you know exactly what you're supposed to be improving it. Then the grade provides me with a numerical method that I would use to potentially quantify how that's going. So feedback can serve a number of goals and grading serves two goals. First, a constructive one in which I'm trying to help you become the best that you can be. And an evaluative one in which I am trying to quantify how good or how much better you have become at these specific skills at the exact time that I'm looking at your work in a work setting, usually your feedback on a code review or on paraprogramming is almost fully constructive. You're not being actively evaluated at that time on how good you are at something. Unless it is the specific situation where you are pairing in a job interview or you are giving a receiving a code review in a job interview or in the specific case where a manager is asking your peers for feedback on you, not necessarily for the main purpose of helping you get better, although that may be a side goal, but rather for the main purpose of allocating something like raises and promotions. However, the evaluative purpose in feedback is rarer in a professional setting than it is in an academic setting.
Speaker 1:So most of the feedback that you're giving and receiving is overall going to be constructive then
Speaker 2:that's the idea. Yes, and I think it's worth it at this point to establish a slight difference between my use of the word constructive and the way we typically use the word constructive. When we talk about feedback. So when I say constructive, I'm talking about a goal of helping a developer get better, whereas when we use that word and feedback, I think what we're often doing is we're trying to associate a, a nicer word with what we actually think of as negative feedback, which is, uh, maybe providing the news that we think somebody needs to get better at something which is useful, but you know, can be uncomfortable.
Speaker 1:So if we, um, if you look at, um, you know, giving feedback and receiving feedback, um, uh, you know, uh, students usually are on the receiving end of feedback as we first discussed. Like they're usually being graded by, uh, by someone, uh, and they, they rarely have to give feedback. Uh, I mean, they might fill out evaluations for their instructors and their TA's, et cetera, but they're, they rarely have to give feedback to other students on their, uh, on their work. Um, and, uh, and I can imagine a student being uncomfortable at doing this because, um, uh, again, because the feedback that they tend to, uh, be involved in is, is always, is, tends to always be evaluative and that they might associate the, uh, giving feedback to another student as being evaluative is as opposed to being, uh, constructive. So, um, what, you know, what advice would you give to someone, especially to students to get out of that mindset and to, to figure out like what are the effective ways of giving feedback to someone else? Uh, whether it be, you know, in the context of a code review or in the context of, you know, someone just, um, wanting feedback on their work style or their communication skills or something like that.
Speaker 2:Totally. So I think that when we give feedback, a lot of the discomfort can come from the fact that we're not sure how that feedback is going to be taken, right? Because ultimately, no matter how we frame feedback, we don't have control over how another person interprets that feedback. We could frame it just as nicely and as positively as we can. And it can still be the term we might use as quote unquote taken the wrong way. And there are a number of reasons that that can happen. So first of all, if the person wasn't expecting feedback and we provide it to them, then it can feel like, you know, an unwanted critique has been levied against them. Or sometimes people ask for feedback but they're expecting feedback about thing a and we provide feedback about thing B, which in addition to suggesting that they need to prove improve at thing B also suggests that we, uh, that we don't have the same priorities that they do. Or another thing that can happen is that, um, they ask for feedback and they use the word feedback, but what they're really expecting is validation. They think that something they've done is really good and they want to be told by somebody else that what they've done is really good, which is valuable and it has its place in, in a workplace or in a classroom. But, uh, but we hear feedback and we expect that they would also like to hear things that we think could be done better. And so even though it feels like they asked for that feedback, they just really weren't expecting some of what it is that we told them, which can be surprising and can result in a negative reaction even if we feel like we told them exactly what they asked us to tell them.
Speaker 1:So. So it sounds like you have to be mindful, not just about how you give feedback, but also about how you, how you receive feedback, uh, which I think is, um, I think it's, it's sort of like a pattern that is, is hard to break as a student because again, you're, you're so, you're so accustomed to receiving feedback being, you know, basically evaluative, judgmental, you know, being given a grade, et cetera. Um, what, you know, what do you think you can, what would you suggest, you know, for someone who is receiving feedback? Like what, what, what would be a good way to, um, either, you know, make sure that you take the feedback the right way or, or, or maybe like get feedback that is going to be valuable to, uh, is going to be actually valuable to you.
Speaker 2:Totally. So here's what I think is missing from a lot of feedback interactions. Generally the request for feedback goes something like, Hey, do you have any feedback for me? And then that leaves this wide open ended kind of situation where the feedback giver has to figure out what can I give feedback on? Is it safe for me to give feedback? Are they going to not like me after this or not ask me for feedback again. And it's a lot of stress sort of for both parties because the giver has to determine what feedback is safe and wanted and, or the receiver has to figure out how to receive the potentially surprising news that they need to get better at something, you know? And so there's an interaction that can happen at the beginning of this that I think will reduce a lot of that stress, which is if we get specific about what it is that the feedback receiver wants feedback on. So as a feedback giver, I will often ask us, ask if someone says, Hey, can you give me any feedback? I'll say, all right, well, um, what, what were you going for in this code that you're asking me for review on? What are you hoping to do in this interaction that you're asking for feedback on what are your goals? And I will ask them to provide me with two or three specific goals. For example, in code will I really want the code to be legible to other developers. It was really important for me to separate the responsibilities of these objects in a way that it's going to be easier to add on more responsibilities later or I know that this needs to run in a high performance environment. It's extremely important to me this code run fast or that this code not take up a lot of resources and allocate a lot of objects as it's running. That is really helpful for me as a feedback giver because it tells me what the recipient is prioritizing and what feedback they're going to welcome. So that's the first question I ask. The second question I ask is what, how would you assess yourself? How you performed on these goals in the code that you're giving me to review. And that self-assessment gives me important information too because if their self assessment is, you know, I think I did a really great job. I'm really proud of what I did here that tells me they might be looking chiefly for validation. And so I have the opportunity as the feedback giver to validate their work in the highest terms that I authentically can, which has positive connotations in the work environment as well. It allows me to build my relationship with this person. It allows me to provide them with con confidence they need in order to be able to continue doing a good job. That having been said, if their self assessment is, you know, I worked really hard on this but I think it could still be improved in this area, in that area. And um, I'm kind of hitting a wall and I'd really like your thoughts about maybe what more I can do here. That is also great because it gives me an opportunity to know where they are welcoming my help and where I have the opportunity to frame my feedback as, okay, I see your goals, I want to, I want to co conspire with you to get you to those goals and here's what I'm seeing in the work that you've done that that allows you to leverage my eyes and my judgment to help you do what it is that you want to do. So I think that those two questions are really helpful for maybe a feedback giver can ask those questions. And as a feedback recipients, I try to provide the answers to those questions ahead of time. So when, when when you ask for feedback, when you ask for feedback on a code review, like what, what is important to you? What, what, what are you hoping to get out of that? Uh, uh, that code review. Totally. So I think that, and part of this is that we tend to not ask for specific feedback at all. We tend to kind of submit a PR review or ask for feedback. And the general question is usually, you know, do you have any feedback for me? So specifically with regard to a code review, there are kind of a number of characteristics that I'm looking for my code to display and a lot of them have to do with maintainability. So for, I guess I'm speaking now about myself personally and what my goals are in writing my software. The answers to this might differ depending on who you are and the kind of software that it is that you write, but I want to make sure that my code does a couple of things. So first of all, I want it to be legible. I want to ensure that my code is something that another developer can walk into and figure out what's going on. There are a number of ways that I want this to happen. I want my variable names to be clear. I want my method names to be clear. I want each of my tests to tell a story about what's happening in my code because I want developers to be able to turn to my tests to get an understanding of what my system is supposed to be doing. If they're new to the system, I want my code of course to be functional. I want to make sure that it works, but I also want to make sure that my code responds to the scaling needs of the system. How many people are going to be using this code and would my software be able to handle that many people at once? Is my code robust? If an end user were to put in the wrong input on an app that I write, would my app be able to handle that gracefully and would my app be able to guide the user in what input I really need? Let's say on a form or would my app just crash? Of course, that's not good. Is my code secure? What a hacker be able to access somebody's precious personal information because of a mistake that I made in my code. I want to make sure that that can't happen. Is my code accessible? So are people who use screen readers or other accessibility tools, large font, high contrast, large tap targets, are, are those people going to be able to access my code in the same way that people who don't use those features are able to access access to the things that I've built? And finally inclusion. So I'm a, you know, a white queer woman. There are perspectives that I lack. I can't understand what it's like to be a person of color. I can't understand what it's like to be a guy. I can't understand what it's like to have a disability that I don't have. And if my app is supposed to serve people that I am not, then I need to figure out a way to get their perspectives on the decisions that I am making. Because ultimately we see a lot of issues in tech and in other arenas where technology is supposed to serve a group of people who are not represented in the decision making body. So those are qualities that I am actively looking for in the feedback on my software. And those might not necessarily be true for, for everyone. Um, let's say if you're writing a compiler than raw speed in your code is going to be much more important to you than it is if you are a programmer who works on an end user application who's maybe much more focused on, on inclusion in a way that a compiler developer might not be. So those are my goals as somebody who primarily writes end user applications. But I think it's valuable for any developer to think really hard about what their specific goals need to be on improving the code that they're writing and improving their skills as a developer.
Speaker 1:Okay. Well with that, I think we can wrap things up. Uh, so if you enjoyed, uh, hearing about feedback and all the other things we talked about, uh, just as a reminder, Chelsea has written and spoken extensively about this topic and many others. You can find her blog posts or talks, et cetera, at Chelsea, troy.com. Chelsea, thank you so much for joining us today.
Speaker 2:Absolutely. My pleasure. Thanks for having me.
Speaker 3:[inaudible].