33: Ep. 33 | Looks Good to Me with Adrienne Braganza

Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I am your host today, Erica, and I am joined by…

Brittany Ellich (00:08) Brittany Ellich

Erika (00:09) We met while working on a team at GitHub and quickly realized we were all obsessed with getting better at what we do. So we decided to start this podcast and share what we’ve learned. We’ll be talking about everything from leveling up your technical skills to navigating your professional development, all with the goal of creating a community where engineers can learn and connect. Today, we are diving into one of the most critical yet misunderstood parts of every software developer’s job.

the code review. And we are absolutely thrilled to welcome Adrienne Braganza, Adrienne is a software engineer, international speaker and author of the book, Looks Good to Me, Constructive Code Reviews. We think that your book really strikes a chord because the process of writing and reviewing code reviews really isn’t

taught by anyone. It’s something we all kind of learn on the job by mimicking others, maybe having a particularly kind co-worker at the start of your career talk you through the process. But your book, Adrienne, is a missing manual and it approaches the topic from a refreshingly human-centric perspective. It goes beyond just the tools and the syntax and addresses

the crucial interpersonal aspects of team trust and communication and avoiding the kind of toxic reviews that harm morale and productivity. So thank you so much for joining us. ⁓ We’re so happy you’re here.

Adrienne Braganza (01:40) Awesome. Yeah, I’m really happy to be here. Erica, Brittany, thank you so much for having me. I’m so not surprised that we’re still talking about code reviews today, but I think it’s actually even more important in this day and age. But yeah, always happy to talk about code reviews.

Erika (01:56) Absolutely. Well, let’s start with the core problem and your motivation in this space. So what motivated you to write a book specifically about code reviews?

Adrienne Braganza (02:07) You know, I got the chance to, ⁓ in my role as a developer advocate, I get to talk to a lot of people in the developer network. And a lot of that includes a lot of teaching, a lot of workshops, a lot of technical tutorials. So, in that you kind of get these pretty cool opportunities. And that was one of them. Manning publications, reached out to me and said, Hey, we really like what you’re doing. And we’ve seen a couple of your talks.

If you had to write a book about anything, anything in tech, what would it be?

like not even a half a second later, I’m like code reviews because you know, there’s always the next new thing. If it was a specific framework, if it was a specific programming languages, those all move way too fast. Like by the time you go through the normal book review process, that thing is already outdated. So for that topic, I really wanted it to be something that was evergreen, something that affected every software development team. And it doesn’t have to be a developer either.

anyone who’s touching code that could be software testers, I really wanted to hit a topic like that that really would affect the most people, but also is something that is just completely misunderstood, as you’ve mentioned. And I had a lot of things I wanted to share about what worked on the teams that I’ve been on and what didn’t work and all the frustrations we surely faced. So yeah, that kind of was an easy decision for me. Putting all of my thoughts together, though.

That was that’s another story. That’s why the book took about almost two years to write.

Erika (03:41) Well, that is amazing that you got this opportunity and we’re all benefiting from you taking the time to put your thoughts down on paper. And like you mentioned, mean,

Adrienne Braganza (03:49) I hope so.

Erika (03:54) This is, yeah, not a problem that’s going away anytime soon of reviewing code. And, you know, we do talk a lot about AI these days, but sort of at the heart of…

Your book is a lot of these interpersonal and communication aspects. So from your perspective, why is this human-centric approach critical ⁓ to a successful code review?

Adrienne Braganza (04:19) I think ⁓ in the research that I’ve done, both from looking at papers that have been done on code reviews and my own teams and all the common patterns and themes of what was frustrating developers, it always came down to misunderstandings and bad communication. That’s really the heart of most of the frustrations we deal with in code reviews.

So I think it’s super important to take some time to not just think what tool am I using or how do I make it faster or how do I just get the check mark. It’s why are we doing this? What are we using it for? What do we all agree is something important to call out or not? And when you mentioned earlier is absolutely true. The first…

team you work on and the first exposure you have to a code review process, if at all, that’s kind of what you carry with you throughout the rest of your career. So if you’re lucky enough to have a team that has an established process and has good communication and not just that, but good interpersonal skills and clear people with, you know, a co-collaborative nature of how they want things to be done, then like you’re really lucky. Hopefully you learn from that.

