Radical candor doesn't mean being a jerk.
In this episode, we talk about using the principles of radical candor to give effective code reviews, with Rina Artstain, software engineer at Dropbox.
Jess Lee is co-founder of DEV.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Rina is a senior software engineer at Dropbox and was a full stack engineer before the term was invented. She believes communication is key to everything, and practices creating software by applying careful study, thoughtful listening, and open conversation. She is a speaker and a mentor, focused on promoting women in tech.
[00:00:01] JL: This season of DevDiscuss is sponsored by Heroku. Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?
[00:00:18] BH: Fastly is today’s leading edge cloud platform. It’s way more than a content delivery network. It provides image optimization, cloud security features, and low latency video streaming. Test run the platform for free today.
[00:00:31] JL: Triplebyte is a job search platform that allows you to take a coding quiz for a variety of tracks to identify your strengths, improve your skills, and help you find your dream job. The service is free for engineers and Triplebyte will even cover your flights and hotels for final interviews. So go to triplebyte.com/devdiscuss today.
[00:00:48] BH: Smallstep is an open source security company offering single sign-on SSH. Want to learn more about Zero Trust Security and perimeter list user access? Head over to the Smallstep Organization page on Dev to read a series about Zero Trust SSH access using certificates. Learn more and follow Smallstep on dev.to/smallstep.
[00:01:12] RA: And it turned out that I was not the only one who left code reviews feeling maybe hurt or angry sometimes, and that wasn’t really getting the best results.
[00:01:34] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all our lives as developers. I’m Ben Halpern, one of the co-founders of Dev.
[00:01:41] JL: And I’m Jess Lee, also a co-founder of Dev. Today we’re talking about code reviews and specifically how to give feedback with Rina Artstain, Software Engineer at Dropbox. Thank you so much for joining us, Rina.
[00:01:52] RA: It’s great to be here.
[00:01:53] BH: Rina, can you tell us a bit about your background?
[00:01:56] RA: I have a CS degree and an MBA from Hebrew University. I’m from Israel. I started out at Intel. I worked at a couple more companies, a small Israeli company that was sold to an enormous European conglomerate. After that, I switched to Dropbox. I’ve been working at Dropbox for two years in the Tel Aviv branch.
[00:02:17] JL: What kind of things are you working on at Dropbox?
[00:02:19] RA: I work on Enterprise, the Dropbox solutions for businesses. And I was on the team that did Enterprise Console last year, we released that, or large companies that want to manage a few teams from a single point of entry.
[00:02:38] JL: Awesome. And you wrote a really great article titled “Radical Candor: Software Edition”, which takes some of the principles by the book Kim Scott wrote titled “Radical Candor”, but specifically for people in tech. Can you talk a little bit about who the audience of that original book was for and how it ended up resonating with you in regards to software development?
[00:02:58] RA: The original audience or managers who need to talk to employees and have hard conversations about personal development and maybe places they need to improve. And that’s not easy. And I think in a lot of places at work, there are all sorts of issues that we don’t feel comfortable talking about, even between colleagues. And I was actually asked to give a talk about that and I was trying to make it more technical because women always do the “soft skill” stuff. So I was thinking like, “How can I put a twist on this to make it more technical?” And I thought about code review and the process of code review and how many times we end up feeling really bad while doing something that should be a technical process. And I think it really fits in with my entire view of software engineering, which is that software engineering isn’t about sitting in front of a computer and writing code. It’s about communication. So I put like all of that together and came up with this idea and I just got super excited about it. It just fit in so well into everything I believe. And I was worried when I gave the talk. I like asked the audience how they felt about code review and got answers. I was afraid that nobody would say anything about how they felt. And it turned out that I was not the only one who left code reviews feeling maybe hurt or angry sometimes. And that wasn’t really getting the best results when you think about it. Because if I got a code review and what I feel is angry or maybe embarrassed, I’m not going to learn much from the experience and I might not respond well or actually might not even change my code according to the comments that I got. And so that’s just not the right way to go.
[00:05:04] JL: Yeah. I mean, I can definitely relate to some of those feelings that you’re describing in my own PRs. Let’s just take a step back and actually define what Radical Candor is for people who are unfamiliar.
[00:05:18] RA: Radical Candor is a framework for giving feedback where the point is that we want to get our point across, even if it’s difficult, but not being mean because we want the other person to like listen to us and trust us and learn from what we’re trying to say. So this is a quote from Radical Candor, “Radical Candor is about giving guidance. It’s kind and clear, specific and sincere.” Right? So we need to really make a connection with the person we’re talking to. They need to trust us. They need to believe that we have their best interests at heart, but we don’t need not to be afraid to tell the truth. And a lot of people take this to like being a jerk, but that’s really not the point. The point is to say what needs to be said. For me, if I had to summarize it, then I would say that Radical Candor isn’t about telling the truth no matter what. It’s about building relationships where the truth is welcome to get better quality results and improve personally. And I really thought a lot about these two sentences and they’ve been highlighted a lot of times in that part post that I wrote. So I guess it resonated with other people as well. That’s basically Radical Candor. And the framework comes with like a nice graph where there are four quadrants. One of them is called “Ruinous Empathy” where we don’t know anything because we’re trying not to hurt the person we’re talking to. So of course, they’re not improving. The other one is called “Manipulative Insincerity” where we’re not saying anything because we really just don’t care enough to say anything and the jerk quadrant where we tell the truth and we just don’t care about the feelings. The quadrant we want to be in is where we care personally and challenge directly. So we talk to the people, we tell them the truth, but we do it kindly. And that’s the Radical Candor, quadrant.
[00:07:24] BH: Is Radical Candor and exercise that needs to be undertaken with all parties involved knowing that Radical Candor is taking place or is it something I could practice on my own as a method of giving feedback?
[00:07:37] RA: Definitely practice on your own. You need to establish trust before you do it, right? If you walk up to somebody on the street and say something, they’re probably not going to take it well. They might, but probably not. Once you have a relationship with someone and they believe that you like them and care about them, then you can say things that are maybe hard to hear, but they’ll be willing to listen because they’re open to hearing what you say. You don’t have to say the words, Radical Candor. It’s not a system where both people need to be on the same page. You just need to have that trust and the courage to say things that are hard to say.
[00:08:19] JL: You mentioned earlier that one of the quadrants is being a jerk. And I imagine that when you mentioned like challenging people directly, I think that there’s like a really fine line. So can you just talk about the difference between being like obnoxiously aggressive versus being challenging?
[00:08:37] RA: So I think that the being-a-jerk quadrant is when you say things that aren’t meant to help the person that you’re talking to. I don’t know if this is a thing in America, but in Israel, like in reality shows, people will always be mean and then say, “No, but this is my truth. This is what I believe. This is my truth.” Nobody cares what your truth is. You’re not being nice. I’m not going to like you just because whatever your truth happens to be. So in that place where I’m just saying things because they’re true or because I want to say them, it’s about me, and when I’m being radically candid, I’m talking to someone, I’m telling them things for them to help them improve. And they also have to believe that that’s why I’m saying it. So sometimes you might really have that motivation, but because you haven’t established the right relationship, it’s not going to come across like that.
[00:09:39] BH: Is the practice of Radical Candor especially difficult across cultures? Like you just mentioned, “I’m not sure if this is a thing in America.” Have you discovered that Radical Candor or ideas related to feedback in general translate effectively across cultures? Is this fundamental or are there nuances that go a little deeper?
[00:10:01] RA: There are definitely nuances. I think it’s also funny. In Dropbox, the Radical Candor is an initiative that started at headquarters because they were being too nice. And in Israel, we’re very direct. We have much more direct culture. So we needed a nudge in the other direction. So I think that while everybody at Dropbox is very nice, even in Israel, I think that the differences in how we communicate were very apparent. So yeah, there are definitely nuances. And if you have a direct culture like Israeli culture, then you need a lot of establishing relationship and like softening our messages, whereas in American culture where people are taught to be more nice and polite, then they need to be pushed in the honesty direction. Again, it’s funny because my parents are from the American culture, but I grew up in Israel. So Kim Scott talked about how she was told, “If you don’t have anything nice to say, don’t say anything at all.” And my parents definitely told me that. But when I was giving this talk in Tel Aviv and I asked if anybody else had heard that ever, nobody had. So it’s really kind of amusing because I’m like somewhere in the middle. So I think I’m well-placed to see the nuances and the differences.
[00:11:32] JL: If I was an organization that had people from all over the world, how would you go about implementing Radical Candor, taking everyone’s background into consideration, especially when it comes to code reviews?
[00:11:45] RA: I think that international corporations, which are based in America are still very US centric. So most of the other offices have to like adjust themselves to the culture in the US. We need to take that into account. There are a lot of things that we might not understand. And when we establish relationships with the other teams, they start to get it. So I think it’s always about having open communication lines and understanding that things might be different, but we, as a remote site, have to realize that we’re going to have to do most of the adjusting. And it’s very common to have like international communication courses or classes to help us understand things, like exclamation marks in American are excitement and in a lot of other places in the world, it’s yelling at you. So that’s something that you always have to realize that if you’re being yelled at through Slack, it might actually be somebody who’s excited about something. So cross-cultural communication is always a problem. And I think Radical Candor, because it puts so much importance on communication and establishing relationships, I think that really helps mitigate the culture differences because if there’s a person in front of you and you know them, I mean, we’re all people in the end. So if you know them and you know that they have a good intention, then you’re not going to be insulted by some small thing that they said wrong or being interrupted in a meeting, which we always do all the time and it’s even harder over Zoom, but it’s something that people used to complain about that they were getting interrupted, and then when it’s someone that you know, then you don’t take it as hard.
[00:14:01] JL: Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that. It allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], which explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.
[00:14:33] BH: Empower your developers, connect with your customers, and grow your business with Fastly. We use Fastly over here at Dev and have been super happy with the service. It’s the most performant and reliable edge cloud platform. Fastly CDN moves content, data, and applications closer to your users at the edge of the network to help your websites and apps perform faster, safer, and at a global scale. Test run your platform for free today.
[00:15:01] BH: How can Radical Candor be expressed in type? Is there a difference in oral conversation versus a typed-out conversation or even documentation?
[00:15:12] RA: I think that emojis really do a really good job of getting tone across. I don’t know if you’ve heard of Because Internet.
[00:15:22] JL: No, I haven’t.
[00:15:23] RA: Because Internet is this cool book about like internet language. Gretchen McCulloch or something like that, she writes about how emoji are gestures. So when you talk to someone face to face, then you can see their facial expressions and their gestures that they’re making. And I think that having emojis in written communication really helps get your tone across. Certainly if you’re communicating over Slack or something like that, I’m sure you use a ton of emojis. And I think it can work. I mean, speaking in person is always best. I don’t know, but in my code reviews I use emojis.
[00:16:04] JL: Yeah. I actually rely pretty heavily on emojis when I communicate. And the other day I realized just how different the Zany Face emoji on iOS and Android are to the point where, like, from my perspective, it’s expressing completely different things. And I remember discovering that and just being like, “Oh, no! How often was I misinterpreted by using this emoji?” Because I don’t know what device other people are on.
[00:16:34] RA: Yeah. She talks about that in the book about how differences. Someone sent me an emoji of a blushing face with like the wide eyes and I’m like, “What happened?” He’s like, “I don’t know. I just wanted to say thank you for giving me a compliment.” And I’m like, “That’s not the right emoji. I don’t know what’s going on.” So yeah.
[00:16:54] BH: For those that are familiar with Radical Candor or try to practice it, have you experienced anyone who falls into the wrong quadrant, but calls it Radical Candor? So excuses Obnoxious Aggression by saying they’re actually doing Radical Candor. Is that something that happens when folks become aware of this idea?
[00:17:13] RA: I’m sure it happens. It hasn’t happened to me. So I can’t speak to that, but I’m sure it happens a lot.
[00:17:20] JL: In your article, you also mentioned code review management systems and blocking changes. Can you talk a bit more about that?
[00:17:28] RA: So a lot of code review systems have a way to block someone from pushing their code. So we use fabricator. It’s the same system that’s used at Facebook. You can just block someone and it means that no one else can approve the code either. It always felt to me like something very aggressive. It’s like if somebody blocked me, I would like complain about it. They don’t trust me. They don’t think that I’ll read their comments and implement them. And I thought it was just me, again, because of this feeling that code review is just technical. And it turns out that I’m not the only one who feels like this. I actually did a Twitter survey and there are a lot of people who feel that blocking reviews are aggressive. Basically what it’s saying is, “I don’t trust you. You did a terrible job. I will not let you push this code in no matter what.” And that’s not very pleasant.
[00:18:31] BH: Yeah. Our tools absolutely enable our communication and are sometimes the only way to communicate certain ideas. So the tools have to work for us. GitHub changed their request review icon from a big red X to a slightly softer plus minus with a red box, which I really appreciate it. I felt like that helped me actually reach for that command more often because before that I felt more hesitant to offer that more candid feedback that this truly needs changes and it’s not just a comment. Because I didn’t want to say, “Big red X, this all sucks.” I wanted to say like, “Request changes and here’s why,” and we can kind of get through this in a communicative way. And I was really happy when that icon changed. I felt like it allowed me to express my opinion a lot more clearly.
[00:19:22] JL: It’s interesting that that change enabled you to be more honest in the way and request changes. I feel earlier Rina was mentioning that Americans are like too nice. So it’s almost like funny that when it was that X that you like didn’t feel comfortable using it. And I was going to say that and then I realized that, Ben, you’re also Canadian. So maybe that doesn’t fully apply to you.
[00:19:45] BH: I don’t know. I’d say it applies. If that’s the spectrum, I’m double American. Yeah. I genuinely felt more liberated to be more honest to use that tool because I didn’t feel like it was screaming at the people as much implicitly because I wanted to give more honest feedback more liberally and not that I avoided using the tool, I just never quite felt like it was expressing my attitude as effectively and that small design adjustment in the context where I’m communicating with someone without a lot of extra context about my tone or things like that. I felt like it enabled more effective candor.
[00:20:24] RA: I think that on the receiving end, it probably also changed the feeling of requesting changes or getting deeper feedback instead of like, “No, stop.”
[00:20:36] JL: How would you recommend giving feedback if you actually haven’t quite built that trust with the person you’re communicating to? And I’ll be a little bit more specific, Dev is an open source platform. And so we have lots of contributors that we’re meeting for the first time and we’re really meeting them through GitHub, through the PRs. Any recommendations there?
[00:20:57] RA: I think that being clear about intention is really important. So if I’m blocking or not approving and I have some serious comments or questions, I just should write that. Like in the beginning, “Hey, I read your code. Here’s what I think. I don’t want to approve this because A, B, C,” or, “Could you please fix these things? I have a few questions before I approve and just be like really clear upfront about what I want from you.” So that establishes intention and it helps building the trust because if I’m just reading like maybe tens of comments. I hope that the PR is small, so you don’t have that many comments. But if it’s like a bigger thing, like sometimes there can be like a lot of comments and you just get this fatigue reading it. And by the end, you’re like, “What does this person want from me?” And you don’t really want that reaction. You want someone to read the comments feeling good and open to what they need to change or learn from the comments. So I think that really stating upfront, “Okay, I have a few questions or I didn’t understand what you were trying to do with this flow,” or something that’s more like an I statement and really establishing like what’s going to come now, and that helps with the intention. Again, if I’m just reading a whole bunch of comments, it doesn’t really matter what they say, but the feeling is, “Okay, my code is terrible. Oh, no! I’m no good.” Or, “Who is this idiot? Why are they commenting on things? Why don’t they understand what I meant?” Right. So none of that is the good attitude to be in while code reviewing.
[00:22:51] BH: Oh, that’s equal. Is there a frequency where Radical Candor should be delivered? Is there an exhaustion with too much too often or is there another issue that feedback isn’t given consistently enough?
[00:23:03] RA: I think it really depends on the person that’s giving the feedback and receiving the feedback because it can be exhausting. And if you’re not in the right state of mind, then you’re not going to be able to do it well, because you really have to focus to be able to give that kind of feedback. And if it doesn’t come naturally, then it’s hard work. And some people are also not good at receiving feedback. I think that even if the feedback is given really well and you have the good relationship established, you’re still going to feel at least like a twinge, right? It’s not nice to get bad feedback. You don’t want it too often because of burnout and you don’t want it too far apart because things build up. And if you’re too emotional when you get to giving or receiving feedback, then you’re going to have a hard time with it and you’re going to close off and not be able to listen. So it also depends on the person. I’m always constantly looking for feedback. So anybody who wants to give me feedback anytime, I’m there. But other people need like a break to like think about things and process them. And I think like giving feedback is much harder for me. So while I try to do it, I still feel like I need to prepare. And if I had to constantly give feedback, then I wouldn’t be able to do it because I would say the wrong thing or I would just be tired and not get my attention across. So it really depends on the person and the relationship.
[00:24:41] JL: Do you have any words of advice for people who do struggle with receiving feedback, even if they understand the genuine intent there? Any way to prepare that person or to help the person giving the feedback make that feedback easier to digest from either party?
[00:25:02] RA: I think it’s really important to be clear and not dance around the issue, because if it’s difficult to hear, trying to soften it sometimes makes it worse because then you like leave the conversation not sure exactly what happened. So I think that clear, actionable feedback might be unpleasant in the short term, but in the long term, it’s much better, and the person who received it and was not happy will appreciate it more. So there’s like the situation-behavior-impact model. So that really works well if you don’t have the best communication skills or the best relationship during the situation, the SBI model really helps because then you’re like, “Here’s what happened. This is what you did. This is the impact.” And that helps being actionable. And when it’s actionable and the person feels like they can do something to fix it, that already is like a step in the right direction. And again, it’s like a long-term thing. Maybe the first time you give feedback, it won’t work out well. Second time, it’ll be better. Third time, it’ll be better. As long as you work at establishing relationship and that back and forth, that’s what’s going to work. And I think that if we go back to the code review thing, I think that if that’s how you look at code review as long-term relationship thing and not like, “Okay, I got this code. I have to look at it. I’m just going to write whatever comes to mind and that’s it.” Then you’re going to end up with a code review that’s hard to handle emotionally. If you think about, “Okay, I’m going to have to work with this person for maybe years to come,” then you might be more careful about how you write and what you write, and again, try to establish that relationship so you can work together better.
[00:27:16] BH: Are there any other management books you’d especially want to recommend as food for thought, if anybody wants to go deeper into this rabbit hole or similar rabbit holes?
[00:27:27] RA: I really like Good to Great by Jim Collins. He wrote it after Built to Last. I actually liked Good to Great better. What I like about it is it talks about how to make an organization that was just good, great, and the principles I think are very applicable to personal development as well, because they talk about like finding your hedgehog concept, like your core values and building on that. So he’s talking about businesses, but that’s something that a person could definitely do for themselves and like find their own core values and make decisions according to them. It really helps to have that kind of compass. I recently did CliftonStrengths tests and part of the follow-up was to like define our own brand. And I really thought a lot about it and came up with a sentence. It’s supposed to be my brand. I still don’t know where I’m supposed to put this, but I did come up with it so I’m really happy about it. So the sentence is, “I create software by applying careful study, thoughtful listening, and open conversation.” And when I actually go to work and I have this like core concept in my mind, it really helps me navigate even daily activities. Is this serving my core values and what I want from work and what I want to contribute? And I think, for me, that idea, the core idea comes from good to great.
[00:29:29] JL: Join over 200,000 top engineers who have used Triplebyte to find their dream job. Triplebyte shows your potential based on proven technical skills by having you take a coding quiz from a variety of tracks and helping you identify high growth opportunities and getting your foot in the door with their recommendation. It’s also free for engineers, since companies pay Triplebyte to make their hiring process more efficient. Go to triplebyte.com/devdiscuss to sign up today.
[00:29:54] BH: Another message from our friends at Smallstep. They’ve published a series called, “If you’re not using SSH certificates, you’re doing SSH wrong,” on their dev organization page. It’s a great overview of Zero Trust SSH user access and includes a number of links and examples to get started right away. Head over to dev.to/smallstep to follow their posts and learn more.
[00:30:18] JL: Now we’re going to move into a segment where we look at responses that you, the audience, have sent us to a question or a request we made in relation to this episode.
[00:30:27] BH: This week, we asked you, “Share your experience with feelings of embarrassment during code reviews.” Our first response is from Bernard. “I once forgot to squash my commits and was told my variable names were too descriptive. And that I didn’t comment some code that a lead didn’t understand because he’d never seen the JS code that allows you to monitor changes in HTML node attributes. A colleague actually egged on some negative banter as I left the office. I didn’t mind. I’m more mature than that. I did feel embarrassed that her comments were wrong and out of place, but I still didn’t mind.”
[00:31:05] RA: IT doesn’t sound like he didn’t mind. Right? I think that this is again like this feeling that we shouldn’t have feelings about our code, but really our code is our work. We put a lot of effort into it and some of our identity at least is what we do for a living. So I think it’s really legitimate to like allow ourselves to have those feelings and not say like, “I don’t mind.” Of course, you mind. You mind or you wouldn’t have thought of it. Right? So I think that it’s really important to open the stuff up and say, “Look, fine. So I made a mistake, but you shouldn’t be making fun of me. That doesn’t make sense. This is work. We have to respect each other.” I think that allowing yourself and allowing others and realizing that feelings are part of work make a big difference.
[00:32:00] JL: So Lynne wrote in, “Something I feel is important, especially when reviewing for junior devs, is to leave nice comments too. For example, comment on something they did well. It doesn’t need to necessarily be pointing out all of their mistakes, some positive comments would go a long way. And we’ll lean be criticism, don’t make it personal. You should have done this, et cetera. Instead of the word “you”, be careful with the language and say something like, ‘I think this could be done differently or a better approach to this could be…’”
[00:32:29] RA: I totally agree with the “I” statements. I always try to say, “I think.” I catch myself saying, “You should,” and I like to take a step back and say, “Okay, I think that this could be done differently,” or use “we”. “We might want to do something.” I think that there are two things here. One is that even senior devs need some nice words. When somebody comments and say things like, “I trust that you know what you’re doing or good, nice job or I like this piece of code,” you feel really nice. You feel proud, right? It makes you feel good. So why not? And also we need to be careful, like sometimes, and this happens a lot with inexperienced developers or experienced developers who are new to the organization, that happens too, where the code is like all wrong. It doesn’t make sense in the context and really it’s all wrong and then you’re like commenting and then you’re like, “These are too many bad comments. This is going to be awful.” And you stop yourself, but you shouldn’t because you do want the quality of the code to be high. So you don’t want to stop because you’ve written too many bad comments. You might want to stop and say, “Okay, maybe this isn’t the right format to give this feedback.” And sometimes when I see something like that, I stopped and I say, “Okay, I’m going to stop giving these comments. I’m going to reach out to this person and say, ‘Okay, I went over your code and I think your approach is wrong or maybe we should do it differently or something,’” that because let’s talk. So either, it could be over Slack and it could be over VC now. Right? There’s nothing in person, but I think it’s really important to like find the right format to give that feedback in a way that’s not going to feel too strong and too aggressive, but we have to get that feedback across. We don’t need to stop ourselves because we feel that we’re being too mean, again, because our purpose is to get the code quality up.
[00:34:40] BH: Yeah. And when I’m working with folks who give really excellent, positive, and constructive or negative feedback, I find it really effective for my own motivations because if someone gives good positive feedback, I tend to be really excited when I know I’m doing something that’s going to lead to that positive feedback, if I’m submitting a certain style of code, and I know that the improvements are going to be recognized or the kudos is going to be there when someone recognizes the good stuff and then that makes me pretty okay with the idea that other parts are going to be picked apart because when I get it just right, people are also going to be that much more excited or that much more willing to celebrate those things. I certainly recognize when I’m expecting someone to just put a positive emoji on certain parts of it. That makes me feel better about the parts that are going to have to go back to the drawing board or get rejected for merger or anything like that.
[00:35:41] JL: I like the one from Sebastian, if you want to read that.
[00:35:44] BH: “Working in a senior only department, I realized how offended people can be when you word things wrong. Today I’m the lead of a group of intermediate and junior devs. When embarrassing things happen in PRs it happens to us, not a single person. The difference in how well feedback is received when saying “we” instead of “you” and asking questions instead of pointing out mistakes is day and night.”
[00:36:07] RA: Yeah, totally agree that “we” works well and questions are much better. Sometimes you look at the code and you just really have no idea what’s going on here. So you can say something like, “This doesn’t make sense,” or you can say, “Can you please explain?” Right? And that’s just totally different.
[00:36:29] BH: On the topic of little word changes that really help, we have written in our guidelines to avoid using phrases like “just” then “simply” when it’s unnecessary to describe how to do something really to kind of emphasize that that’s a moving target, depending on who’s reading it and to avoid those little things that make people feel bad, which is possible by avoiding the use of a few triggering words.
[00:37:02] JL: Gary wrote in, “A couple of years ago, I went for a development job where the tech test was to read and write data to a file. Nothing complicated, but my brain totally froze. I’d had a couple of years of development at that point with a career sidetrack into a non-technical role, but felt really embarrassed by not being able to do something so simple off the top of my head. A quick Google leader and it came flooding back. Didn’t finish everything on the test, but still got the job.”
[00:37:29] RA: I actually had a similar experience where I don’t what, like I must’ve missed that class or something, but anytime anyone says something about bits and bytes, I just totally lose it. I have to Google how many bits are in a byte and how many bites. I don’t know. I needed that in an interview once and I just really like totally lost focus. Yeah, it was very embarrassing and the person who asked me that question is actually now my tech lead. So I don’t think he actually remembers most of that, but for me it was bad. So I think that when we feel that way, we sometimes have to take a step back and realize that some of that is in our head. So it’s not only on the other party to be nice and be careful about what they say. It’s also about us remembering that it’s not a onetime thing. Even if we make a mistake or we forget something basic, that’s not the end. We still will have more chances to prove ourselves. The feeling is legitimate, but we should try to get past it.
[00:38:41] BH: So Radical Candor and radical review is about getting us to the best possible outcomes, collectively giving feedback at least to the best possible outcomes. What would you want to leave our audience with in terms of actionable items to Institute some Radical Candor into their processes?
[00:39:03] RA: So I think that the most important part is to remember that we’re working with people and not computers and that we can’t ignore the human aspect of what we do. So when we write our comments, we need to take into account like who’s on the other side, we need to like balance those two things. The code quality has to be high. We don’t want to compromise on that, but we also need to remember that there’s a person on the other side and we need to consider that when we’re trying to get the code quality high. So we need to like choose our wording, establish good intention, establish relationships, and really be careful about not being mean, but saying everything that needs to be said.
[00:40:00] JL: Awesome. Thank you for your insights Rina and for joining us today.
[00:40:03] BH: Yeah. Thank you so much.
[00:40:04] RA: It’s really nice to be here.
[00:40:14] JL: I want to thank everyone who sent in responses. For all of you listening, please be on the lookout for our next question. We’d especially love it if you would dial into our Google Voice. The number is +1 (929) 500-1513 or you can email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email email@example.com and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Please rate and subscribe to this show on Apple Podcasts.
[00:41:11] SY: Hi there. I’m Saron Yitbarek, founder of CodeNewbie, and I’m here with my two cohosts, Senior Engineers at Dev, Josh Puetz.
[00:41:18] JP: Hello.
[00:41:18] SY: And Vaidehi Joshi.
[00:41:19] VJ: Hi everyone.
[00:41:20] SY: We’re bringing you DevNews. The new show for developers by developers.
[00:41:25] JP: Each season, we’ll cover the latest in the world with tech and speak with diverse guests from a variety of backgrounds to dig deeper into meaty topics, like security.
[00:41:33] WOMAN: Actually, no. I don’t want Google to have this information. Why should they have information on me or my friends or family members, right? That information could be confidential.
[00:41:41] VJ: Or the pros and cons of outsourcing your site’s authentication.
[00:41:44] BH: Really, we need to offer a lot of solutions that users expect while hopefully simplifying the mental models.
[00:41:52] SY: Or the latest bug and hacks.
[00:41:54] VJ: So if listening to us nerd out about the tech news that’s blowing up our Slack channels sounds up your alley, check us out.
[00:42:00] JP: Find us wherever you get your podcasts.
[00:42:02] SY: Please rate and subscribe. Hope you enjoy the show.