Effective Code Reviews

00:00 How do you build reliable software with fewer bugs? Yes, unit testing is part of that.

00:04 But did you know that code reviews often play a key role in this process

00:09 and come with many more benefits on top of just bug detection?

00:12 This week, you'll meet Dougal Matthews. It's Talk Python to Me, episode 102, recorded February 28, 2017.

00:20 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.

00:51 This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy.

00:55 Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via at Talk Python.

01:01 This episode is brought to you by Rollbar and Hired.

01:06 Thank them both for supporting the show.

01:08 Check them out at rollbar and at hired underscore HQ on Twitter and tell them thank you.

01:15 Dougal, welcome to Talk Python.

01:17 Hi, thanks. It's an honor to be here.

01:19 Yeah, it's great to have you here.

01:21 I'm really excited to bring a slightly different view of technology here.

01:25 Often we talk about, you know, how do you execute this code?

01:28 What's the API you call?

01:29 But let's take a step a little bit back from just writing code and talk about how we work as a team,

01:34 how we contribute to open source, contribute to our company's code, and things like that through this code review

01:41 whole conversation that you have here.

01:43 Yeah, I mean, I spend so much time doing code review just as part of my daily job.

01:47 It just seems like such an important thing to actually talk about and see how we can improve.

01:50 Yeah, and I feel like people don't talk about it very much.

01:53 That's why I was drawn to a talk that you gave at EuroPython that we're going to talk about is,

01:58 you know, it's great that you're talking about this here because it can actually be either very beneficial

02:04 to bring in people, kind of to level them up as developers, or it can be confrontational and actually upsetting, right?

02:10 So I think having this as a thing you study and a thing that you do meaningfully,

02:15 not just, hey, I have to review your code, somebody said so.

02:18 Seems like a good idea.

02:19 Absolutely.

02:20 At the EuroPython talk, I actually, I'd done a quick sort of raise of hands

02:24 to see what people thought about code review.

02:26 And I think it was only around 20% of the room said they looked forward to or enjoyed the code review process.

02:32 And given how long, how much time people spend doing code review, which was several hours a day, if not more in some cases,

02:38 then that's just something we need to do better at.

02:41 Yeah, we definitely do.

02:42 Before we get to that, though, let's start with your story.

02:45 How did you get into programming?

02:45 Yeah, I've got a fairly common story.

02:47 I think I started messing around with computers when I was young.

02:50 The first thing I'd done really was learning sort of HTML and I guess CSS a bit later on,

02:55 just because I first encountered it in some websites and I looked at the view source.

03:00 And just with that, it kind of led me down this rabbit hole.

03:03 My dad had actually done something really great when I was a teenager.

03:06 He embraced it.

03:07 He was running his own company at the time.

03:09 And not many people actually had websites for their small businesses.

03:13 What year was this? Do you remember?

03:15 It must have been around 2000.

03:18 Okay, yeah.

03:19 Maybe a couple of years before.

03:20 Yeah, I mean, the web was certainly well established.

03:23 Like the whole dot-com boom was going crazy around that time.

03:26 It was still not a thing that if you had a business, you had a website, right?

03:31 Like that was not a one-to-one mapping.

03:33 It was if you're doing internet stuff or you're a big company like Coke or Chevrolet or something,

03:39 you would of course have one, right?

03:40 Yeah, absolutely.

03:41 I think at that point, it was really out of reach from your regular small companies.

03:45 So yeah, my dad just basically got me to put together a simple website for him.

03:50 And honestly, it was fairly terrible, but it was my first kind of step into that world

03:54 and that direction.

03:55 And I just, I love the idea of web development since.

03:57 Yeah, I think it's interesting that the whole view source thing brought so many people into programming, right?

04:04 It used to be we would go to a store, we'd buy a box, it would have compiled machine instructions on a disk.

04:11 We'd put those on our computers and run them.

04:13 And then the web came along and if it did something interesting, you could pretty much just look and study it, right?

04:19 Yeah.

04:19 And that actually reminds me of one time, I was just starting and I was trying to figure out

04:24 why something wasn't working.

04:25 And actually, I didn't have access to the computer all the time.

04:27 So what I'd done is I printed about 20 pages of HTML and just sat down and studied it.

04:32 It wasn't a very good approach, but...

04:35 I've tried that as well.

04:36 It's extremely hard to get anything out of it.

04:39 I did it with C++.

04:40 Awesome.

04:41 Okay, so you created the site.

04:42 What language was that in?

04:43 It was purely static.

04:44 So it was just HTML.

04:45 I'm not even sure if I was using CSS at the time.

04:48 It might have been a bit early in my learning at that point.

04:52 But fairly quickly, I moved on to doing PHP.

04:55 I think it was just because you've seen it everywhere.

04:57 All the websites ending with .php, like on, I guess, Facebook later on.

05:02 But they were everywhere at the time.

05:04 I never really felt quite at home with PHP.

05:06 It wasn't really the language for me.

05:08 I'm not really quite sure what it was.

05:10 I mean, it was just a large number of things.

05:12 I guess it always felt a bit strange.

05:13 And I was trying to do more.

05:14 Like, I was trying to do more object-oriented and think about my code more from an engineering point of view.

05:19 And eventually, I stumbled on a video by Jacob Cavill Moss when he was introducing Django.

05:25 It was very early on.

05:26 It was before Django at one point.

05:27 And I just picked it up and tried it out.

05:29 I just loved it.

05:30 It was great.

05:31 And that just kind of led me down that path to learning Python.

05:35 I remember writing a blog post years ago that Django, it's just Python because it was Python that I really liked.

05:42 I mean, I do enjoy Django, but it was Python and the full ecosystem and everything beyond that.

05:46 And it just kept on going.

05:48 Yeah, I hear that's a story sort of like that over and over in that the guys around Django were very just enthusiastic, right?

05:57 And their enthusiasm wore off on anybody who came in touch with them.

06:01 And Django just really grew, partly because it's really great, partly because it's Python,

06:05 but partly just the enthusiasm of getting started with this new world, right?

06:09 Yeah, absolutely.

06:09 And I'd gone from sort of hacking on WordPress sites and various PHP frameworks to then suddenly the elegance of Django

06:16 and Python just defining models and having the admin and all that just there was just amazing, mind-blowing, really.

06:23 You mean there's objects in architecture and factoring?

06:26 Oh, my goodness.

06:27 Yeah, yeah, very cool.

06:29 So you said you have some strong ties to Europython.

06:32 What's the story there?

06:33 Are you working with the conference somehow?

06:34 The reason I wanted to mention Europython, I mean, there's actually several reasons.