see this is what a code review process should be and I see the benefits of it and you take that with you throughout the rest of your career. But unfortunately, most folks don’t have that. I had a terrible code review process my very first time. was, you know, a lot of people relate. I don’t say everyone has this experience, but when you just come out on your first like real job as a software developer, even as an intern, you hear about this process and you’re so

worried about it because you’re like, I don’t want to be critiqued. I don’t want to look stupid. I don’t want to, you know, prove that I’m not supposed to be in this job. And then you have an experience where you do get your code critiqued and it is very harsh and it is very mean. That could definitely set you up the wrong path. Like you could say, I don’t want to do this anymore. I don’t like this. you know, some people might be thicker skinned and they’re like, yeah, I did write crappy code or whatever, but

Regardless of all that, I absolutely believe that there’s a proper way to do code reviews and that proper way all comes down to communication. So I come back to that every single time. Almost all forms of frustrations and problems people have come to me about code reviews. It boils down to some form of miscommunication.

Erika (07:04) Totally. mean, I think it’s one of those areas where what’s left unsaid and all the unsaid assumptions can really bite us. I’ve seen everything from the… There’s a bit of a spectrum of the over-permissive to the hyper-vigilant reviewing style.

And so much of the time it’s a one-on-one sort of like back and forth. And so yeah, you do sort of establish this relationship with somebody through a code review. And like you, I think there’s sometimes like some shared level of responsibility, which is true in all software development, but depending on the person either writing

the PR or reviewing the code, there’s assumptions on both sides about what the responsibilities are and what we’re trying to get out of this. Like, you know, is it perfection? Is it good enough? Is it, you know, meeting some kind of quality or safety criteria? So totally true. And, you know, when those unspoken assumptions don’t get met or it gets broken, there’s a level of trust, but

degrades and that can definitely compound over time. I I’ve kind of heard reviews weaponized in a certain way sometimes where like a bug gets into production and it’s so and so’s fault for writing the code or so and so’s fault for not catching it in review. it’s like, no, no, You know, that’s right. Right. Like we’re all in this together. And yeah, to your point, like

Adrienne Braganza (08:36) That’s the wrong way to think about it, yeah.

Erika (08:45) it can be borderline traumatizing if you have a really bad review experience.

Adrienne Braganza (08:49) Yeah, I think you hit the nail on the head as well as that because we all have such different experiences, that’s why it is such an interpersonal thing rather than a more technical thing and why we all have so many of those unspoken assumptions. We carry those, what I call them in the book, implicit expectations of what a code review is supposed to be. And so when we see someone else doing either something completely different or totally against what we have learned.

and have internalized as the code review process, that’s another form of why there’s so much friction between team members, because some people think it has to be done this way, some people think it’s not that serious, some people are like, we don’t need it at all. All of those experiences that have shaped our different trajectories in this field definitely play a part into how much friction there is if you don’t have the same beginning experience in code reviews.

Erika (09:46) Absolutely. Well, let’s talk about some of the ways that we can set ourselves up for success. So you recommend a four phase process, establish goals, choose tools, set guidelines and refine. So say I’m on a team that is having a lot of friction. Where would I hypothetically start?

Adrienne Braganza (10:06) That’s a good question. With this information, I assume you have some sort of process in place and there are probably clear friction points that your team has. I would still start at the very beginning of establishing goals, but right before that, I would say take like one or two weeks to kind of jot down every member of the team, anyone that’s part of the code review process to kind of just note

What are those friction points? What is a bottleneck? What was not great? What got lost in translation? All of the things. And I think it’s really interesting to compile those answers from the whole team to see, because some people think it’s great. And some people think, there are only these steps in our code review process, but other people have missing steps or go through different steps. And just aligning the team on what they’re…

code review process actually is, is very enlightening to see what those common themes are and what different people experience as bottlenecks. So once you have that, then I think the four-phase process that I talked about can then begin, right? So now that you have those friction points, now you can establish those goals. we, you know, now that we know what’s hard, what are we actually doing this for? Do they actually match? Are we doing this because it’s just been in place?

