We're all becoming reviewers (maybe we already were) with Jacob Walls

Speaker 1: Good morning everyone. Thank you for for our coming to our talk or Jacob's talk. We appreciate everyone here. We appreciate your time. So we're going to get started. Just want to introduce Jacob. And he will tell you a little bit about himself and what we're we're gonna be trying to accomplish this morning. Thank you. Good morning, everyone.

Speaker 2: Thanks, Kenya. Yeah, and thanks everyone for coming to this talk and thanks for the invitation. I'm always looking at what's going on in Django. Space with a lot of pride and admiration from afar. So it's cool to be able to Talk to y'all. So I'm Jacob. My talk is we're all becoming reviewers. Maybe we already were. I'll tell you a little bit about myself in a second. But what this talk is going to be. I'm going to talk about some concepts in software testing that have been very important to me in my career just as a developer and also as an open source contributor. And I'm hoping that's especially that A lot of things are changing in software development these days, and a lot of attitudes about Gen AI are starting to affect our attitudes about code review and testing And so I'm kind of hoping this is going to open up an interesting conversation where we can um

Speaker 2: talk about some of these concepts that have been important to me. Um Given that software testing was my first role in software, actually. So a couple words about myself. That's me on GitHub, it's just my name. My original training was in music composition and technology. Like many music technologists, uh, you end up kind of fiddling in programming to make your little electronic music thingies go whizbang. Um and so it was kind of natural that after school I ended up um working on a um in a in a QA and development role for a sheet music retailer who was working on a sheet music search engine. So I was doing a lot of work with um loading sheet music into Python and and dealing with symbolic representations of of sheet music. That was exciting. And But around that time we were working on that project, COVID hit and the business changed, and I was no longer working on these sorts of RD projects.

Speaker 2: And I realized like, okay, how can I kind of stay in this field? How can I keep working with Python? And after you know, my more senior colleague had left, I didn't have as much over-the-shoulder mentoring. And I was like, how can I keep learning from senior developers And so for me, open source was really a way to scratch all three of those itches, like level up my skills, get more mentorship, and keep working on Python professionally. Um so that helped me, you know, get into some other roles. Um, and so I've been And then projects like Django, where I learned more about the web, never really stopped being important. So I've been a Django contributor about as long as I've been a Django user since 2020. I've been a Django Fellow since 2025, which as you may know is a paid role to support the maintenance of Django. Some other open source projects I've been involved with. either in paid roles or as a volunteer

Speaker 2: include Arches, which is a project I was working on in my last role, which is a full-stack web development platform built on top of Django for cultural heritage organizations to m to present data to the public. Um Music 21's music library and Pilot Pylin's a Python Linter. I didn't even set out to, you know, become involved in that project. I just wanted my builds to stop failing. And so You march off to write your little bug report and then you realize that nobody's going to fix it unless you fix it yourself. And before you know it, you're hooked. You're you're on the bleeding edge and you're checking development and testing your builds. And um so it's just a cool little Um story about how once you kind of catch that open source bug, you know, interesting things can happen where you can become more involved in a project But to reiterate what I said a second ago, my first software role was in manual

Speaker 2: QA. And I definitely feel like that affected how I think about software, even though I'm no longer in a like I know after that first role I never had another role that was like software QA as my title. Um And um this, yeah, that manual QA role. What I mean by manual is that they didn't show us the code. I wasn't down, I wasn't pulling down pull requests and reading the code, right? It was black box testing. Um I'll speak about that more in a minute, but I think my just in a nutshell, I think my career would have been totally different if I hadn't had that first professional role in software be QA oriented. So I want to start with an image. This is a painting that struck me on a recent visit to the Metropolitan Museum of Art here in New York.

Speaker 2: It's called Madame Kupka Among Verticals. It's a portrait of the artist's wife. I think another title for this painting could be Open Source Maintainer in a Sea of Generative AI pull requests. The just overwhelming you can read about it. I'm not going to belabor the point, but you know, if you're following trends and open source, you know that a lot of projects are talking about what do we do with the flood of contributions that demonstrate varying levels of appropriateness for the project, varying levels of adherence to project norms, varying levels of understanding. My question kind of is like, was this the point? Right? Were the creators of generative AI tools intending for this to happen? Um, and if you sort of take a step back from open source and just think about corporate,