06:40 But when I started with Django, I just thought I need to get involved with this.

06:42 But there's nobody local that I know.

06:44 I can't find anyone that's doing anything with Python or Django.

06:47 So as a poor student at the time, I found all the money I had and got myself to Europython in 2009.

06:55 And that's the first Europython I went to, and I've been every year since.

06:58 And I also went to the first and actually the only Euro DjangoCon because after that I got changed to DjangoCon EU.

07:04 Yeah, and it's just I've met so many people there and I slowly have started to do some small things to help out with Europython.

07:11 So I'm on the program committee this year.

07:12 And I'll actually take the moment to point out that the Europython dates for this year

07:17 are the 9th to the 16th of July.

07:19 These are tentative, but I expect they'll be finalized by the time this is released.

07:23 Oh, yeah, that's really great.

07:25 Thanks.

07:25 So if you're anywhere near Europe or you want to go to Europe, right?

07:28 Check it out, right?

07:29 What's the URL?

07:31 I think it's just...

07:32 It's like Europython.

07:35 Europython.eu is the website.

07:37 Yeah, that.eu.

07:37 And this year it's going to be in Rumini in Italy.

07:39 Oh, that sounds awesome.

07:40 Okay, excellent.

07:42 Well, there's a possibility I'll make it there, but it's very far away from it.

07:46 So we'll see.

07:47 But that's awesome.

07:48 If people can make it, they should go.

07:49 I think the Python conferences are something really, really special.

07:53 There is a different way that people interact with each other there than a lot of typical

07:59 tech conferences.

08:00 So yeah, if you can get there, check it out.

08:02 Yeah, I agree.

08:02 There's a long-running phrase of come for the language and then stay for the community.

08:06 And I think that really resonates with me.

08:08 Yeah, absolutely.

08:09 So you're doing a lot with Europython, a lot with Django.

08:13 What do you do for your job today?

08:15 So I'm currently working on OpenStack.

08:18 I'm employed by Red Hat and I work on the OpenStack project full-time.

08:22 So I'm focusing primarily on making OpenStack easier to use and install.

08:27 And I'm also working on a workflow service within OpenStack, which is quite an interesting project.

08:32 I think that's really good.

08:33 OpenStack is really a great example of Python doing major stuff.

08:39 And it's a great contribution, but it is a little bit hard to install, especially if I just want to run it natively on my Mac or something.

08:45 It's challenging, right?

08:46 Oh, absolutely.

08:47 I mean, I think the problem with OpenStack or one of the problems with OpenStack is

08:51 it's such a wide range of different projects.

08:53 There's no two OpenStack installations that are actually the same.

08:57 Some people care about containers or some people can care about VMs.

09:00 Other people can care about storage, distributed storage, that kind of thing.

09:04 They're all very different.

09:06 Yeah.

09:06 I mean, you're basically installing AWS in a sense, right?

09:09 Yeah, exactly.

09:10 Which is quite the thing.

09:12 And by the way, just S3 is entirely down and the internet is, is in chaos today.

09:15 So that's quite something.

09:17 I'm really glad our recording is working.

09:19 That's great.

09:20 All right.

09:21 So let's talk about code reviews.

09:23 So first of all, let's start with who should be doing code reviews.

09:29 Like, are these big enterprises?

09:31 Is this open source?

09:33 Like, who should care about this?

09:35 I think everyone should be doing code review.

09:37 Really, the only reason I can think of to not do code review it, and that would be that you

09:41 are the sole developer on the project.

09:43 And obviously, then it's kind of tricky to have a peer review.

09:47 Most of the time, I'm involved in open source projects and that kind of environment.

09:52 But I think code review is something that should be in the enterprise and all companies as well.

09:57 And I think, actually, it's probably more common in open source just because of the nature of how people communicate and collaborate.

10:02 Yeah, okay.

10:03 So I tend to agree with you.

10:05 I mean, I guess if you're on a small team, you work at like a small company, and you have one project, maybe there's some other developers, but they have their other project, and you don't really cross over.

10:15 It might be a little bit tough to do code reviews, especially if one guy is a C++ person and another person is a Python person or something where they don't know deeply what they're looking at.

10:24 That's a fair comment.

10:25 But you're missing out on an opportunity when you're looking at situations like that.

10:29 Perhaps the Python person becomes ill or leaves the company if nobody else knows what they've been doing, then you're in trouble.

10:35 At least if they've had a light code review process, they might not need to be as in-depth as in some other situations.

10:41 They will have some idea of what's going on.

10:43 Yeah, I think that's a really good point.

10:44 You also actually pointed out some scenarios where it might make sense, even as a solo developer, to do your own code reviews.

10:52 Yeah, so this is kind of an interesting thing, which I just stumbled on by mistake.

10:57 I do some work on one of the documentation projects used in Python.

11:00 It's called mkdocs.

11:02 And it's a fairly popular project on GitHub.

11:05 There's quite a lot of people watching the repo.

11:06 And I was just hacking away on it.

11:08 And I opened a pull request onto the project just because I wanted to trigger the Travis build and make sure things passed and were working before I merged it, just to avoid myself making any errors.

11:18 But in the process of doing that, I left the pull request open for maybe six hours or half a day.

11:24 And somebody came along and actually made a comment on it and made a suggestion.

11:27 So it's just by including that process in something that I'm working on, even if I'm planning to just merge it myself anyway, it gives other people an opportunity to get involved.

11:37 And it actually helped me find new contributors as well.

11:40 Oh, yeah, that's really cool.

11:40 So especially if you have open source.

11:42 But really, if you have a repo that other people are watching, going through the whole workflow, even if it's just a cursory sort of review, lets them know there's like this milestone, like a feature is fixed.

11:54 And here's the code that fixes that feature, right?

11:56 Yeah.

11:57 And also, if you have your CI integrated in that, it will avoid you making any sort of silly mistakes where you've accidentally missed a file or added a file because your test will run against that pull request as well.

12:10 Yeah, yeah, absolutely.

12:11 So do you follow or subscribe to the GitFlow style with feature branches and stuff and PRs?

12:18 How do you guys work together at OpenStack?

12:22 We basically do master development.

12:24 Every patch goes into master and then we've got stable branches for releases that are still receiving updates.

12:30 It's a much lighter workflow than something like GitFlow.

12:34 I find that GitFlow might work well in a company where you can force everyone to follow the same conventions easily.

12:40 But in an open source project, I don't think long lasting branches tend to work very well because they just get out of sync and there's different problems going on or they get forgotten about.

12:50 So I prefer everything just to go into master as soon as possible, but keeping master as stable as possible as well.