Sometimes teams do a lot of pair programming and the really, really strict formal code review process is actually not needed. It just needs to be something, a lighter version for that team. For other teams, they’ve just been going along with the flow. No one’s ever really told them what it was for. They don’t know what it is. So it’s really good to start with what those goals are. Best case scenario is you’re kind of hitting those goals after you’ve determined what the friction

points are, then the next step is just to really go through each of the pieces there, the choose tools, the set guidelines and refine, but really take a look at it based on the friction points you’ve surfaced. So if a friction point is you want two people to accept a review or to be able to look at it, but your tool doesn’t allow you to do that, that’s a tool bottleneck that who knows you then you dig down that hole and see why did

we

choose this tool? Is it still working for our team? Does it not fit how we want to do our process and then talk about whether it’s worth it or possible to change the tool. If there are guidelines that are not in place or ones that are in place that don’t make sense, that’s another conversation that you need to have with the team and another friction point that could be fixed. So if it’s misunderstanding on what’s a blocking piece of feedback versus not,

and people are always fighting on your team about, I prefer to implement it this way. Well, no, I think my way is better. If those are the types of friction points, then maybe it’s worth it to say, talk as a team and agree. This is definitely something we want to call out and should block an approval versus not. And then of course, the refine I always add in there because…

it’s going to change. Your projects change, your teams evolve, tools evolve, AI is here. So whatever you might have decided as a team initially at the friction points of that time, as you start to implement new things and new guidelines.

they might not fit or you might need more. And so it’s a continuous process to really make it work for your team. So I would start there, start logging those friction points and then go through the four phase process of what do we actually want with our code review process? What’s the diff between that and the actual goals or the actual friction points we’re having, see if the tools fit, see if there are guidelines that are missing or that we can delete and then continue.

to do that over time.

Erika (14:07) As you’re talking, I’m thinking of like add on benefits that are not even said in like how you laid out the strategy, but in my own experience.

I, like even with the engineers that I’ve worked with who maybe have, like I haven’t had the best code review experiences with, they’re all really smart. But I think in a lot of these like sort of process changes, sometimes they’re the ones who are least likely to buy into some kind.

some kind of like change. Like sometimes there’s this attitude of like, well, like, you know, I’m doing fine and you know, the problem is not me, right? But as soon as you ask those people to like basically air their grievances or like note down everything that’s wrong, like the list is a mile long. So.

You know, not only does it kind of deescalate the situation to be like, hey, like, you know, we have this amorphous problem, like not naming names. It’s like not personal. It’s not anybody. It’s our shared team problem. But we don’t know exactly what it is. Like, what do you think is wrong? Like, you’re so much more likely to get, you know, that one person or say it’s like a whole team or, whoever might be resistant at the beginning.

to like, once it’s their problem, they named it, like they’re more likely to want to solve it. Cause I do feel like that’s also very much an engineering personality trait of like, see a problem, want to solve. Yeah.

Adrienne Braganza (15:39) For sure. I think I talk about this specifically encouraging either engineering managers or tech leads to do and kind of lead the process for logging these friction points because depending on the team and depending on your rapport, like you said, it might not go that well. Another big part is that some people are not comfortable speaking up or

talking about these types of things in a group forum. having a way to capture that information, not just in a, let’s have a meeting and talk about all our problems in front of everyone. It’s maybe you send it in an email, maybe you capture that in one-on-ones, maybe you go to an engineering offsite and everyone writes in a post-it note. There needs to be various forms of…

Capturing this feedback if making it anonymous makes it better and more honest. Absolutely do that But you know, sometimes there are teams who are they’re chill with each other and that’s you’re very lucky if you have that where if it is okay, then yeah, you have a conversation you talk about it and ideally you whiteboard it out and you you know write it all down, but I definitely encourage Really anybody who wants to pioneer this process and wants to take it make it better for the team to

to capture all of that and solve it together. That’s absolutely something that’s a theme in the book. It’s not just one person making this set of guidelines and then everybody follows. The more you have other people’s input, usually you have more buy-in from the rest of the group rather than just top-down management.