Speaker 2: you know, the business world. I think yes, many people would say yes, this was the plan to just flood this amount of work at people. Um There's this talk given by Corey Doctorow, who's a writer who spends a lot of time thinking about tech and AI called the Reverse Centaur's Guide to Criticizing Criticizing AI. Whether or not you like are a you know AI proponent or AI skeptic, I think it's an interesting talk to look at. He develops a couple of notions which are kind of negative notions about or notions about the negative effect of AI on workload. The one I want to talk about first is called the accountability sync. I don't think it's his term, but he develops it nicely in this talk. The it's

Speaker 2: accountability is kind of senseless when you think about a machine. Accountability is really a concept for humans. So he he talks about, well, one thought experiment he uses is um radiologists at a clinic. Let's say your radiologists usually process about a hundred x-rays a day. You can imagine management saying, we've got this great new AI tool. It's going to detect, you know, if you missed a cancer on that X-ray. And so we're going to send you back a few to double check at the end of your shift. So your productivity might actually go down when we adopt AI. Instead of processing 100 a day, you might process 97. Because we're going to send you three to double check. But that's okay. We just want to find all the cancers. We're willing to accept a drop in productivity. He contrasts that with what's actually happening in many cases, or at least what people say is happening in many cases, where instead of going from 100 down to 97, people are going from 100 up to 500, where their their workload just grows exponentially

Speaker 2: And they're told to just just spot check it. Um and don't worry, the AI is gonna do all the work, you're just gonna do the spot checking. And what happens though is that when something goes wrong, the human gets blamed instead of the AI instead of the AI, because it's senseless to blame anybody but a human. So that that phenomenon is called like the accountability sink. Just drive the volume so hard and blame the human at the end. The other idea he develops is the reverse centaur. A centaur, magical creature, magical pony, can give you, you know. magical powers, but a human is riding it or human is driving it. A reverse centaur would be where the AI is the one with the magical powers and it's just driving the human as a tool.

Speaker 2: In in the talk, there are these, you know, kind of disturbing things you read about, you know, Amazon delivery vehicles that have eight cameras trained on the driver's face to make sure that they don't take breaks and stuff like that. You you read this and you have to take a shower afterward because it's just, you know difficult to follow uh or you know difficult to read. Um so this is like this is the negative view about like was this the point right was this the idea to drive so much work and um you know, just blame the human at the end. Um so that's the bleak side. Is there any, you know, non-bleak side, you know, to this? I think, well, maybe, yeah. That now Proponents would say like, well, now planning and testing are cool again. Maybe we're all becoming reviewers, and that's okay, because reviewing is a cool activity now.

Speaker 2: Testing is a cool activity now. Going from 100 x-rays to 500 x-rays is great because really I just want to be doing the spot checking. Um so my question in this talk is So if this is not bleak, if this is good, then something about this needs to be distinctly good. Like testing needs to be good because there is a distinct testing mindset. And this is this is something that's kind of tough for me because at the beginning of my career, like I just said, like starting in software QA was a huge part of my career. And so I definitely feel like I think like a tester. But other times, as you can tell from the title of my talk, I question that notion. Like I don't necessarily think that developing and testing are two different mindsets

Speaker 2: I want to share this quote with you. If you'll indulge me. This block quote comes from the Cypress tutorial, the section called Understanding the Testing Mindset. Cyprus is a testing tool for end-to-end tests on in web development. It's like Playwright, if you've heard of Playwright um or to a lesser extent like Selenium. So in this in this quote, which comes at the front of their tutorial about teaching developers to write automated tests in Cyprus. There's this kind of philosophical blurb about the testing mindset. So I'm not going to read it out loud. I'm just going to give you a minute to read it and I want to ask you if this if this rings true for you or if this or if this rings false.

Speaker 2: So in this quote, I mean there's kind of a built-in assumption that there are separate teams Or that you're even on a team, you know, if you're a solo developer, you're not really a team of one. So leaving aside the question about whether or not, you know. It rings true for you that there are different teams in the first place. Does this sense that there's um a completely different mindset a completely different set of responsibilities. Does that ring does that ring true for folks in their experience or does that um not resonate?