12:57 Yeah, I think that's a really interesting point.

12:58 And I've worked both ways.

12:59 I've worked in a company where we basically agreed to do the GitFlow stuff.

13:04 So every change has its own branch, like a feature branch or a bug fix branch, and then you do a pull request back to the dev or main or whatever to have someone else review it on the way back in.

13:16 But I've also worked in the – basically, we've got a dev branch and a releases branch.

13:20 And we just push, you know, merge over to the releases every now and then.

13:24 I don't know.

13:25 I've torn.

13:26 Like they're both – they both have their advantages.

13:28 One of the things I see about the second one, the latter one, like what you described you're doing is the closer you are to dev on your branch or what you're doing, the less merge pain you're going to have.

13:39 Like a friend of mine describes sort of being branched as credit card debt.

13:45 A little bit of credit card debt is fine.

13:46 If you let it build up for six months, there's going to be a reckoning when you try to fix it, right?

13:51 Yeah, absolutely.

13:52 And I think if people are using longer-running branches, then as long as you're rebasing, then you're maybe avoiding most of the problems.

13:58 That's right.

13:58 So if you take the dev branch and you merge it into your feature branch every now and then to like keep – basically to keep that time, the work that's been done from the time that you're working on your code to what you're going to check in minimum, that's great.

14:12 Okay, so in my mind, I guess code reviews are obviously about finding bugs or making sure that you follow certain procedures for, say, security reasons.

14:23 But you actually said there's a lot to do with like code quality and mentoring and a lot of things.

14:31 So like what are some of the benefits?

14:32 Yeah, so this is actually quite an interesting point.

14:34 There's a paper which is called Expectations, Outcomes, and Challenges of Modern Code Review.

14:40 This is one of the first academic papers I read about code review, and it's kind of what led me down this rabbit hole.

14:45 At least I hope I'm remembering the right paper.

14:48 This data might be from another one.

14:50 We'll put all the papers, the links to the papers, and people can find the references.

14:54 Somebody had done some research with Microsoft, and what they'd done is they'd done a questionnaire for the developers before and after the code review process.

15:02 And they were just finding out why they were doing code review, what they were expecting to get out of code review, and the motivations.

15:09 And while most of the developers actually stated their primary motivation was to find bugs and find problems, when they took the outcomes of code review, so they looked at the comments and all the different feedback that was in a code review, then they manually classified it based on all the different things that were coming out of it.

15:25 They actually found out that bug finding was much smaller.

15:29 While bug finding was still important, it was a much smaller piece of the overall code review process, and there were a lot of other benefits that you'd get out of it as well.

15:38 I see.

15:39 Yeah, they probably started out the same sort of mental model, like, okay, how well did we do finding bugs?

15:43 And like, oh, wait, all these other good things came out of it.

15:45 Wow.

15:45 Yeah.

15:46 Yeah, and I think this is part of why a lot of people don't enjoy code review is because if you're going in just to find bugs, you're kind of going in with a negative stance.

15:55 You're thinking, what can I find that's wrong with this?

15:57 What can I find that's broken?

15:58 It's not.

15:59 It's a slightly different process.

16:01 But what they actually found was the biggest outcome was a code improvement.

16:05 So this is kind of subtle to a bug because the code that was up for review was valid, and it worked.

16:10 But actually, based on the feedback and the iteration that went on in the code review, they ended up with a better solution in the end.

16:16 And then there's understanding and shared knowledge between the teams.

16:19 So it's about having awareness of what other people are doing on different projects or different areas of the code base.

16:25 Okay.

16:26 Interesting.

16:26 Yeah.

16:27 So you had some interesting quotes, like one from Jeff Atwood, the creator of Stack Overflow, about the value.

16:34 And it's also one from Steve McDonnell, right?

16:36 So yeah, Jeff Atwood, who a lot of people will know, he wrote a blog about code review a while ago.

16:41 And he basically said that the hardest thing about doing code review is finding somebody that you trust enough to do the code review with.

16:47 But once you actually get into the process, you'll find that every minute you spend in code review is paid back tenfold, which is a really huge sort of payback for your time investment.

16:57 Yeah, that sounds like a good investment.

16:58 And then the one from Steve McDonnell.

17:00 So he was basically, in his book, Code Complete, he compared the detection rate.

17:06 So how often you're finding bugs in your reviews.

17:09 And in their study, they found out that unit tests had a 25% chance of catching bugs.

17:15 Function tests had a 35% chance.

17:17 Integration tests, 45% chance.

17:20 But then code reviews were actually between 55% and 60%.

17:23 So I'm not sure I completely buy those numbers.

17:26 But I mean, just even think that code review is just as valuable as your unit tests is quite something.

17:30 I mean, I couldn't live without my unit tests.

17:33 Yeah, it certainly is interesting.

17:34 And that book, Code Complete by Steve McDonnell, it's really, it's quite a book.

17:38 It really has a lot of wisdom, a lot of things like backed up by studies and numbers.

17:43 And so if you haven't seen that book and you're kind of into this process stuff a little bit, definitely check it out.

17:50 So the fact that you get better bug coverage than unit testing, that's pretty interesting.

17:56 Also, how do you feel like unit testing contributes to mentoring and better understanding and sort of team understanding versus, say, like code review?

18:06 I feel like you would get more of that out of a code review, right?

18:09 Because you're actually talking, not just writing tests.

18:11 Yeah, absolutely.

18:12 So one of the things I covered in my talk was the issues with the sort of the quotes that I gave is they are very focused on bug detection and defection rate.

18:21 And as you said, there's a lot more to code review, which I cover as well.

18:24 I think the reason that paper is covered in the bugs is bugs are sort of an absolute thing.

18:29 Something is a bug or it isn't.

18:30 So it's very easy to measure.

18:32 You can see how many bugs have been reported, whereas all of the other benefits, they tend to be a lot softer and a lot harder to actually get a tangible measurement of.

18:40 Yeah, like that example of what if the Python guy gets hit by a bus, right?

18:45 Your company is more anti-fragile if you do these types of things, right?

18:49 It can withstand these problems, whereas I guess it's obvious, like the user can't log in and you get a 500 error on the server.

18:56 Okay, well, that's a bug, obviously, right?

18:58 But you can say, well, we could have missed this with, we could have saved this with a test.

19:01 But also, like, our team works better together.

19:04 Our team has a better understanding of what each other is doing and the tradeoffs they're making and so on.

19:10 You can't really test for that.

19:11 No, not at all.

19:18 This portion of Talk Python To Me has been brought to you by Rollbar.

19:31 One of the frustrating things about being a developer is dealing with errors.