Erika (17:15) sure. One way to distill this information that you talk about a lot is ⁓ the team working agreement. So could you describe a little bit about what it is and what’s maybe like the most important thing to include in it?

Adrienne Braganza (17:29) For sure. love this. I learned about it. We borrow it. I don’t know who the original is, but we borrow it from the Scrum world or the Agile world and any type of project management where it’s just this set of guidelines that you as a team agree to enforce and what those guidelines are could be anything. So from the Scrum world, it’s, you know, we agree what the different user story sizes are. We agree on their sprints.

They’re two weeks versus three weeks. We agree on how we’re gonna treat each other. You can go as granular as you want. You can get as interpersonal as you want. But I thought it was a really great thing to apply to code reviews because there are a lot of different parts, those unspoken assumptions that would be great to put in a team working agreement. So for me, there’s a lot you could put in there. But if you had to start

and you definitely had to put something in there. I would say the most important thing is the reviewer and approver responsibilities and how you communicate in code reviews. So even that sounds kind of generic. What I mean by that is what are your non-blocking versus blocking pieces of feedback?

So if something falls under the lines of a security issue, a code smell issue, you know, straying away from code convention issue, a, what’s the word I’m trying to look for? If this ⁓ introduces, or if it makes code maintainability more difficult, all of these types of

smells or things to look for you would put in a blocking issue list. And then all of the things that a lot of folks tend to agree are should not be blocked, meaning somebody can’t, you know, not approve it because you don’t fix it. Silly things like formatting, spacing, preferential variable naming, unless you can back it up within an objective fact. Like that’s going to be different among every team. So if you can have that conversation and agree at least to the most important

things of what should be blocked versus not blocked. That’s one way to be more clear on communication. And the other part is how to structure your comments.

I dedicated a whole chapter to this because it’s that important, but I mentioned something called conventional comments. If you’re familiar with conventional commits, it’s kind of the same thing where you basically are structuring your comment so that it’s very easy for the code author to read it and know what to do. Do I need to address it? Do I not need to address it? Is this blocking? It’s not blocking. What is this related to? Do I need to make this fix right now?

Is this a suggestion? Is it polish? Is it, you know, a lot of the times when we get pieces of feedback, we immediately panic and are like, my gosh, I have to work on all of these things. But then later on, when you talk to the reviewer, they’re like, no, I just wanted to tell you those things. Like, actually everything looks fine. So you waste some time worried thinking you needed to make all these changes, but in reality, these were just, you know,

things they wanted to share with you. So by adding a simple little tag or comment signal, like I also, what my team use, you can, as an author receiving that feedback, it’s much easier for you to be like, okay, these are the things I absolutely have to fix. These are the things I don’t have to address. And that makes it go much faster.

those would actually be the top two things I would put in there because the majority of things that people argue about are within that process. It’s misunderstanding each other and then you get into a debate and you’re like 27 comments long and a thread of arguing why you should do this and why you should not do this. Or it’s arguing about, no, you should approve my PR because X, Y, Z and then someone else says no. And you haven’t decided on what.

should or should not block it. those would be the top two important things. that kind of falls under what is the responsibility of a reviewer and an author. So the most important are the bonus things I would add in there are what is your code review process like actually do? What are the steps? Because that are not only be helpful to your team to reference, but any new team members can now easily get into the swing of things. Even folks who are not new to programming

just new to programming, sorry, that’s what I meant. If they’re new to programming and they’re just getting into this for the first time, that’s gonna be very helpful for them. And then spelling out what is actually happening in your code review process. So if you use different statuses, absolutely spelling out what the different comment signals you’re using are. If you have common scenarios of like, if you get stuck arguing about something, like what do you do? Those are all the nice to haves.

but if you only had to start with a couple things, it’s what are your comment signals and what’s a blocking versus non-blocking issue in your code review process.

Brittany Ellich (22:25) I love that my team at GitHub ended up reading this book altogether as well. Your book was amazing. Thank you so much. the conventional comments has been.

Adrienne Braganza (22:29) So, nice.