Speaker 2: We got some interesting stuff in the in the in the chat. James is mentioning that one one separate role for QA involves uh um checking the acceptance criteria, making sure that the features match the acceptance criteria for the project. So it's a little different than breaking things. Yeah, it's a great point. Um so I mean this I I don't want to pick apart this blurb. I just thought it was interesting because it it sort of assumes that this is not controversial. It just kind of assumes that like You need to have different teams that have different responsibilities. But then the blurb ends with, okay, but you're going to need to put on that hat. You know, these are separate responsibilities and they're separate mindsets, but

Speaker 2: If you're gonna start writing tests in Cyprus, you need to put on that tester hat. Yeah, everybody uses mindsets to get through the day. So I totally understand the switching hats thing, but I just, you know uh like everybody switches hats all the time. Like this this sort of Yeah, this this sharp division between development and testing. I kinda kind of I kind of question. Um so I I to tell you briefly how things um felt or worked in my first role in QA. You know, there was this distinction that the company that I worked at, it was a medical records vendor. There are two in the in the US that are the biggest providers of electronic medical records for hospitals and clinics. One is now

Speaker 2: has been purchased by Oracle. The other one is um it's been privately held since forever. It's called Epic. I worked there. They had a whole division of manual QA'ers. Doing black box testing, like I said, like you'd get the description of the changes and you'd get the testing instructions and you'd set off to click around in the UI and try to break it. Nothing reached QA unless they'd have gone through programmer QA first, which was what they called code review. You know, they caught they called it programmer QA. I think it's interesting they didn't call it code review. They they The the idea was to do quality assurance. The idea was to do testing. And the idea was that a programmer should do some white box testing and look at the code and look for things that were missed. But it's interesting that they didn't call that there was this sense at the company that that wasn't real QA.

Speaker 2: Like programmers couldn't really do QA. You didn't want programmers doing QA. You wanted manual QA specialists doing the QA. And a lot of the programmers I worked with felt that way too. Like they didn't really feel like something was tested unless a manual QA tester looked at it with a black box, you know, no knowledge of the code and did that manual verification. So with all the changes happening in in um tech right now with AI driving all this volume at us, it's making me think like, okay, where is like What's the plan here? Like what's what's the intent behind it? Is it to make us do programmer QA now instead of development? Because that's the third item that's not on the screen now, right? It's development. Sort of like development flows down to programmer QA, flows down to

Speaker 2: The real, the real stuff, the real QA. And so like are we being just nudged down the ladder where the idea is that Claude does all the development and we're doing the programmer QA? Or is Claude going to do that too? And then now we're going to be driven down the ladder to Manual QA and is that is that good or is that bad? Anyway, so uh Again, this idea of like being driven down the ladder only really makes sense if you believe that they're different things, or if you believe that QA is about breaking things as opposed to building things. So Obviously there's a there's a cost thing going on here as well. Like the people that are driving generative AI think that it'll be cheaper to just push us all down the ladder to programmer QA and then to QA. I guess we'll see whether or not that turns out to be true.

Speaker 2: Yeah. So a couple things that I, you know, I I learned as a as a QA that I've kind of carried with me in my career as a developer. um that maybe relate to this question of is there really a difference between QA versus programmer QA? Is that You know, an important part of my job as a software tester was to apply pressure at weak points. And this is maybe what was helpful as a black box tester because I had to learn as a user what parts of the software were more fiddly. And then once I gained that knowledge, yeah, I just continually drove as much pressure as possible into those weak points. So to give you an example, You know, hospital software has a lot of intake forms for patients

Speaker 2: and they're long, so that you have to scroll up and down. What happens when you leave focus in a field and then scroll that field off the screen? Should it accept your changes? Should it discard your changes? Should it validate? If there's an error, should the error force you should should the error force that field to scroll back into view and make you deal with it? In really critical workflows like physician order entry and stuff, we had all that stuff nailed down perfectly. But for anything that was a little more gray area, like a nurse taking an interview about what medicines are you taking at home. Like we can't really validate that because if you say you're taking something at home, who are we to say that you're not taking that at home? Like we're pretty much just putting in whatever you say about what medicines you take at home. Nobody needs to sign off on that. But there would be these interesting questions about like, okay, well what if you