19:34 Ah, relying on users to report errors, digging through log files trying to debug issues, or a million alerts just flooding your inbox and ruining your day.

19:42 With Rollbar's full-time error monitoring, you'll get the context, insights, and control that you need to find and fix bugs faster.

19:49 It's easy to install.

19:51 You can start tracking production errors and deployments in eight minutes or even less.

19:55 Rollbar works with all the major languages and frameworks, including the Python ones, such as Django, Flask, Pyramid, as well as Ruby, JavaScript, Node, iOS, and Android.

20:05 You can integrate Rollbar into your existing workflow, send error alerts to Slack or HipChat, or even automatically create issues in Jira, Pivotal Tracker, and a whole bunch more.

20:14 Rollbar has put together a special offer for Talk Python To Me listeners.

20:17 Visit Rollbar.com slash Talk Python To Me, sign up, and get the bootstrap plan free for 90 days.

20:23 That's 300,000 errors tracked all for free.

20:26 But hey, just between you and me, I really hope you don't encounter that many errors.

20:30 Loved by developers at awesome companies like Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch, and more.

20:36 Give Rollbar a try today.

20:37 Go to Rollbar.com slash Talk Python To Me.

20:40 Yeah, so how do you feel like automation fits into this?

20:50 So like continuous integration and whatnot?

20:54 So I really strongly believe that you should automate as much as possible.

20:58 Anything that can be automated that isn't is essentially wasting your time.

21:02 And for most people, their time is the most precious thing.

21:06 So this means that you should be automating your linting.

21:09 So this is like your PEP 8 checking or your FLAC8.

21:12 Yeah, you had an interesting quote where you said something to the effect of this whole thing often gets set up as an adversarial sort of relationship.

21:20 Like, okay, these guys sit on the side of that table.

21:22 You sit here.

21:23 We're going to review and tell you what you did wrong and how you need to fix it.

21:28 And one of the things that code reviews are supposed to do is like say, well, you're not following this coding convention or you didn't do this thing.

21:37 You know, you didn't document this or name this correctly or whatever.

21:40 Right.

21:40 And if that comes from a human, it seems super nitpicky.

21:44 But if it comes from a machine, everybody is sort of subjected to the thing absolutely uniformly.

21:51 So you're like, oh, yeah, FLAC8 told me that should have an underscore and not camel case or whatever.

21:56 Right.

21:56 Yeah, absolutely.

21:57 The sort of the feedback from an automated machine.

22:00 So in terms of also including verifying the tests are running, it doesn't feel negative.

22:05 It doesn't feel like the code is judging you.

22:08 But sometimes if somebody comes along and reviews something that you've been spending a lot of time on that, but then they just point out different small little things that they think would be slightly nicer formatting, then that can be infuriating.

22:19 Yeah, I think it's infuriating, but it also can't be anyway.

22:22 But I think the other part that is there is if your job is to be the reviewer, you don't want to spend your time going, yeah, you named that wrong.

22:31 Yeah, that needs a comment.

22:32 Yeah, that needs a doc string.

22:34 Like that is not that is like a job that robots could do and robots should do.

22:39 Right.

22:39 You should say like, no, no, I think this algorithm is when we scale up, this is not going to scale or this is a stateful thing you're doing.

22:47 That means like we can't load balance it.

22:48 So we need to do that different.

22:49 Like that is the kind of thing people should be contributing to and not spending the energy on camel case, camel case, doc string.

22:55 Yeah.

22:55 Right.

22:56 Yeah.

22:56 So focusing your time on the design and the architecture and the actual solution to the problem is just so much more productive.

23:03 Yeah.

23:03 And so you said you were trying to rename this process to like something other than a review, right?

23:08 Yeah.

23:09 I have a bit of an issue with code review.

23:12 I think review is a slightly negative feeling about it.

23:15 If you think of something like a performance review at work, that's rarely a good thing.

23:19 And your manager says, okay, we need to have a performance review.

23:21 I much prefer to think that it's going to be a code collaboration or a code discussion.

23:27 It's something that you're working on with someone else.

23:30 And I think we should try and encompass that more.

23:31 I don't realistically think we'll ever change the name at this point, but that's how I perceive it in my head at least.

23:37 Yeah.

23:37 Yeah.

23:38 That's cool.

23:38 I think code collaboration.

23:39 To me, maybe code conversation, right?

23:42 Something like this, right?

23:43 Yeah.

23:43 That's awesome.

23:44 Yeah.

23:44 I mean, certainly in the open source space, I feel like these can almost be a conversation starter or an introduction to somebody maintaining an important project.

23:56 Like you can go look at some code, fork it, do some work, and then your pull request like starts the conversation.

24:02 Like here's how I think I can both contribute to your project and improve it.

24:06 And then, you know, you get to know that person a little bit, at least by going through and reviewing their code back and forth on, well, you didn't think about this in our project and you're going to have to account for it and so on.

24:17 Right?

24:17 Yeah.

24:18 And I think it's really important when you submit a change to a project that you state that you want to have feedback.

24:30 I just want you to merge this.

24:31 And I was like, well, you've only just opened this pull request.

24:33 We're only just starting to talk about it.

24:35 I've never seen this before.

24:36 So this is like the start of the conversation.

24:39 And I think both people need to go into it at that point.

24:42 Whereas sometimes somebody's maybe been working for a week on something and they feel like when they opened the pull request, they kind of feel like they've done.

24:49 They feel like they've finished.

24:50 But that's not the case.

24:52 Yeah.

24:52 No, it's the beginning, right?

24:53 The beginning of the conversation.

24:55 What would you recommend to have made that person's experience better?

24:59 Should they have opened an issue and said, I'm going to do a pull request.

25:02 Here are my intentions.

25:03 Here's the problem I've identified and what I think I'm going to do.

25:06 I'm sort of personally torn because on one hand, actions speak much louder than words.

25:12 Like here is the code that I have written that will fix this for you.

25:15 Puts you in a different place than somebody who opens an issue and sort of like almost complaining.

25:19 Right?

25:20 So they come with more credibility, but at the same time, they put a lot of energy into it.

25:24 And they may have gone in a path that was incongruent with what you're doing.

25:26 Right?

25:27 So what do you think?

25:27 Yeah.

25:28 So I think in this case, you just need to judge it yourself.

25:31 Really?

25:31 There isn't a standard answer.

25:32 Sometimes what you're working on is fair.

25:35 It seems fairly obvious.

25:36 So it's fairly small and contained.

25:37 And then you should just go ahead and do the pull request.

25:40 But if you feel like there's maybe more discussion, you're not sure about how it should work, then it's better to go towards an issue first.