Brittany Ellich (22:35) really, really great for us. was something that I didn’t realize that I did a lot where I was like, I’m just going to provide this extra bit of information. And that makes it really unclear when you’re just like, OK, but I just want to get this thing completed. using that has been really helpful.

Adrienne Braganza (22:48) I’m really glad to hear that. Yeah, I think it’s just it also really helps across teams that are global. This is another thing I’ve come across too is folks who are uncomfortable or maybe not as confident in the English language. They also complain or not complain, but are frustrated that they are not as understood or what they want to say might be taken out of context because English is not their first language. So again,

And some contract between team members of like, is what this means.

completely eradicates that sense of this is what they mean versus this is what I interpret it as. And again, if you agree, you know, these are the comment tags we’re going to use. It’s blocking, non-blocking, maybe the section that it’s applying to and maybe a ⁓ level up or polish or optimization. Just having that at least level of being on the same page just helps so much in Teams when it comes to

writing out feedback.

Brittany Ellich (23:51) Can you talk a little bit, you’ve spoken in the book about automation, which is something that I feel like lot of engineers love to automate things. What are your suggestions on what are the best things to automate versus what are the best things to leave to humans to judge?

Adrienne Braganza (24:04) you

So absolutely style guides should be like the first thing at most teams. That’s one of the things that surprises me is that there are still people fighting about like indentation and spaces and you know, just a little formatting things. And I always thought we waste so much time on this, especially not just for, you know, you fixing it. I know everyone usually despises getting like 20 comments of, you missed

So if there’s anything that can be automated, should. Anything you can fix before the code review should be automated. If you have a linter, ESLint prettier, if you have static analysis tools, like Roslyn for C sharp.net framework, if you have…

Any of these things, automated tests, so Mocha tests or dress tests, if you can run any of these things and fix them before the code review, I highly recommend implementing those things first because this is what I call the low hanging fruit, the things you don’t want to waste your time on during the code review. And these automated tools will find it much faster. And again, with the interpersonal ⁓ thing,

Most everyone was more willing to fix that squiggly line. Like if a machine is telling you you did something wrong, I’m like, ⁓ you’re right. I should fix that. But if someone else is telling that to me, I’m like, I roll my eyes. like, I know you’re right. But it just, feels, it feels worse if somebody else is telling me something like that. I’d rather have something that.

With all of our ingenuity, creativity, nuance, context, what humans are good at, I’d rather have them spend their time looking at my code, looking for those issues that cannot be found by automation. I want to talk about that. I want to see some random edge case that I may not have seen because I was so in the weeds of creating this and getting this feature done that you happen to see. And we talk about it.

Alongside of that, know AI is going to be a thing, right? The fact that we are generating so much more code with AI, that’s where I’m like, code review is absolutely still necessary for humans. And I still stand by this. know the book, in the book I go, you know, I’m not against AI code review tools. They’re getting better. They’re definitely better than when I published the book.

But it’s still not there. The thing is, you want to maybe use them for like a first pass. So absolutely use the code review tool to surface, again, those low-hanging fruit, those suggestions, those easy fixes. Maybe it’s a typo, maybe it’s something that fixes the structure of code to make it more readable. Absolutely use it as a first pass. But then as a team, you need to monitor

and see is the use of this AI tool, again, is it achieving the goals that we want? Are we spending more time correcting or getting false positives from a code review tool versus it making it faster for us versus it surfacing things that we don’t see? Those are the kind of new questions that we have to ask ourselves as we start to integrate AI tools into code review. One thing I definitely support is

keeping structure in the code review process. So I talk a lot about being very, very explicit in our PRs. Make sure the title can be well understood and you don’t even have to go into the description to know what this is about. Keep it atomic, make it actually manageable to review, link things, put things to documentation, and using automation and tools to help you do all of that because that’s the extra work that

Unfortunately, a lot of software devs don’t want to do. There are a lot of folks that are, know, sometimes we’re feeling lazy. Sometimes we just don’t care. But if that helps counteract those feelings to make sure we’re doing better and just.