Speaker 2: you know what if what you typed in what what if what you typed into the field doesn't match what's in the system and then you scroll out, should we accept that or discard that or should we validate that or should we force you to address that before we keep moving? I realized that we didn't have as like a clear idea about what was supposed to happen there. And that really taught me to just always drive traffic into those weak points. Other weak points would be like the lock button that locks the screen, right? Because if you're uh in the hospital, you can't walk away from your computer because other people could just order opioids and stuff. You know, you gotta lock the screen before you leave your computer. I would start putting all these cases together. Like let's leave focus in this field and then let's scroll it out and then let's hit the lock button, you know, and just terrible things would happen. So um This kind of taught me or I adopted the mindset that basically all software has these weak points. It's just inevitable.

Speaker 2: And it's it's kind of your job to just drive as much pressure into those weak points. Other things that I found were that bugs cluster so that if you find one bug in an area, there's likely two. If you find two, there's likely four. And if there's four, you better get some help because there's probably 16 and you're probably going to need more help to find them. You're probably going to need fresh eyes because fresh eyes find a bugs. Now delivering 16 bug reports is not a pleasant task necessarily for the person writing the bug reports or the person receiving the bug reports. But I also found that keeping your feedback compassionate and concise Not catastrophizing, not trying to speculate about the impact, just keeping things straight and to the point meant that you could deliver a large volume of bug reports

Speaker 2: and the developers wouldn't hit you. And I feel like this happens at Django. Like, you know, before I was a fellow, like I mentioned in my last role, I was working on a full stack framework built on top of Django. And I in in that last role, I was I was trying to use the Django ORM to kind of do some wacky stuff to model totally generic Data tables. I gave a talk at DjangoCon Europe last year called Dynamic Models Without Dynamic Models. And in it I talk about how I found ways to leverage the ORM more to model data that was ultimately shaped by user-defined schemas. So instead of a book model and an article model, I had these generic tables and I didn't really know what was in them because our users were defining the concepts.

Speaker 2: So I was kind of pushing the ORM to its limit to um and I I discovered where all the I discovered all the all the areas I needed to stay away from in order to make my project work. And I realized when I when I came back to following Django development a little more closely after that project was wrapping up I noticed that there were some new features landing and I thought, hey, here's how I can contribute back. I can take these new features that are landing and I can retest them against all of the, you know edges of the ORM that I had just encountered myself. And since bugs cluster, those are important places to like keep pushing. And you know, this these new features that I that I was testing was the composite primary key feature in Django 5. 2. It was in great shape when it was merged.

Speaker 2: Uh, and everybody who was involved did a great job on it. And but I was I was thrilled that the when I was providing additional feedback, um it it all it it felt like it was welcome feedback. Um people knew that I was that this was a contribution, this was not um unwelcome. um kind of no matter the volume, even if you have half a dozen tickets. Okay. That's a nice story, but also I have to slow down and remember that like Think about the story that I'm telling you. Like I'm talking about accountability syncs. I'm talking about reverse centaurs. I'm talking about this attitude that things are always broken and have weak points and that you should always be driving uh traffic into the into the weak points and that bugs cluster and that there's there's always more bugs. It starts to sound like st

Speaker 2: I'm a pessimist about technology. I think some attitude in that neighborhood is perfectly healthy and shouldn't be discouraged. Like um It's not, you know, it's not arrogant to have some s some version of this thesis that like things often have issues. I was buying a flight the other day to attend DjangoCon and I literally could not submit my payment information to buy the flight. It, you know, I struggled and struggled and realized like, oh, let me try another browser. I'll try Safari. And it went through. And I thought, forget, forget even people that aren't comfortable with technology. Forget, you know, older folks. I almost forgot to try that. You know, like and I work in this field. So it's just like

Speaker 2: if I can't figure out how to buy a flight, like this is bad. Like this, like a lot of stuff these days is broken and I don't celebrate it. It's just it's just what it is And if that resonates with you in any way, I have a I have the book to recommend. I enjoyed this this read. You know, it's from 1984, so it's not talking about AI. I'd love to see Charles Perrell write a book about generative AI. Um, but this social scientist wrote this book in the 80s, a few years after the Three Mile Island nuclear accident in the US. Um that that kind of loomed large in the US in the late 20th century, the Three Mile Island accident, it kind of halted the movement toward nuclear power.