25:46 I do think that sometimes it's actually easier to express what you want to do in code.

25:50 Like you're just messing around.

25:52 So I think it's also fine to just go straight to the pull request.

25:55 But you should just always have the expectation that this is a very first draft and it will change or it could change.

26:01 Yeah.

26:02 I think maybe think of it as like a draft of a paper sort of thing.

26:05 It's a pretty interesting way to think about code.

26:07 Right?

26:07 Okay.

26:10 So when you're authoring changes, don't start with a code.

26:13 Well, what should you start with?

26:14 You should either be starting.

26:16 Well, you can start with the code if you want to, but it's always good to start with a discussion first on an issue or sort of a bug report somewhere where you can actually flesh out what it's going to be.

26:25 But that isn't always needed if it's going to be a much smaller change in the end.

26:29 Yeah.

26:30 Also, you know, understanding the context of where that person's coming from, where the project is.

26:36 Right?

26:37 Like on one hand, you might, it would be very easy to look at one algorithm and go, this algorithm does everything in memory.

26:42 It loads it all up, all this data up at once.

26:44 And it's going to be super slow.

26:45 We can't do this.

26:46 Well, that's true if you have a billion records.

26:48 If you have 20, it's totally fine.

26:51 And the billion record solution would actually make it worse.

26:53 Right?

26:53 So understanding context, I think, is super important.

26:55 Yeah.

26:55 And when you actually provide a change, it's really useful to tell people both why you were doing something.

27:01 Sorry, what you were doing and why you were doing it.

27:03 I quite often see commit messages or pull requests that only really cover one of the two.

27:08 And I think you really need to understand both as a reviewer to really give a thorough review to that code.

27:14 Yeah, for sure.

27:14 I think, obviously, you have to keep that in mind no matter what.

27:17 But I feel like in open source, you don't necessarily know how people are using your code as opposed to, like, within your company, like, well, it's that website.

27:24 We know what we're doing.

27:26 We know what the traffic is.

27:27 We know how that's going to look.

27:28 Right?

27:28 So it seems almost more important in the open source, open space world rather than confined behind your company's wall.

27:36 Yeah, absolutely.

27:37 So say, for example, you need to add a new sort of method to a function for some reason.

27:42 If you just write in your pull request, added parameter A to this function, then that's not very useful.

27:48 You need to also explain why you're doing that.

27:50 What is the actual advantage to this as well?

27:52 Yeah, and how you're not going to break everybody's code by doing it.

27:54 Yeah.

27:54 Another interesting piece of research that you pulled out, something from Mozilla, was people actually find more issues and give better feedback on small changes, small PRs and so on, rather than large ones.

28:09 Even though the large one surely has more things to address.

28:11 This happens because reviewers are just overwhelmed by a big change.

28:15 And I actually seen someone tweet about this.

28:18 Basically, they decided that they should just submit bigger changes because people do less thorough reviews and they get their code in more easily.

28:25 Sneak it back.

28:26 Yeah, that's obviously not the idea here.

28:28 So if you can just keep your changes really sort of contained to one particular thing, one particular issue, and ideally touching less files within the project.

28:37 Although, obviously, sometimes you need to touch multiple files.

28:39 It just makes it easier for someone to review and get their mind around it and really understand what's going on.

28:45 And I think that's why the smaller changes then get a much more valuable review, whereas the bigger changes, they tend to nitpick at different things, but they've maybe not quite been able to wrap their head around everything that's going on in this review.

28:57 Yeah, so do you recommend sort of having one concept per check-in type of thing rather than, I did all my work for the day, so I'm done, so I checked it in.

29:06 But here's this little change I made, then I reformatted this thing, and then I addressed this performance thing over here rather than just all at one shot.

29:15 Would that get better feedback?

29:16 I'd definitely go for splitting that up into multiple reviews.

29:20 I actually find that you mentioned that you reformatted something in that example, and I actually think that can really make it harder to review something because the diff could be 10 times bigger just because they've also reformatted the code at the same time.

29:33 They do that as two individual changes, and you can actually see, okay, this is where they've actually made the functional change.

29:39 This one's just laid out.

29:41 Okay, they're both fine.

29:42 Something like this can depend a bit based on the tool that you're using.

29:45 So if you're using a GitHub pull request, if you just have two commits in your pull request, then that would be fairly easy to review in that case.

29:52 But something like Garrett, which only allows one package at a time, it's a bit tricky.

29:56 Yeah, sure.

29:56 What do you think, what contribution to this do you think GitHub has made?

30:00 How important is all of this sort of well-known, commonly used infrastructure that is kind of GitHub.com for code review, code collaboration?

30:10 Do you think the tools are adjacent?

30:12 I think they're reasonably good.

30:13 They've actually made some changes over the last, I can't remember when exactly, but I think over the last six months or so, they added a whole bunch of features.

30:20 And at least some of them appear to be inspired by Garrett and maybe other code review tools as well.

30:25 I think they're improving the process.

30:28 Originally, I think it was almost too simple.

30:31 But actually, for small projects, it seems to work quite well.

30:35 When you see larger projects on GitHub using pull requests as their primary code review, they tend to come up with a very complicated system on top of that with labels.

30:43 Or they maybe, I think Facebook has bots on all their different projects that are like progressing things on and sort of marking them as failed or not.

30:50 So yeah, I think they've done a great job in making code review accessible to everyone to at least a degree.

30:56 But yeah, I still think there's space for improvement there.

30:59 Yeah, it's interesting.

31:00 I mean, it's not necessarily true that the code that, you know, say you guys are using for OpenStack or Python is using for CPython is necessarily the best same set of tools for people with a thousand line project.

31:15 Right.

31:16 Like there's overhead in these bigger things that the smaller ones would actually suffer from it being there.

31:21 So it's always a tension, right?

31:23 Yeah, absolutely.

31:23 I mean, so we use Garrett for OpenStack and it's a Python open source project.

31:29 So that's quite nice.

31:30 In all honesty, it is very hard to use.

31:33 It's also extremely ugly and it takes a long time to just get used to using it.

31:37 But once you do get to that point, I find it really good.

31:40 Whereas GitHub, I feel like that's maybe the opposite.

31:44 Whereas it's really easy to use, but you start to hit up on the limitations of it fairly quickly.

31:49 Yeah, I think that's totally, totally correct.

31:52 So, I mean, even simple stuff as like nested issues or to-dos, right?

31:58 Like I'm not even sure if GitHub supports those, but it can be like, well, we want to do this thing, but there's actually five things we have to do to make that happen, right?

32:04 That could be important.

32:06 Okay.

