Ctrl Alt Tech
Welcome to Ctrl Alt Tech, the podcast where technology meets curiosity. Each episode, our host chats with expert guests to explore a wide range of STEM topics. We aim to make complex ideas accessible and exciting, so join us for thought-provoking discussions and, hopefully, learn something new along the way!
To learn more about SciBite and how our ontology-led approach ensures robust data management visit https://scibite.com/
Ctrl Alt Tech
Episode 5: Pull requests with Ben Lomax
Ben Lomax is a lead software engineer at Kraken Technologies, and is passionate about creating high-quality, meaningful software. The inspiration for today’s show comes from Ben’s talk at EuroPython 2024, titled ‘The Art of the Pull Request’. In this episode, we chat about PRs, code reviews, and crafting the ultimate review experience. Also joining us is Brandon Walts, a fellow software engineer at SciBite, who brings a wealth of software development experience to the conversation.
If you are interested in finding out more, check out the following resources mentioned in this episode:
The Art of the Pull Request - Ben Lomax: https://www.youtube.com/watch?v=2upWetU_vUc
“How to Make Your Code Reviewer Fall in Love with You” - blog post by Michael Lynch: https://mtlynch.io/code-review-love/
Emma 00:00
Okay, cue the music.
Emma 00:15
Hello and welcome to Ctrl Alt Tech, the podcast that brings you interesting and engaging conversations from the world of science and technology. I'm your host, Emma, and today I am joined by Brandon Walts and Ben Lomax. Brandon is a colleague of mine here at SciBite, where he works as a software engineer. Ben is a lead software engineer at Kraken Technologies. And Ben and I met at Euro Python last year, where he gave a talk titled the Art of the Pull Request, which is the jumping off point for our conversation today.
Emma 00:55
In this episode, we chat about pull requests, keeping the human element in your PORs, and we ask, why bother with code reviews anyway? If you're new to software development, I think you'd be particularly interested in some of today's takeaways. But as we mentioned, this info is useful to reflect on at any stage of your career. Let's dive in. Hi, Ben. Thank you so much for joining us today on Ctrl Alt Tech.
Ben 01:12
Thank you very much for having me. Very excited to be here.
Emma 01:15
I am really looking forward to our chat today, but I would like to kick thins off by asking you to introduce yourself to us and our listers please.
Ben 01:25
Okay. No problem. So, Hi, everyone. My name is Ben Lomax, he/him. I am a lead software engineer at Kraken Technologies. We develop the software used by, energy companies. So the biggest one of the UK is Octopus energy. And, yeah, in my spare time, I kind of tend not to do a huge amount of coding. So most of the stuff that you will get from me is from the Kraken Tech side of my life.
Emma 01:53
That's perfect. That's ideal. I understand that high quality code, I'd say, is important to you, or that you've spent some time thinking about how can we make code the best it can be for people at like each end of each, each end, of at all stages of the coding process, shall we say. And to add a bit more context, myself and Brandon attended EuroPython last year, and we both were at your talk, “The Art of the Pull Request”, which I'm going to use as a jumping-off point for today's conversation. And I'd like to dive into that a little bit more. Could you start us off by letting me know kind of what, gave you the idea for that talk? Why? Was it something you wanted to explore?
Ben 02:38
Yes. So, this talk very much came from the advice that I was giving to people joining my team, particularly kind of junior developers. But even, you know, mid-level developers, and I think, you know, it hit the third, fourth, fifth, sixth time that I was giving this, this advice to people. And I was like, you know, it's just going to be easier for me if I make a talk. Have it be recorded, and then I can just tell people to go and watch this talk instead of me having to go over all of these points again and again and again. So yeah. So that was my kind of drive for creating this in the first place.
Emma 03:15
Okay.
Ben 03:15
Hopefully it's useful to people outside of my teams.
Emma 03:18
Yeah. That's that makes a lot of sense because, good source of inspiration. What would you say are some of the key messages from your talk then?
Ben 03:27
So key messages from my talk just to, really summarize, 30-minute talk into, three lines. So, the talk itself is around the idea that you can improve the quality of your pull request, kind of independently of the content of the pull request. So you can shape the pull requests in a way that makes it easier to review. And that has a bunch of benefits, both for you and for people reviewing. Some of the ways of doing it. I don't know if you want me to just kind of ping through some of the.
Emma 04:02
Yeah, so maybe we'll talk about some of the key ideas, but what you kind of highlighted about pull requests.
Ben 04:07
In which case. Yeah, I guess, let me break this up into two small bits then. So first of all, so the talk looks at some of the benefits and not just the reviews, but for you as well as the, the author of the PR. So some of these are things like getting your PR reviewed faster, making it easier for reviewers to spot bugs, making it easier to spot bad architectural decisions and offer a better kind of opportunity for learning and teaching from a reviewer to you. So there's a lot of benefits to kind of spending the time in making the PR high quality, not just in content, but in how you lay it out as well.
Emma 04:46
Yeah
Ben 04:47
Some of the tips obviously, you know, go watch the video.
Emma 04:49
Yeah.
Ben 04:50
I highly recommend it. But just to kind of give some of the high-level stuff. The main takeaway, the one that I will still kind of push for people to do the most is keeping your PR small. So it's very, very easy, especially when you've been given, you know, a chunk of work to do to just sit down and keep hacking away at it until you get something working.
Ben 05:13
And then here you go. Here's everything that I've done in one go. Please go and review everything. I have been that person, you know, as a, as a junior developer, I'm just like, right, let's say it's working. I'm done. The difficulty with that is that as a reviewer, it's a lot more cognitive work to sit down and kind of crunch through a whole bunch of stuff, especially if it's kind of interconnected code, especially if either commits aren't well structured or it's just one giant commits of all of the changes and cutting back and forth up and down the PR to try and figure out where stuff's called and why it's called and blah blah blah.
Ben 05:54
So keeping PR small is incredibly valuable. And again, if you go watch a talk, I go into kind of more details on how to do this, but it forces you to split up your work into steps and then deliver each one of those steps as either a PR or as a commit. So take a look at what a small first step is, and giving that as a PR, as a small PR for somebody to review makes it way more likely for me as a reviewer, to look at and go, hey, that's less than 100 lines change. Great. I've got time for that. I'll go through an overview. It's and it's quick to iterate on. So keeping PR small is probably the kind of stuff the main thing that I recommend to everyone.
Emma 06:35
Yeah.
Ben 06:36
To do it well there's a few kind of underlying skills, but that's the, you know, if you want, an easy kind of rule of thumb. If you can keep your PR less than 100 lines, you will have very little problem getting it reviewed by people. It's not always possible. Ignore that. If you're moving files, things like that.
Emma 06:55
Yeah, of course there's going to be outliers to that. But as a, as a general rule of thumb, I might pull you in on this Brandon as someone who's covered a lot of, PRs. Does that kind of resonate with you? I feel like keeping it small is a good way to make your life easier as the code author and the reviewer, right?
Brandon 07:13
Yeah. I think there's a big thing of when you open it and see how many files have changed and how many lines have changed, and just is this something that I can do, or is it something where I'm going to have to schedule a chunk to a day and then that chunk of a day comes and I'm doing something else and then I, you know, it goes off. So I think as a reviewer, there's something that I can do, at 4:00 on a Thursday afternoon when I really don't want to get started on a new project or content switch. Have you done me a favor by giving me something? You know, I could kill half an hour with?
Emma 07:48
Yeah, 100%.
Brandon 07:49
Definitely think size can be an issue or can be, can be a plus. Of course, there's a lot of temptation, then to try to, okay, well, let me make a small PR when doing something bigger where you have context, where you may have a few changes that are all in the same context that, you know, would make things something more sensible rather than, you know, I see a PR and then I'll see another one that comes in two weeks later.
Brandon 08:17
And I think, okay, I vaguely remember having to deal with something similar to this and that. I'll think, you know, maybe that would be nice if both of those had been included, even if it was a bit bigger, because then I can load all that context into my head at once and deal with all of this at once, and then not have to do a couple of contexts, which is a couple weeks apart. So like all these rules there, there's soft and squishy rules, but squishy rules.
Emma 08:46
I think the mention of context a few times there though, is important. I believe it's like another good thing to keep in mind when we're doing these reviews right. We want to kind of give our reviewer enough of the why you're doing something, and not the what that you are doing for them to be able to efficiently review your PR, I guess.
Ben 09:06
Yeah. I agree with, the kind of balance that out with the not throwing more context than you need. If you're doing three changes in the same PR, that's then kind of stepping in the other direction. So it's finding that sweet spot for reviewer to be able to look at that and understand the changes, whilst not overloading them with too much stuff to keep in their head at the same time. One of the reasons that I kind of landed on the name “The Art of the Pull Request,” is that this is very much an art form and not a science.
Emma 09:34
Yes.
Ben 09:35
Some of this just comes from experience of well, I've reviewed PRs and this was way too much for me to handle, so I'm not going to do that in my PR just for somebody else to handle.
Emma 09:45
Yes. An art, not a science. For sure. I want to step back for a minute. I think from touching on tips for the PR review itself, PR review, excuse my redundancy there. If we step back and ask ourselves why do we even bother doing PPs to begin with, it's something you kick off with Ben when talking about the pull requests, you know, why don't we all just push to Main and be done with this?
Ben 10:13
Yeah. Excellent question. So we'll say no. PR is pull requests or pull
Emma 10:19
pull requests. Yeah, my brain went there.
Ben 10:21
Do not worry. I can say like a thousand times, while I was writing my talk, like removing and adding and. Yeah. Anyway. Yeah.
Emma 10:29
So true.
Ben 10:30
So, yes. Why do we even bother to do PRAs? So some of the reasons certainly that I've kind of seen as most relevant, things like finding bugs before they production, making good architectural decisions by having extra people kind of look at your code. And kind of parse that, and think about that keeping code quality generally high. PRs allow other people to see how you're writing the code and see if that's in line with either their own version of best practices, or, even better, the company's best practices or your team's best practices. If we're being a bit more cynical, it also makes it harder for people to sneak in malicious code.
Emma 11:12
I think another one then my favorite one is as a teaching opportunity, right?
Ben 11:17
100%. And especially for the more junior developers out there, listening to this, PRs and crafting a PR, as well is a fantastic teaching and learning kind of space. There's a few different reasons. One is the problems are real, right? You, hopefully solving a real problem which has nuance and it has complexity and it ties into other stuff.
Ben 11:39
And so it's not just a toy example. It's a thing that is like useful to, to do. You also hopefully care enough about it to see through to the end. Right? This is one of the one of the downfalls of doing it in personal projects is sometimes I've looked at this in three hours and I just don't care anymore.
Ben 11:55
And I close my laptop and I just don't figure it out. So that works. Stuff if you're getting paid, if you need to be doing this and it's urgent or whatever, like you hopefully care enough to see if or another thing is you can discuss solutions with multiple people at the same time. Small asterisk, my tech stack to this is always been using Git and GitHub.
Ben 12:15
I'm sure there are other platforms that allow and other version control systems allow this as well. But yeah, so certainly with Git and GitHub, you can discuss solutions to multiple people at the same time. And you also have a written record of the decisions, right. So you can refer to it later on, either as a why did you do this as now bug.
Ben 12:37
Well, we decided together this was the best way forward. Oh hey, I remember us talking about why we did this somewhere, but I don't remember what was said. You can go and find that and have that as a snapshot of the thought process to go back to them. So back to for more learning. So yeah, loads of really good reasons why PRs are good for learning and teaching.
Ben 12:58
I would actually argue unless you do programing or pair programing or kind of programing in person with other people, pull requests, likely to be some of the main sources of learning that you get teaching from other people that you get in a typical workplace. Certainly that's been true of me, of my experience in various places, doubly so if you work in an asynchronous workplace.
Emma 13:24
Yeah.
Ben 13:25
At Kraken very much, I kind of have devs all over the globe. If I'm working with somebody in the US or in Australia. Asynchronous comments on PRs is sometimes the only way of working with somebody.
Brandon 13:38
You know, one thing that kind of struck me when I was going through and re listening to talk to have reading some things like Michael Lynch has written some really interesting stuff about this. Is that how much rubber ducking gets secretly built into putting together a good PR and if you're looking at a lot of the techniques described about how you want to organize your PR so that it becomes more logical and clear, you're secretly you are sort of rubber duck refactoring your code in doing that. And I think that's sort of one of the little untold benefits of some of these advanced PR when you start to really think about it.
Emma 14:19
Yeah, 100%. And if you are listening and you're not sure what the rubber duck is in reference to, that's actually come up for me only very recently where the solution to my problem was so obvious. So rubber duck kind of debugging, I guess, is the idea of, imagine that you need to explain your problem to a rubber duck, but like articulating your problem in regular spoken language and only very recently just saying my problem out loud, to a team member solved the issue for me immediately. And I mean, I felt like an idiot, but my problem was solved.
Ben 14:58
I mean, I think we've all been that like I would 100%, hey, I've got a problem. Let me ask you my question. And then by the end of the question, like, it doesn't matter. I've solved it. It's fine.
Emma 15:07
Yeah.
Ben 15:08
right. It's 100%. And I have a number of Kraken and Octopus energy plushies on my desk at the moment for rubber ducking. But yeah, it's an excellent point that shaping your PR well and kind of thinking it through helps to step by step, figure out the underlying structure and the logic, and it helps just clarify things in certainly in my brain as I'm doing it all kind of writing a question up in slow now it's more likely I'm writing question up in ChatGPT or in Gemini, or in whatever kind of AI question space you use, the act of kind of thinking through and sounding out your question will help to answer it. I love that has an extra benefits. I'm really trying to find a way to sneak that into this presentation, if I get another chance somewhere.
Emma 16:02
So can I ask actually, the seen, as you mentioned, you know, as ChatGPT enters the chat or Copilot or whatever the case may be, how do we feel about pull requests and code reviews in the age of AI? I mean, on GitHub. I'm seeing a feature now on my PR that I can get Copilot to do an initial little, little review for me. What are our thoughts on that?
Ben 16:27
The talk that I wrote, I kind of write that before AI tooling really kind of took off in a big way. So a lot of this talk didn't have AI in mind when I wrote it. I've kind of looked at it again since then, and I think parts of it still apply, but I suspect part of it have changed. So back to your question. I think AI has some real benefits to offer. It's very similar. So some of the kind of high-level benefits, the low hanging fruits, very similar to, for example, using a linter in your code.
Ben 16:58
Sorry. Linter is something that will run checks to make sure that your code is written in a certain way. Right. So for example, it will only allow lines of certain links and then it will automatically kind of drop them out onto low lines and split them up into little lines. I think AI tooling can help to do something similar,
Ben 17:19
if you have written coding conventions, and this is the thing that we're kind of already looking into with Kraken’s code base. And because we do have some written code conventions, and so having an AI be able to look at those and apply those to your code, or at least offer suggestions to you based on your coding conventions, I think it'd be a nice, easy win that isn't too controversial.
Emma 17:45
Yeah.
Ben 17:46
Possibly more controversially, you've got this in two ways, right? The thing that you mentioned is, AI as a reviewer, and I think that's probably the less controversial of the two, but it will likely make suggestions for changes which you then, as a human, have the choice to implement or not, and is hopefully spending the time to kind of think about it and think things through and whether that's the right thing to do or not.
Ben 18:09
I think where we're going to start to see things become a little bit more tricky, more controversial, potentially more damaging is people using AI to either heavily or entirely create PRs. And I think at that point things become harder because ideally, and I think this is something that I've seen kind of come up in discussions and in various places. Whoever submits the code is still responsible as a human for what AI purposes?
Emma 18:38
Yeah.
Ben 18:38
At that point I would argue your reviewing skills become extremely important in terms of reviewing the PR that has been put together, by an AI.
Emma 18:49
Yeah. Do you have any thoughts on the topic Brandon? How do you feel about the inclusion of an AI in code reviews?
Brandon 18:55
Yeah, I think it is potential to be useful. And I think the couple ways it seems like useful is sort of doing quick smell testing. So when you're when you're looking at something, especially in a team like ours where we're working on some fairly diverse projects, there's a whole lot of things you have to remember to check for and is can kind of smell test to say, oh, need to double check that you're sanitizing inputs here, or you need to check such and such, or this is looks like it might be an anti-pattern.
Brandon 19:27
It's not going to review it, but it's going to help lead you to stuff that you don't have expertise. I think you should be an enhancer in being able to give you, as a reviewer, some quick knowledge. So somebody throws some, some rust at me as part of a PR, you know, I don't know rust very well, but I can get a very quick, you know, lesson, you know, in what should I be looking for?
Brandon 19:57
What are sort of idioms or what are anti-patterns in, in this language so that I can do a little more review beyond saying, oh, it compiles and the variable names are consistent. So I guess it's okay. I think as a, as sort of an enhancement to like that it may be maybe useful.
Emma 20:19
Yeah. More and more it seems like it has a place, but we're not getting rid of the humans from these things any time soon.
Emma 20:27
And I think, you know, if I throw it back to your talk again, Ben. Like with the underlying idea being that you want to optimize your pull requests for the reviewer. Brandon, you've also mentioned the articles that Michael Lynch has done. My personal favorite of like, How to Make Your Code reviewers fall in love with you. Like, we're talking about people here and we're not we're not losing the human element from these things anytime soon. For sure. And are there any other key takeaways from the talk that you would like to touch on?
Ben 21:02
Yeah. So probably the main other concept in the talk that was kind of bringing up and chatting about now is the idea of keeping your commits atomic. So what do I mean by that? In a PR you have the ability to stack a number of commits together.
Ben 21:24
So you do you make one change in a commits and then you create a second commit. There's a second change and a PR is just, a whole series of those put together. Keeping a PR atomic, roughly speaking, means only doing one thing per commit. So as an example. So if I have some function and I want to both rename that function and also change what it returns, those are two things.
Ben 21:58
And so you should be doing each of those things in a separate commits. Commit one. Rename that function everywhere. Commit two. Change the return from the newly renamed function. The impact that can have is it keeps the mental load much, much lower for reviewers, if I'm reviewing that. But the first thing that I see is hey, function, do a thing has been renamed to function update variable X, and I can see that name change very simply everywhere.
Ben 22:33
Step two is the functional change of returning a different value. And I can see that without having to fight through the name change at the same time, because those two things can be done independently. And so again, there's probably too much content here to kind of go into it in 30-seconds. I recommend to go and view the, the, talk which goes into it in a whole bunch more detail. But yeah, the idea of splitting up your work into discrete steps and allowing your reviewer to review those one-step at a time is incredibly powerful.
Brandon 23:13
I think one thing that would help is if people it's really worth your time to learn how to use some of these Git tools. And I mean, a lot of people sort of use Git as a filing cabinet to throw their changes in however they may come.
Brandon 23:25
And if you learn to do things like learn how to do partial staging, learn how to do things like squash commits, amend your commits to interactive rebase and you can, you know, turn your messy history into the history that you wish you had written, and one that's a lot more clear. And you, and you may not have made atomic commits when you were trying things out and figuring out how you wanted to make your changes.
Brandon 23:53
But it's actually very easy to go back and make those atomic commits. If you learn a few of these Git commands and really take the time to get to know it, it's it's time well spent, I think.
Emma 24:06
Yeah, definitely to things that go hand in hand there. Learn your version control keep your commits atomic. And as Ben said like if you want to dive into that in more detail. His talks a great jumping off point and also has some examples and some more info. So definitely check that out.
Emma 24:36
I want to ask you both a question about code reviews, actually. I'm thinking about the pros and cons and some of the things that we have touched on so far. I'd like you both to tell me one thing you wish people would do more of in their code reviews, and one thing you wish they would do less of. Ben, do you have an answer for me?
Ben 24:58
So one thing that I think I wish people would do more of, is reviewing their own PRs I think this is a thing that is, one will make PRs much nicer to review from somebody else, because a lot of the easy mistakes are already been spotted. And it also it's really good practice for people to, you know, review, PRs, and to kind of understand, you know, if you review your own PR, you're like, man, this commit really suck to review.
Ben 25:26
This was difficult for me. That's going to be twice as bad for somebody else. But also that's really good kind of training because you put that together in the first place. You then see that it's difficult to review, and you get a chance to make it easier to review in the future by working and making it nicer. And that's a really good thing to learn and practice. So reviewing your PRs, it will also save you like a round trip of, hey, this thing has a spelling mistake in it
Emma 25:57
Yeah.
Ben 25:58
Things I wish people would do less of pitching reviews at a level which isn't actually helpful. So for example, if I'm trying to put in, you know, more architectural change, nitpicking on some of the names may not be helpful, if what I'm really hoping for is for somebody to critique the architectural decisions or the database models or whatever it is.
Ben 26:22
And I think that's a little bit on the reviewer. Sorry, on the author of the PR as well, to make that clear upfront. Right. If I'm putting together a PR that does the thing and I'm wanting reviews in a specific way, or if this is, especially for very early drafts or for prototypes, I don't care if something is named slightly wrong. It's a prototype. I'm putting everything out once I'm done anyway. Please review for these things.
Emma 26.46
Yeah, that makes a lot of sense. Brandon, have you anything? One thing people should do more of and one to the left of.
Brandon 26:53
Yeah. I think one thing I would like to see more of. Still more context, but I when I'm reviewing something, I want to be able to play with it. And one thing specifically is maybe even have some sample data so that you can say, you know, they'll say, oh, this file was breaking when we tried to run it. Or, you know, here's an example of what's broken. Here's an example of what's fixed. And a lot of times I find myself having to go through three layers of tickets and this ticket and eventually talk to somebody and say, can you show me how this is broken or how to run this and make that easy for me?
Brandon 27:32
Because the only way I'm going to really feel satisfied myself is if I can play with your changes, and I can figure out how to make your changes, or figure out how things got fixed. So yeah, even however much context you're adding, still not enough. But, things I wish people do less of. There's a, I think, just a little bit of carelessness again, in what gets put into a PR, I still see, you know, sometimes people will do some weird things with their, their merges and, and stuff and you'll get a PR which is there changes and it's bringing along a lot of other changes.
Brandon 28:14
Don't quite have to be there sometimes. Just be careful about again, making sure that we're reviewing what we want to review and that, even though it's might be harmless. Just don't make me guess. When I look at this, this is exactly what you want to do. No more, no less. So that I'm not. You know, I don't feel comfortable in saying this. Let's do it or not.
Emma 28:43
Yeah, there are some great takeaways. Thank you both. I'm thinking, I like your, idea, Brandon, of, like, give me a little bit of sample data or something, because we write a lot of, you know, we write a lot of scripts or, helper tools and stuff like that, and something that you can try it out with instead of having to cobble together something yourself.
Emma 29:02
So note to self for me, the next time that I would like Brandon to review something, I think that's, there are some great advice, but I actually want to move specifically to advice for junior for developers. Now, I know we've mentioned bits and pieces that would be useful. I think pretty much everything we've discussed so far would be useful.
Emma 29:27
Would also be useful at any stage of your career. But one thing that I think about when I reflect on using pull requests and code reviews is teaching tools, and how they've helped me, like at the start of my career, get like first job out of out of college, or when I joined new teams and, and learning from doing the reviews I'm also faced with.
Emma 29:54
But do I know enough about this to be able to comment? Is what I have to say even useful here? And I wonder, do you have any sort, any sort of thoughts about that? Or are you familiar with that feeling? Ben is kindly nodding along.
Ben 30:16
Yes, very much so. Both for myself and for like a myriad of junior developers that I've talked to over the years. I do have a few thoughts on this. And again, this is the things. These are the things that I have told people and will keep telling people who are asking you, bring this up. The main thing that I suggest for people, if you are looking at a PR as somebody who is either more junior than who has ever written, it's sometimes like much more junior or much less experienced with the code or with a language or whatever it is.
Ben 30:50
PRs don't just have to be you marking somebody else's work as good or bad. They can also be a great place for you to ask questions about why they've done those things right. If a senior in your team has written a PR, go and practice reading it and don't understand why they did something, ask like it's right there and all of the things that I mentioned before.
Ben 31:17
So apply that the problems are real and complex and nuanced, which means that they are phenomenal places to ask questions, say, hey, this thing, why did you do this thing? Hopefully the answer given by the senior developer is clear and easy to understand because they understand it's. But also it gives you that real world experience of the answers, because sometimes it's a very textbook answer.
Ben 31:45
You know, we want to keep this code modular because it will be more extensible in the future, blah, blah, blah. Go. And go read this Wikipedia article on modularity or whatever it is. Sometimes the answer will be this is not a good way of doing this, but I have to get something out today. And so this is the shortcut that I'm choosing to make for these reasons.
Ben 32:07
And so in that way, I think PRs are incredibly valuable learning opportunities for junior developers. You know, anybody who's not already very familiar with that code, that language. So that's one aspect, even if you don't think that you are likely to actively be helping, go in and ask those questions for yourself. You will get lots of learning from it.
Ben 32:28
Also, sometimes you, as a fresh pair of eyes, looking at a thing and asking the basic questions can help to point something out that whoever's been working on this for a day or a week or two weeks, they are now in way too deep and they've lost sight of some of the obvious stuff. And so sometimes a very simple question can force somebody to take a few steps back and go, oh, wait, that's a good point. That was an assumption that I made three days ago, and I'm just not reevaluated that at any point. But actually, maybe I don't have to do all of this, maybe this other, you know, and so I think
Emma 33:08
That's 100% true.
Ben 33:09
Yeah. And that's one of the ones that I felt for myself in, as a junior developer, one of my first jobs was being in a room looking through, you know, the next sprints worth of material. And occasionally I would ask a question that I thought was just me asking so that I could understand better, and there would just be this kind of silence in the room as people like, actually, I don't know the answer to this either. Why are we doing it this way? Why are we doing this other thing? Yeah. So I think it really helps was that you seen that process happen a few times and you can see you're more confident. But yeah, make sure that you it's important for you to understand it for yourself. And you may just help nudge somebody else reevaluate one of their assumptions.
Brandon 33:53
Yeah, I think there's even a bit of usefulness if you're if you're a junior or maybe it's something new to you and you don't quite you don't find any problems. You know, you go into review and you think, oh, I should be looking for problems. I should be looking to catch stuff. Maybe it looks fine. Just reviewing it with the summary can be useful. And you say this, these changes do this and this. We're now using such and such library. And because of that, we have to change the way we handle this data. And that does two things. I mean, A, it's useful for you just to summarize it, and B, there's a chance that when somebody reads that review, they may think, oh, that's not quite what we meant to do, but that's what we did.
Brandon 34:41
And so even just writing a review that's a summary of your understanding can be really useful for everyone. And that's more than enough.
Emma 34:55
I think those takeaways are a really nice way for us to wrap up today's conversation. And let everyone digest all the great advice and thoughts that you guys have shared with us today. Ben, before I let you go as the guest in today's podcast episode, I'd like to ask you our quickfire questions.
Ben 35:14
Amazing, go for it.
Emma 35:16
First thing that comes to mind, dark mode or light mode?
Ben 35:19
Dark mode.
Emma 35:20
Can you tell me an app or gadget that you cannot live without?
Ben 35:26
Err, not off the top of my head.
Emma 35:29
That's fair. Too many to choose from.
Ben 35:32
As in work-related or life-related?
Emma 35:34
Life or work or anything.
Ben 35:38
All right. Curveball. When I go travel HappyCow. Great way of finding, veggie and vegan places anywhere in the world. Highly recommend it.
Emma 35:51
Yeah. Great shout. I love HappyCow. Can you tell me a scientist or tech innovator that you admire?
Ben 35:58
I'm going to cheat on this one. I don't have any go to, like, famous versions of those things. The people that I've worked with and the people I see at conferences. But really the people that I've worked with, those for me. Yeah, particularly the ones who've mentored me along the way.
Emma 36:17
Perfect, I love that. Thank you so much Ben for joining us today. It's been lovely to chat to you.
Ben 36:21
Thank you very much.
Emma 36:58
And that is a wrap for today's episode. I would like to extend a huge thank you to Ben and Brandon for joining me today. If you'd like to check out Ben's talk, then please follow the link in the show notes, which I highly recommend that you do. Thank you all for listening and join us next time on Ctrl Alt Tech.