Speaker 2: In this book, Normal Accidents, Living with High-Risk Technologies, one of the theses is that in high-complexity systems, there are always accidents. And so they're not really accidents, they're just normal. In in in high complexity, tightly coupled systems, you should just contemplate that accidents are an integral part of the system. Here's a block quote. In complex industrial space and military systems, the normal accident, generally, not always, means that the interactions are not only unexpected, but are incomprehensible for some critical period of time So the book opens sort of uh with an analogy of kind of what happened at the Three Mile Island accident, but told from uh a story of somebody getting ready for work and missing an important job interview and all the things that you would never think of possibly being connected to each other, all contributing to

Speaker 2: a systemic failure that prevents you from going to the job interview. And what's interesting about one thing that's interesting about the Three Mile Island accident is that it took the engineers and operators a long time to even start solving the right problem. They spent so much time solving a problem that was just not even what was happening. And some of the critical failure points, like a valve that was stuck open, it just wasn't even on their on their board. Like they didn't even have any sensors monitoring whether or not that valve was open. So there was just a huge part of the system was just not even observable during the accident. And his point of the book is that with complex systems, like your observability can never really catch up to the complexity. So you're just going to need to accept that with complexity there's going to be stuff you can't see.

Speaker 2: And stuff you can't see means stuff you can't operate. Um so I don't know, with Gen AI, it's a lot of stuff I can't see. So I'm like I said, I'd I'd love to see Charles Perro's book on the world that we're about to enter into when We're just uh we're the accountability sinks where stuff is just coming at us and we can't really see what's going on inside the machine. Um so Okay, that's like a particularly negative view. Just like I did before, I want to back off the negative view just a little bit, right? What's what's the what's the less bleak view? Um I think You know, what was I saying a minute ago? Like, okay, as a QA, I had to learn to adopt this mindset that stuff's always broken, and I should assume assume that it's broken and try to prove that it's not.

Speaker 2: Um If you put it like that, it sounds super arrogant. And it's not nice to be an arrogant person. So you need to like reframe it. A less arrogant way of putting it would be like the testing mindset is not that it's probably broken, it's that it's probably fragile. That's still a little too committed to the idea of techno-pessimism for me. So like you could water it down a little bit more and just say, like, well, it's probably bespoke. Like it's probably just highly specific. And then the totally ego-free way of thinking about problems in software would be, well, it's just probably significantly different if I alter this little piece over here. Right? If I leave focus in the field and scroll out, something different probably happens. If I get the UI into a certain state and then I hit the lock button, it's probably significantly different like the the workflow is probably significantly different when I log back in because I hit that lock button.

Speaker 2: So that is kind of what has affected how I think about development. I think about how just little all the time I'm thinking about how little changes can have an improbably large effect on a workflow. When I left that manual QA role to go back to grad school for music, people knew that's why I was leaving. And so there was, you know, people would tell me like, oh That's why you that must have been why you found all those bugs. Like must have been that music. This must have been that music training. And you know, I kind of laughed at the time, but I think there's something to that. We all bring our own backgrounds to our work. And I think for me, I Definitely brought from my training in music this attitude that little changes in one part of a system can have an outsized effect on the whole. The traditional training for

Speaker 2: Composers, and it's you know it's changing these days, but um not just for composers, also people who just take music theory in a music major, often involves um harmonizing chorals in the style of Bach and the way these exercises are supposed to function is that when you choose notes, you have to take careful uh or you have to take care around how your choices of notes produce lines uh like melodies and how how they also form chords. which are simultaneities. And so you move a note because you're trying to fix the melody and you've broken something in the chord. Or vice versa. You've you've tried to fix something in the chord, but now it's out of range for the voice. Or just, you know, and that's only two dimensions of of sound like like uh well actually that's just one dimension of sound.

Speaker 2: That's just pitch. But sound has like five different dimensions. There's pitch, there's also rhythm, there's volume , there's tone color or timbre, and there's spatial location. And so when you're working with more than just a little exercise, you're working with a real piece of music, almost any choice you make and have an if can can throw something out of whack on any of those five different planes. of sound. And um I mean to me that's what software is like. You change one little if condition And suddenly you've broken an authentication pathway, or you've created a security hole, or you've created a performance problem, or you've, you know, just like those five dimensions of sound, there are at least as many dimensions that you have to think about as a web developer. uh you know accuracy, pattern, and you know, adhering to your codes, uh, architecture, architectural patterns, uh, like I just said, security, performance, the list goes on.