32:06 Now, you talked about how if you're the reviewer, you shouldn't see this as like I'm assigning a grade or judging this person's code, but maybe think of it as like a shared responsibility with the author.

32:18 And you had a nice picture of like bunnies or guinea pigs or something.

32:21 Yeah, it was a guinea pigs.

32:24 I think I found that on Flickr.

32:25 Yeah.

32:26 I think it's really important when you're reviewing something that you take on ownership of that code as well.

32:31 Because effectively, I think the author of the code and the person that's approved and merged it are just as responsible for it ultimately.

32:38 This may not work in practice sometimes because people that submit the changes that get merged, they'll disappear on an open source project, for example.

32:45 You should really be trying to share that responsibility.

32:48 And I think this sort of highlights an issue that you would see with something like Git Blame because you would sometimes use Git Blame to look through the history of a project and see who has written what.

32:58 But that will only ever show you the author or sometimes the merger, depending on how you're doing things.

33:03 It won't show you everyone that's involved in the code review process as well.

33:07 And I think surfacing all these different people is useful.

33:10 As a side, I think Git Blame is a terrible name for the command in general.

33:14 But I think just having something which helps you find everyone that knows about this.

33:19 It's more about finding someone that has the knowledge here rather than finding someone to blame, in my opinion.

33:24 Yeah, I agree.

33:25 I certainly blame.

33:27 While sometimes it feels appropriate, you're like, all right, what is this?

33:31 Who wrote this?

33:32 It's not a real positive thing, right?

33:34 And you're right.

33:35 It only captures the final commit, which it could have actually just been the person who just reformatted it because there was a problem, right?

33:40 It doesn't even necessarily mean they created it.

33:43 Yeah, or moved the code around.

33:44 Yeah, yeah.

33:45 Something like that.

33:45 You also said that code contributions are like puppies.

33:49 Yeah, so the picture of the puppy is actually my dog when she was only a couple of months old.

33:54 But it's quite a nice quote.

33:57 I don't know where it came from, so I can't attribute it correctly.

34:00 But somebody said that code contributions are like puppies.

34:03 Everyone loves them.

34:04 But you need to look after them.

34:06 You've got to walk them.

34:07 You've got to feed them.

34:08 You've got to care for them.

34:09 And this is the same for any code contributions that you receive.

34:12 You need to make sure that they continue to work.

34:14 You need to make sure they're documented and so on until you can deprecate it.

34:18 And that often is quite hard to do in open source projects.

34:21 Absolutely.

34:22 Well, and I think the puppy analogy is nice.

34:24 Like everybody loves them and they're cool when they're nice and cute.

34:27 But, you know, when they're four years old and it's raining and you're busy, do you really want to walk them, right?

34:32 Or do you want to leave the party early because the dog needs to go out?

34:36 It's easy to say, well, I just want to change this behavior a little bit.

34:39 I just want to add this function.

34:40 I just want to like add an overload or a default parameter here and think how hard can that be?

34:47 It's like two lines of code.

34:49 I'll check it in.

34:49 Well, there's the documentation.

34:51 There's that video you recorded showing people how to use it that you have to re-record.

34:56 There's this thing you have to redeploy.

34:58 There's this, these, like they can, the smallest changes can expand in like large ways, right?

35:03 So under, like having somebody who knows that, like it's reviewing and going, you don't really fully appreciate the cascading changes that the small change is going to have, right?

35:11 Yeah.

35:11 And I think it's, it's something that open source maintainers in particular should feel like they can do, they can reject code more basically on this basis.

35:20 I think people quite often feel pressured to accept contributions.

35:23 Right.

35:24 I worked hard on it.

35:25 And so why don't you want to accept it?

35:27 It works.

35:27 It passes the test.

35:28 Yeah.

35:28 But then they then are responsible for looking after that code for forever.

35:34 Yeah, yeah.

35:35 This portion of Talk Python To Me is brought to you by Hired.

35:49 Hired is the platform for top Python developer jobs.

35:52 Create your profile and instantly get access to 3,500 companies who will work to compete with you.

35:57 Take it from one of Hired's users who recently got a job and said, I had my first offer on Thursday after going live on Monday and I ended up getting eight offers in total.

36:05 I've worked with recruiters in the past, but they've always been pretty hit and miss.

36:08 I tried LinkedIn, but I found Hired to be the best.

36:11 I really liked knowing the salary up front.

36:13 Privacy was also a huge seller for me.

36:16 Sounds awesome, doesn't it?

36:17 Well, wait until you hear about the sign-in bonus.

36:19 Everyone who accepts a job from Hired gets $1,000 sign-in bonus.

36:23 And as Talk Python listeners, it gets way sweeter.

36:26 Use the link Hired.com slash Talk Python To Me and Hired will double the signing bonus to $2,000.

36:31 Opportunity is knocking.

36:33 Visit Hired.com slash Talk Python To Me and answer the door.

36:36 You know, I had a recent experience with this.

36:45 I suggested some change to pyramid the web framework and they're like, great.

36:48 And if you're willing to be the maintainer of this part of that feature for two years,

36:52 then we're totally happy to accept that.

36:54 Is there a simpler way we can solve this problem?

36:56 Maybe.

36:56 So they subscribe to the puppy philosophy.

37:00 Yeah.

37:00 I mean, it's nice that they were willing to give you that opportunity because actually it's

37:04 quite hard to get to that point of trust with people sometimes because a lot of people might

37:09 promise to support something for two years, but then they'll just disappear shortly after.

37:14 That's right.

37:15 That's right.

37:16 The other thing that I thought was pretty insightful is you said that not just senior

37:21 devs should be reviewing code.

37:24 It shouldn't be a top down, like I'm above you.

37:26 And so I look down on your stuff and I tell you whether it can be approved, but also juniors

37:31 should do review, maybe even a seniors check-ins, right?

37:34 This is a mistake which I've seen in a couple of companies.

37:37 Not recently, actually.

37:38 So hopefully it's sort of a trend that's dying now.

37:41 I've seen cases where only the seniors were allowed to review the code and the juniors

37:45 would then sort of be subject to the review, but they would never get the chance to review

37:49 themselves.

37:50 There was actually a study which found that senior developers were actually doing slightly

37:54 better code reviews just because of their experience.

37:57 They also found that junior developers most quickly improved and most quickly became on par

38:03 with the other seniors by doing code reviews themselves.

38:07 I think that really highlights back to all the other benefits that come out of code review,

38:11 like with the shared knowledge and the shared understanding.

38:12 That's how the juniors become seniors.

38:14 Yeah, absolutely.

38:15 I totally think that's a great idea, a great point.