being better software developers, I’m absolutely for using automation and tools like that to keep consistent, to add explicit information in our PRs and to, yeah, do the first pass. But I think for fully taking care of the code review, absolutely not. ⁓ For, you know, even going so far as let’s just pass it to say code rabbit, for example, and then it approves it and it’s all automated and there’s nothing in there. Absolutely not. We’re not there yet.

I actually even spoke to some folks on the CodeRabbit team. I mean, I don’t know if they’re going to like me saying this, but they did say, you know, we are absolutely in support of humans still being in the process. We didn’t build this tool to completely replace humans in the code review process. We built this tool so that a lot of those friction points of maybe trying to get feedback faster from the reviewer of explaining things of surfacing easy

suggestions to fix right away, those types of things, we absolutely built it for. And obviously it’s still going to take time to also learn how our team works, how our project works. That cannot be replaced, at least quickly, by AI. Those are the things that are stuck in the corners of our mind that’s what we should be using in the code review process.

⁓ Absolutely use it in moderation and final sign off on code reviews should to me still absolutely be humans.

Brittany Ellich (29:43) Yeah, that’s valid. Big plus one on that. Both Erica and I are at GitHub, so we use the GitHub code review quite a bit. It’s just sort of built into our process as we’re testing it out. And I agree. I think it’s like a step above like the ESLint or like all the linters that are out there. And there’s some things that I’ve learned from it that I’m like, I didn’t think about that. But there’s so much that you just can’t feed into AI. you can’t.

feed in all that extra context of all the other systems that it has to interact with, or if there’s multiple teams working within a code base, it’s not like it has that context of like, this is how this team prefers to do something versus this is how this team prefers to do something and the conflicts there. So maybe one day, but I don’t think we’re there yet. And it seems like with more and more AI, we’re spending a lot more time reviewing code than ever before.

Erika (30:27) Yeah. And

Adrienne Braganza (30:28) Yeah.

Erika (30:28) it also, like, I don’t know. It’s still, like, I still know that it’s up to me to own whatever code is in my service area from, a mental model perspective. And I don’t think there’s anything that can replace pull request reviews in building that mental model of the code, aside from maybe writing or modifying it yourself. But, like,

If I don’t understand the source code that’s going in, there’s no way I’m going to be able to tell if some generated code is legit or not. If it tells me this is the way to do this thing, if I don’t know what it’s going to or what it’s referring to, then sure, I’ll take your word for it. yeah, it can really…

I can really see how it would shoot us in the foot as developers to wholly offload the mental work to AI. Whether, like you said, whether it’s laziness or some kind of efficiency gain or any of the motivations, sorry, you still have to use your brain.

Adrienne Braganza (31:39) Yeah, I think a lot of folks miss that part is what I’ve seen lately is a lot of folks are introducing AI code review tools because they are being measured by metrics that are like misused. that’s one thing I kind of touch on, but that could be its own book. But you know, if you’re if you are

⁓ rating or monitoring the performance of your devs based on some arbitrary single measurement of like, how fast did you close your PRs or how many did you review? And you only take that single measurement into account without looking at the whole story. I mean, that’s some of the reasons why some devs I’ve spoken to are like, well, yeah, we’re very much in support of the AI code review tools because it’s going to help me review more faster.

with the goal of, you know, gaming that metric. So it’s really important to kind of, you know, remember that these might be the reasons for why we unintentionally make it worse for ourselves, even though we think we’re doing the right thing. And just take a step back from those types of reasons. Always go back to like, what was the whole point of why we wanted to do a code review in the first place? this fits in into the wider

ecosystem of like a fully robust CI CD pipeline, you know, a lot of folks are like, well, I have all that automation in place. Like, why do I even need a code review? You know, it’s going to be caught or if something breaks in the staging environment, it’s okay. that’s, that’s not the point. The point is there still needs to be some sort of oversight of knowing what’s going on in your code base. And for most teams, the only place where that happens is the code review. otherwise,

it’s when you’re pair programming, but then how do you share that knowledge across the team rather than just the two that were working on it? And again, if you have to reference something in the future, even if it’s yourself six months from now and you’re like, what did I do here? Why did I make this change? I don’t remember. I don’t remember what happened two weeks ago. So the more documentation that I have, not just of what is happening, but why,