Speaker 2: I'll leave you with a thought about kind of again this connection between my background in music and and my attitude toward testing software and how one little aspect can have an effect on the whole. I have a memory of um hunched being hunched over an upright piano in my little shared teaching assistant office. working on a piece of music and I was trying to decide which uh which octave to place a Glockenspiel note in. A Glockenspiel is a like a small metal xylophone. I knew I needed the note F, but I didn't know if I wanted the low F or the high F. And I was thinking about all the effects it would have on the rest of the s on the rest of the piece and the texture and the cord and Everything. And I look up at the clock and it spent 40 minutes and I was no closer to a decision about whether I wanted the low F

Speaker 2: or the high F. And I remember feeling so defeated, like, oh, you need to go touch grass. Like go for a walk. You're spending 40 minutes trying to decide which F. to pick. Um but I laugh about that now because, you know, I would be a totally different musician if I didn't have the ability to spend forty minutes debating with myself which octave the F should go in. I've heard other people call this the jeweler's eye. that um you know think about a jeweler they have those tools that they put up to their eye and they you know they've got the they've got the jewels down here and they're they're trying to they're they're looking for these little minute changes that make a big difference People like well-crafted stuff. People like stuff that's had the jeweler's eye on it. And some of this stuff is like fundamentally incompatible with the volume that we're being encouraged to deal with now.

Speaker 2: So we've it seems like we've gone from move fast and break things to move even faster and break everything. But it's okay because we're gonna break it all and we're gonna have the QAers fix it. Like we're all reviewers now. Like we'll just we'll spot check the stuff that's Not working and you know I don't know, we'll just try Safari instead if you can't buy your plane ticket. Um maybe that works, but that all works if we all opt into this new testing mindset. Um And for me, a big question is like, is there a separate testing mindset? And does that really match how we think about technology? And uh this these are the these are the provocative questions I'm going to leave you with.

Speaker 2: I don't have concrete answers, but in this talk I just wanted to share with you. Concepts that have been important to me as a software tester and that I continue to think about as a developer and just kind of invite a conversation about the relevance of these now to you know the new world we live in. So thanks for listening.

Speaker 1: Thank you. Thank you, Jacob. That was very, very provocative. I appreciate it. So I want to open up for a couple of questions. Do we have any? Wanna um show of hands or throw the questions in chat?

Speaker 3: I do have a question. First of all, thank you so much, Jacob, for the presentation. I was wondering how do you handle to be a compassionate while while you are reviewing, how do you approach your first reviewing?

Speaker 2: Thanks for the question. So you're you're asking how how do I incorporate the idea that feedback should be delivered with compassion and grace when dealing with code review? Yeah, um I I mean it's um it's paramount because uh you know this is This is one of the biggest risks to believing that everything like you know, I said all software has weak points. If you really take this to heart, you start to become a techno-pessimist and you think that everything is wrong. when really everything is wrong is just a useful mindset to get you started thinking critically. Right. And so you just have to remember to just put all that to the side when you're actually dealing um with looking at somebody's work. I would to f as a preamble to my answer to your question, I'm gonna just zoom out briefly and talk about for me it was helpful to have

Speaker 2: contributed to different projects both by switching jobs relatively frequently for different reasons because my career was kind of shifting from music tech and then into the web. I kind of switched jobs frequently. and then also contributing to different open source projects, not just Django but other ones, I kind of realized that everybody likes their porridge at a little different temperature, you know, and that Some projects use black and some people hate black and that's fine. And some people like single quotes on their JavaScript and that's fine. Like it's you're not a worst developer because you use single quotes in your Java or double quotes in your JavaScript or you do or don't use prettier These are kind of trivial things, but like more substantial things. You saw that like, oh, really smart developers do something, some things completely differently than I do. And so I just remember that before I give the feedback, and then I can hopefully do a better job.

Speaker 2: I'm not perfect, but I I try to recognize that in the comments and say like You know , did you consider doing XYZ instead of this should be like ABC or this should be XYZ? And you know, sometimes sometimes it's just a a shortcut because maybe I really know that I mean my my my experience with what I'm talking about definitely varies. There are times when I know more about what I'm talking about, sometimes when I know less about what I'm talking about And sometimes in the in the areas where I have more experience, I kind of can anticipate where the conversation is going to go. But many times, no, the question is a literal question. Did you consider is not just a way of being like Soft. It's actually a genuine question. I genuinely want to know the answer to. Like because my assumption is that you did consider it.