38:17 Sure, they'll find fewer bugs, potentially, because they don't really know as well to look

38:22 for them.

38:23 Maybe their suggestions will be pushed back upon.

38:26 Like, I suggest you rewrite this in a simple way.

38:28 Well, no, no, it won't scale and we have a million users, so on and so on.

38:31 But even just having that conversation, making them actively think about it and propose those

38:36 changes, whether or not they actually make it through, the value has already been gained

38:40 from that, right?

38:41 Yeah, absolutely.

38:42 Okay.

38:42 Very nice.

38:43 You also said having a review checklist might help.

38:46 It seems to me like that could depersonalize it a little bit.

38:49 Like, look, these are the things we're going to check for, so we're going down the list

38:52 and it's not me being a jerk to you.

38:54 This is a list.

38:55 Like, it applies to me too.

38:56 A code review checklist can be very beneficial because it gets everyone really on the same

38:59 page and everyone's kind of reviewing to the same standard and the same expectations.

39:04 The one thing you need to be careful with is that you don't include anything that could

39:07 be automated because there's temptation.

39:08 It's easier to write something on a sort of a review policy than it is to automate it.

39:13 So you just need to make sure that that doesn't happen.

39:15 But otherwise, I think it's a really good idea for projects to explicitly sort of state what

39:20 they're expecting.

39:21 And this can be useful both for the reviewers and also somebody that is submitting something

39:25 for review because they know what they are working towards.

39:27 Yeah, that's cool.

39:29 Certainly, it seems like you could just build the checklist and go, okay, what of this can

39:32 we automate?

39:32 And we're not going to use this checklist until we've gotten everything that can be automated

39:37 automated.

39:37 Yeah, that's actually a good idea.

39:38 So that'd be a really nice way to build up your priorities.

39:41 Yeah, for sure.

39:41 Like automated linting and things like that.

39:44 We already talked about the bots providing the nitpicky stuff and so on.

39:48 You also suggested possibly having multiple reviewers.

39:51 Yeah.

39:52 Not a one-on-one situation.

39:53 Yes, I think a lot of people actually assume that core review is essentially one-to-one.

39:57 You have one person doing the authoring and one person doing the reviewing.

40:00 You can get real benefits from having multiple reviewers.

40:03 So this is something I hadn't done before working on OpenStack.

40:06 And in OpenStack, every change has to have at least two core reviewers.

40:12 And also then they'll often have other reviewers that are just community members that are interested.

40:17 So every change is, I actually looked at the numbers at one point, every change on average

40:21 was getting between three and five people reviewing it.

40:24 So they were a huge number, but only two of those were going to be in-depth reviews.

40:28 And it's just really surprising to me how often I will review something and then someone else

40:34 will come along and review and actually see something that I missed.

40:37 It helps multiply the benefits of the shared knowledge and the shared understanding.

40:40 It also takes the pressure off code review.

40:43 So you can not feel like you're the only person that's verifying this.

40:47 You don't feel as responsible, but you share that more.

40:51 It's not like you're the goalie.

40:52 And if it goes past you, it's over, right?

40:55 Yeah, exactly.

40:55 Interesting.

40:56 Yeah, definitely talked about the short reviews.

40:59 Do you think it would be beneficial to kind of reverse that as well and have multiple contributors?

41:06 So if I'm submitting a patch, this probably works better in a corporate space.

41:10 But if I'm submitting a patch and it's getting reviewed, I also have to like sit in on the review,

41:16 maybe be a reviewer, maybe just observe someone else's code being reviewed as well.

41:22 Like having that other side of the story not be one to many.

41:26 And that sounds a little bit like doing pair programming in maybe an asynchronous way.

41:30 So you have multiple people contributing to the project.

41:33 And I think that can work well, but it does probably require that you know people a bit more.

41:38 So this is something that I do see happen in OpenStack fairly often.

41:42 Some of my colleagues, if I see that they've got a review up and then there's a small addition or something else that I can make to it,

41:48 I'll just push a change to that.

41:49 I guess it also requires the tooling to support this.

41:53 It wouldn't be quite tricky in GitHub, for example, because you'd have to send a pull request to the branch,

41:58 which is the original pull request, and it becomes a message.

42:01 Yeah, yeah, yeah.

42:02 I'm certainly thinking like this is a place where you guys sit down over like a shared projector and have this conversation.

42:08 You know, something like that.

42:09 They get, you know, pure open source where it's all asynchronous.

42:12 I'm not sure it makes any sense.

42:13 I work from home remotely, so I always think about everything as being async and whatnot.

42:19 Yeah, yeah, same here.

42:21 I work from my house as well.

42:22 Okay, so all that stuff is really interesting.

42:25 Now, we talked a little bit on the tools that you might use to make this work.

42:30 So we've got Garrett, which is open source Python.

42:34 It's like a web app that you install.

42:35 Do you like connect it to your Git repo and it watches the branches or how does that work?

42:40 There are integrations for GitHub, which I've not actually used them very often.

42:44 But the way you interact with Garrett is with a Git plugin, which is actually also written in Python.

42:50 So you pip install a project called git-review, and that gives you a new command, which is git space review.

42:57 And there's a little configuration file in your code repository, and then that will send the review up for review to the destination of the Garrett installation.

43:07 And you will have an account with Garrett already with your SSH key in there, so it knows who you are.

43:12 Nice. I see.

43:13 So you do like a push to that origin or something, right?

43:16 And then it has it.

43:17 It doesn't necessarily have to hook into the full code repository.

43:21 Yeah, so the git review, it does a couple of different things, the command.

43:25 But primarily what it does is it sets up the remote for you and pushes and creates a branch for your change on the remote one

43:30 and gives you like a review number and that kind of thing.

43:32 Yeah, yeah. Very cool.

43:33 And then GitHub, obviously, we've talked about that a lot.

43:36 They just added like full proper code review where you can go to a check-in and like expand it out and comment and stuff.

43:41 So GitHub's coming along.

43:43 There's also Bitbucket.

43:44 Probably a lot of people use Jira.

43:46 I don't know the source usage relative to GitHub, but it seems like at least issue and review stuff happens a lot in Jira.

43:52 I'm not sure if Jira has code review built in, but I've not really used it.

43:55 The one I do hear quite good things about is Fabricator.

43:58 So this is actually written in PHP, I think.

44:00 And I also think it came out of Facebook originally.

44:02 I've heard of some people really having success with that.

44:06 Again, I've never actually used it myself.

44:08 The only two that I really have recent and extended experience with are GitHub and Garrett.

44:14 Sure.

44:15 Okay.

44:15 Excellent.