a lot of what’s missing and that’s what takes so much longer to get back into a code base, I argue, is because you’re trying to understand why something was done the way that it was done and when you go back into it, you’re like, you know, maybe you try something that was already tried and nobody’s documented why that implementation didn’t work and there’s some quirk and so, yeah, I digress, I’m going on a tangent now, but you definitely just need to take everything into moderation.

and see what those initial goals were for or why you establish a code review in the first place.

Erika (34:29) Well, we could, I think, talk about this for many hours. But I think that’s a good place to leave our conversation of the motivations and some really practical ways to integrate some of this book and the contents to our own teams. And one thing that really shines in this book is

is so much personality and truly like the joy of going through this with you, with all the illustrations and you also talk about emojis, which, you know, especially in like a remote first environment ⁓ can kind of communicate a lot of this intent and enthusiasm, personality that…

might get lost in sort of like a remote, remote first environment. So our fun segment today is, I’m call it Emoji Personality Check. So this can be in your code review personality or some kind of like other area of your life where you feel like you could really characterize it in a single emoji. And so what that emoji would be,

sort of what part of your personality it describes and any more you want to share. So we’ll go around. We’ll let you go last so you have a second to think about it. So I feel like a lot of my life is captured by the sweat smile emoji. Probably as evidenced by the name of this podcast as being overcommitted. I always have a lot going on.

But I do try to approach it with some semblance of joy and sense of humor. So it’s usually not the crying emoji. It’s usually like the, I’m barely there. I’m making it work and I got a smile on my face, so.

Adrienne Braganza (36:17) That’s

the, that’s personified as an emoji.

Erika (36:21) Yeah.

Exactly. ⁓

Brittany Ellich (36:27) I love that one.

I feel like the one that I want to reach for the most when I’m like adding a, an emoji on a comment or something like that is the upside down smiley face. Because that one is just like communicates to me like, why is this like this? And that’s usually what I’m asking myself over and over as I’m investigating a problem or, you know, hopefully not with code reviews as much because that could come off a little bit offensive to some people. But yeah.

Adrienne Braganza (36:47) You

Brittany Ellich (36:54) I think that I really like that one and I wish that that one was more available.

Adrienne Braganza (36:58) I feel like we’re cut from the same cloth because I have like when I first thought about I’m like well Sweat Smile is definitely the one I use the most and then the second one upside down I’m like, yeah, I do that a lot and I’m now looking at my own phone to see what I’m using so lately There’s the one that’s just the two eyes, but the mouth is straight just and I think that’s

I think that’s a good one for me too. That definitely explains my personality. I would say fairly accurately after those two because those two are way more like higher on the tier, but there’s just so many things now where I’m… I guess it comes from a place of like…

Either, huh, I didn’t know that, or huh, is this really the world we’re living in, huh, did I really do that? It could apply to so many different things. So I think that’s a good one to have. The only other one I would put is probably the drooling face, because I really like to eat food and desserts.

Erika (37:40) No.

Well, super fun. I might have to incorporate the emotionless emoji more in my life as a good balance. Yeah, like the zero reaction.

Brittany Ellich (37:52) that’s very relatable.

Adrienne Braganza (38:05) Yeah, I

think it’s going to be healthy for all of us because I think also before I would probably either answer too quickly or say something and I guess that one’s a good one now. just, let’s just take a moment. Let’s just, hmm. Yeah. Is it worth it? Is it worth it? Yeah. Yeah.

Erika (38:17) Yeah.

Brittany Ellich (38:19) I love that.

Erika (38:21) Well, thank you again, Adrienne, for joining us and ⁓ thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. And Adrienne, if our listeners want to follow you, where could they do that?

Adrienne Braganza (38:39) Yeah, check me out on Blue Sky. It’s at abt.bsky.social, because I haven’t switched it over to my domain yet ⁓ on the to-do list. And yeah, just on LinkedIn or on my website, adrienne.io

Erika (38:56) Well, until next week, check us out on Blue Sky for our show notes and any episode follow-ups and share with your friends. Goodbye.

Adrienne Braganza (39:06) Thanks.