Speaker 2: And I just want to hear more about it before I like form my opinion about it. Um so I I I feel like That attitude sometimes manifests in a comment that begins, did you consider? But that attitude, even if I don't spell it out like that, informs the comments that I leave where I'm I'm trying to understand why the other person made the choices. And I kind of suspend my own opinions until we get more of the conversation out. I think Another thing that's challenging can be when reviewers and developers come to code review with different expectations about how many iterations they're going to be or how much time it's going to take. And That's um it obviously if there are time constraints like in a professional situation you may have a specific time budget that you can't spend more than two story points on

Speaker 2: on something. And so everybody just has to have all of the information. They need to know if there's not time to do more review. Because it can be un yeah, it if you get caught by surprise by that fact, that can be really challenging. Um But as long as people understand, you know, that there's not some external constraint about like don't spend more than this time box on this thing, you know. I think having having reviewers and developers both have a roughly similar expectation about how much work is going to be done during review definitely helps. I like doing work during review. Like I promise this, I promise this answer is coming to a close, but you're asking me about something that I do all day every day

Speaker 2: now. So that's why my answer is longer than probably it should be. But I'll wrap up with this I I like that work, real work happens during code review. I don't think people should, I mean in an ideal situation, I don't think people should be working on their masterpiece all by themselves at their easel. You know, I feel like you should avoid polishing it to 100% and then share it, you know, because there's no point in polishing something that's going to change significantly. So and sometimes that leads to misunderstandings where then people give you polish feedback. And it's like, yeah, I was gonna do that later. Like I I know that React component could have been smaller. Like, I know how to do that. I'll do that later. Like, don't give me feedback on making my React component factored smaller. So and and I don't have a good answer for that. Those those

Speaker 2: those mismatches of expectations during the review process, both in terms of how long and on what topics, are just ordinary everyday. problems. I don't know if that answers your question at all.

Speaker 1: Excellent. Well we see another question from Rachel. A follow-up to that. She says, have you ever been on the end of a non-compassionate code review? And if so, how how did you handle that?

Speaker 2: Um yeah, I you know, it's it's I've probably had some that I've blocked from my memory, so I may not be able to answer in too much detail about those. I have been in in code review iterations where I feel like there's been a um Just a maybe a communication style mismatch where people leave really blunt feedback or really casual feedback and maybe I like I'm not I don't think of myself as a super uptight guy, but maybe I'm a little uptight in that I don't want code review feedback that's super casual, you know, like hey this sucks or like hey don't you know um Just a comment that just says why with a question mark.

Speaker 2: You know, it's like if you have a good rapport with somebody, maybe you know that there's not attitude behind that comment. But if you don't really click with somebody you know, just leaving a comment that's just a question mark is kind of like a little off-putting. Um it it assumes a rapport that isn't there yet. Um So it depends on how many times you're going to interact with that person. Like if you're going to if that person is the main colleague on your team, it's going to be up to the two of you to you know, tell each other that you don't like that. Um or you could just cut your losses and just, you know, realize that Somebody might be leaving me feedback like a bare question mark and then realize that that's a them problem. It's not it's not a you problem.

Speaker 1: So we'll take one last question on the recording and then turn the recording off and open it up for anyone else. Natalia has left a question. How do you define compassionate? in the global context, like Django's community, where communication style and expectations vary considerably.

Speaker 2: Um yeah, this is uh something I think about all day, every day. I mean it's it's um People come from different backgrounds, people come from different cultures, people come from different communication styles. So the example I gave about the bear question mark, like that's a really significant difference in communication styles. And so I think there should be some effort to bridge that gap. But there are other gaps where, you know, maybe you can't, I mean, well, let me back up and give a more clear answer. That situation is a case where if I if I was working with that colleague closely in my full-time role, I would probably try to spend some energy changing that person's community, convincing that person to change their communication style, because I don't think that's healthy But in many situations, you would never do that.

Speaker 2: Like it's not really your role to be changing someone else's communication style. It's just to kind of um figure out how to um make the best of it, right? Or realize that as I said a minute ago, that it's it's that's all it is. It's it's a nothing more significant than a difference in communication styles. And to understand that um you know uh friction is gonna happen and that it's mostly it that it that could be the reason that it's not personal that it's just difference in communication style

Speaker 1: um Yeah. Okay. Well, um, let's go ahead and um turn the recording off.