44:16 So some tools out there, I know actually in this whole space, there's like a billion tools, right?

44:21 There's a whole bunch of small things, but these are some of the big players in our space.

44:25 Very cool.

44:25 I think, you know, we're kind of getting to the end of the show.

44:27 We're running low on time.

44:28 Let me wrap it up with my final two questions, as always.

44:32 So if you're going to write some Python code or any code, what editor do you open?

44:35 I use Vim all the time.

44:37 Yeah.

44:37 I work in so many remote servers and VMs that I have some scripts to kind of set up my Vim environment on that machine.

44:46 And then it's just, it's great.

44:47 Oh, nice.

44:48 Yeah.

44:48 That's super portable.

44:49 Awesome.

44:49 Okay.

44:50 And favorite or favorites from the PyPI package.

44:54 Have we passed 100,000?

44:55 I'm going to look at what you're thinking.

44:58 We're definitely getting up there.

44:59 It is at 99,706.

45:02 I think tomorrow will be the 100,000 packages.

45:05 So there are rounding up 100,000 packages on PyPI.

45:09 What ones do you recommend for people to check out that are awesome?

45:12 So I think most of my favorites are the fairly common ones that people know about.

45:16 So I picked a couple of more obscure ones here, which I think are just quite nice.

45:20 And they've been useful in my development process.

45:22 So Vulture is one that you actually covered on Python Bytes.

45:26 You referenced one of my blog posts about it.

45:28 And basically, it's a tool for finding dead code.

45:32 So it finds functions which are never used.

45:34 And that kind of thing.

45:36 It's just really useful.

45:37 I think that's a really cool project.

45:39 And I'm glad we talked about it.

45:40 Because nothing is more frustrating to me than spending half an hour trying to understand what a function does in the context of an app.

45:45 To realize, oh, I don't understand it because it doesn't do anything.

45:49 Right?

45:50 Like, it's super cool.

45:51 So very nice.

45:52 It's amazing how often I've found projects which have a function and it's only has a unit test for it.

45:58 But it isn't used anywhere else.

46:00 But because there's a unit test, everything that inspects the code thinks it's being used.

46:05 But with Vulture, you can exclude any uses in your test cases, for example.

46:09 And then it'll highlight it.

46:11 So that works quite nicely.

46:12 Oh, very cool.

46:12 Very cool.

46:13 All right.

46:13 What's the next one?

46:14 The next one that I've been using recently is called pip debt tree.

46:18 So that's one word.

46:19 And what you can do with pip debt tree is you can provide it the name of a package which is installed in your virtual land.

46:25 And I'll actually give you the tree of requirements for that.

46:28 So you can see where another package came from, why it's there.

46:31 Right.

46:32 You might be looking at your virtual environment via pip list and go, why do I have beautiful soup installed?

46:36 Like I didn't install that.

46:37 Right.

46:37 And this would tell you, right?

46:38 It was installed because of this, which installed that, and it needed that or whatever.

46:41 Yeah.

46:41 And it prints it out in quite a nice sort of tree structure.

46:44 And then it's got a few other things.

46:45 Like you can do a reverse of that.

46:47 So you can have it tell you all the requirements for a package, or you can have it trace where something came from, like the opposite end.

46:54 So from the leaf node of the tree rather than the trunk.

46:57 Oh, that sounds awesome.

46:58 I didn't know about that.

46:59 And the final one you said is entry point inspector.

47:01 Yeah.

47:01 So this is probably the smallest one.

47:03 And I guess this is because I do quite a lot of Python packagings.

47:06 But if you have, so say for example, when you install pip deptree, it creates the pip deptree command for you that you can use in your terminal.

47:16 But actually trying to find out where these commands come from is quite difficult.

47:20 So entry point inspector will actually inspect the Python entry points that are defined in different setup.py.

47:27 And then I'll list them out.

47:29 So you can see where all these commands are coming from, where they're defined, what packages are coming from.

47:33 That sounds really cool too.

47:34 These are all great.

47:35 Awesome.

47:35 Thank you for sharing them.

47:36 Final call to action.

47:38 What should people do after listening to this?

47:39 They're all inspired about code review.

47:41 If people are inspired about code review, they should just think about how they can improve their process.

47:46 They should start thinking about what they're doing, build improvement into your code review process.

47:51 So every now and then maybe have some kind of retrospective and think about what's working, what isn't working, and just try and improve that.

47:57 Yeah, remember why you're doing it, right?

47:59 Yeah.

48:00 Absolutely.

48:01 Okay.

48:01 And then EuroPython's coming up, right?

48:03 Yeah.

48:03 So I did touch on this earlier, but EuroPython is going to be this year on July from the 9th to the 16th.

48:10 These dates are officially tentative, but I think they will be finalized by the time this episode is out.

48:15 I have to put that disclaimer in.

48:16 And people should start thinking about talks.

48:19 So we will have a call for papers coming out very soon as well.

48:21 I would love for people to speak.

48:23 If people have never spoken before, I'd be happy to speak to them about it.

48:27 and help them sort of find something that they want to talk about, I think that'd be good.

48:31 Yeah, it'd be great.

48:32 It's a very welcoming community, so a good place to get started with public speaking, right?

48:37 Yeah, absolutely.

48:38 It's where I first started speaking.

48:39 Well, Dougal, thank you so much for being on the podcast and sharing all these ideas with us.

48:43 It's been great.

48:44 Thanks.

48:44 I really enjoyed it.

48:45 You bet.

48:45 Bye.

48:45 This has been another episode of Talk Python to Me.

48:50 Today's guest has been Dougal Matthews, and this episode has been sponsored by Rollbar and Hired.

48:55 Thank you both for supporting the show.

48:57 Rollbar takes the pain out of errors.

49:00 They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.

49:07 As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.

49:15 Hired wants to help you find your next big thing.

49:17 Visit Hired.com slash Talk Python to Me to get five or more offers with salary and equity presented right up front

49:23 and a special listener signing bonus of $2,000.

49:26 Are you or a colleague trying to learn Python?

49:29 Have you tried books and videos that just left you bored by covering topics point by point?

49:34 Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course

49:40 to experience a more engaging way to learn Python.

49:42 And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/Pythonic.

49:50 Be sure to subscribe to the show.

49:52 Open your favorite podcatcher and search for Python.

49:54 We should be right at the top.

49:55 You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.

50:05 Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.

50:10 Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.

50:16 You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.

50:22 This is your host, Michael Kennedy.

50:24 Thanks so much for listening.

50:25 I really appreciate it.

50:26 Smix, let's get out of here.

50:28 Smix, let's get out of here.

50:28 Outro Music.

50:50 you .

50:51 you