Speaker 1: Hey everybody, and welcome back to another episode of Adventures
Speaker 1: in DevOps. This week, on our panel we have Jeffrey Girlman, Hey,
Speaker 1: check today doing all right?
Speaker 2: We also have Caleb Fernari, Hey, Chuck, how's it going?
Speaker 2: Doing well?
Speaker 1: I'm Charles Maxwood from dev chat dot tv. Just by
Speaker 1: way of announcement, we're starting a new show, or I
Speaker 1: guess I'm starting a new show. We released first episode
Speaker 1: this morning as we record this. It's called The dev
Speaker 1: Influencer Show. You can find it at dev influencers dot com,
Speaker 1: slash podcast, and I bet you can guess what it's about,
Speaker 1: talking about being an influencer in the developer and devop spaces.
Speaker 1: So if you're interested in that, go check out the show.
Speaker 1: I'm also doing an accelerator and you can find more
Speaker 1: about that at dev influencers dot com. We have a
Speaker 1: special guest this week, and that is James Donahue. James,
Speaker 1: do you want to say hello and introduce yourself all
Speaker 1: the way from the Britain and BBC.
Speaker 3: Hi?
Speaker 4: Yeah, James, I'm a software engineer at the BBC. I'm
Speaker 4: really happy to be on the show. Thanks for having me.
Speaker 2: Yeah, thanks for coming.
Speaker 1: I mean some of my favorite shows come out of
Speaker 1: the BBC, Doctor Who and Downton Abbey, which are very
Speaker 1: much not alike.
Speaker 2: Yeah, I have enjoyed those shows.
Speaker 1: Great British Baking Show is another one that started at
Speaker 1: the BBC. I don't think they own it anymore.
Speaker 4: But yeah, oh yeah, Roy Pokua, Yeah, everyone loves that show.
Speaker 2: Yeah.
Speaker 1: So you're you're like famous adjacent, right, we'll just say that, Yeah,
Speaker 1: you wrote this article on codeer Views. And what was
Speaker 1: interesting is is that we we lined it up on
Speaker 1: this show and MICHAELA was asking me what shows to
Speaker 1: get it on, and I was like, well, it's kind
Speaker 1: of good for any of the shows, and she's like,
Speaker 1: can I get it on the devop show? And initially
Speaker 1: I told her no. And then because because usually I
Speaker 1: see the article a name, I don't see the author name,
Speaker 1: and so you get on and I'm trying to make
Speaker 1: this connection, like what are.
Speaker 2: We talking about here?
Speaker 1: But I realized that we're doing a lot of infrastructuring
Speaker 1: code these days, right, whether it's hey, I'm going to
Speaker 1: go spin up this virtual server and then run chef
Speaker 1: or Puppet or something against it, or whether or not
Speaker 1: we have some provisioning software that goes out and manages
Speaker 1: our network or manages our servers, or whether we have
Speaker 1: something that manages things for Kubernetes or things like that,
Speaker 1: and so those code reviews are just as important as
Speaker 1: the other code reviews were doing. So I just kind
Speaker 1: of want to give people a little bit of background.
Speaker 1: This does apply to what you're doing in DevOps, but
Speaker 1: to get us started, I was looking at this article
Speaker 1: and you kind of explain, Hey, look, you know we
Speaker 1: we had to go remote, and because of that, you know,
Speaker 1: we experience certain things, and so we started doing the
Speaker 1: code reviews in a certain way. And I was wondering
Speaker 1: if you could tell that story, because I think this
Speaker 1: is something that people are really going to identify with
Speaker 1: that people are going to go, oh, yeah, we have
Speaker 1: that problem, and you know, maybe this will help some
Speaker 1: of them find that solution that they're looking for.
Speaker 2: Right, Yeah, of course, happy to you.
Speaker 4: So basically, the area that I work in at the
Speaker 4: BBC's the World Service, and we have international news websites.
Speaker 4: We have about thirty five million weekly users across the globe.
Speaker 4: The sites are in forty different human languages as well,
Speaker 4: so there's quite a lot of complexity in our code
Speaker 4: base dealing with all of that internationalization and the fact
Speaker 4: that it has a global audience, and we started rebuilding
Speaker 4: that application a couple of years ago. We had an
Speaker 4: old version that was a monolithic PHP applications service very well,
Speaker 4: but it was time to update the technology and we
Speaker 4: had lots of ideas new features we wanted to build.
Speaker 4: And what happened was we went in quite a short
Speaker 4: space of time from having about five developers working on
Speaker 4: a new renderer. We built a React based isomorphic single
Speaker 4: page application to replace the old monolith. I think we
Speaker 4: had about five developers working on it initially and over
Speaker 4: the course of really just a few months we went
Speaker 4: from that to about thirty five developers. And also another
Speaker 4: thing happened was that we went from all being based
Speaker 4: in one office in London at Broadcasting House to being
Speaker 4: distributed across different cities in the UK and also in
Speaker 4: other countries as well in Africa. We had some developers
Speaker 4: we were starting to have to get used to remote
Speaker 4: first development, and this is before the pandemic, this is
Speaker 4: before you know, the big changes of last year. We
Speaker 4: were having to adapt to scaling quite quickly and also
Speaker 4: being remote first all the time, and that's when we
Speaker 4: started to notice that something interesting was happening to code reviews.
Speaker 4: Some of our code views were taking out a bit
Speaker 4: longer than we'd like. We noticed there were some problems
Speaker 4: where code reviews would spend a long time going on.
Speaker 4: There'd be a lot of comments on the pull requests,
Speaker 4: a lot of back and forth between different people. A
Speaker 4: lot of new engineers were contributing to the code base,
Speaker 4: and not all of them really knew how we did
Speaker 4: code reviews or how we approached them, and we felt
Speaker 4: that there was probably a lot of tacit assumptions in
Speaker 4: the way we were doing code reviews. We also had
Speaker 4: a bit of feedback from some of our developers that
Speaker 4: they found the process quite confusing and quite stressful sometimes.
Speaker 4: And it was really at that point that we thought, Okay,
Speaker 4: we need to take a step back from this. We
Speaker 4: need to talk about what is this code review process for?
Speaker 2: Why do we do code reviews?
Speaker 4: And the interesting thing was that none of us could
Speaker 4: really remember ever having.
Speaker 2: Had this conversation before.
Speaker 4: We'd all been doing code reviews for years, and we
Speaker 4: never actually said why do we do this?
Speaker 2: What are we trying to get out of this?
Speaker 4: And that was really the starting point, we wanted to
Speaker 4: talk about it honestly and openly and really find out
Speaker 4: what everyone wanted to get out of the code of
Speaker 4: view process.
Speaker 2: That makes sense.
Speaker 1: It's funny too because as you go to kind of
Speaker 1: that remote first or primarily remote culture, right, because some
Speaker 1: companies went almost fully remote. In other companies they either
Speaker 1: had some kind of requirement or managed to have hold
Speaker 1: on to having some of their folks stay in the office, right.
Speaker 1: But as you move even part of your team out
Speaker 1: of the office, the requirements on your communication goal way up.
Speaker 1: And so it's it's definitely interesting that, Yeah, all of
Speaker 1: a sudden you're having discussions about how you communicate in
Speaker 1: these ways. I'm a little curious before we dive into
Speaker 1: how to start approaching this though, or other panelists Jeffrey
Speaker 1: and Caleb, I mean, what, what what's been your experience
Speaker 1: with this kind of thing, going remote in this way,
Speaker 1: especially through COVID.
Speaker 3: Yeah, I know, I think you sort of hit it
Speaker 3: on the head. I mean, it totally made us really
Speaker 3: refocus on how we communicate and and you know, you
Speaker 3: just can't walk over to the to the next person's
Speaker 3: cube or you know, or say hey, let's just grab
Speaker 3: a breakout room or something. I mean a physical breakout
Speaker 3: room that a zoom breakout room, right, and that changed
Speaker 3: a lot. But I'm curious. I want to i want
Speaker 3: to throw a question back to James. I'm curious what
Speaker 3: you guys came up with, because when I read your
Speaker 3: article on Medium, I was thinking, Wow, you know you
Speaker 3: ask all these questions about like why are we doing
Speaker 3: code reviews? And I was thinking, you know what you said,
Speaker 3: it's all the above, and you're like, what fifteen or
Speaker 3: twenty different answers? What did you guys come up with?
Speaker 3: What is the reason, what's the motivation?
Speaker 2: Well?
Speaker 4: Yeah, I mean you're right, we did list a lot
Speaker 4: of things that we thought code reviews before. I think
Speaker 4: in the blog post I put like fifteen different possible
Speaker 4: reasons that you could do code reviews. The thing we
Speaker 4: kept on coming back to time and time again, the
Speaker 4: motivation for code reviews that we seemed to be hitting
Speaker 4: no matter how we talked about it was communication and
Speaker 4: understanding a lot of the things that I summarized in
Speaker 4: the article really came out of discussions in our teams
Speaker 4: where we were asking what code reviews for? So you know,
Speaker 4: if you're if you're if you're discussing different approaches on
Speaker 4: a code review, that's a form of communication. If you're
Speaker 4: linking to other documentation or resources, that's communication. You know,
Speaker 4: you might be checking that work meets certain quality standards,
Speaker 4: or thinking about readability and maintainability, those kind of things.
Speaker 2: Communication seems to be the recurring theme here.
Speaker 4: So we felt that that was really something we like,
Speaker 4: we wanted to put at the heart of what we
Speaker 4: were saying that code reviews werefore because a lot of
Speaker 4: people have got different expectations about what code reviews are
Speaker 4: really for them. That and that kind of surprises people
Speaker 4: when you when you say to them, hate it's more
Speaker 4: about communication than anything else.
Speaker 3: Yeah, absolutely, I always felt like it was. There was
Speaker 3: almost this you know, unspoken idea that it's all about quality,
Speaker 3: code quality, and hey, it's just up to snuff. And
Speaker 3: you know, I mean, I've got a security background, so
Speaker 3: I'm in cybersecurity and application security all the time. And
Speaker 3: so when you know, folks in my world think about
Speaker 3: code reviewers, we're always focused on thinking about code defects
Speaker 3: that are of a security in nature. Right, how do
Speaker 3: we how do we try and find those underlying issues
Speaker 3: in code and sometimes just to go off on a
Speaker 3: tingent for a moment. I think that's interesting is that,
Speaker 3: you know, what, do a lot of reverse engineering of
Speaker 3: code to sort of understand, you know, where can somebody
Speaker 3: who's trying to do something nefarious, where can they sort
Speaker 3: of grab a toe hold and do something interesting, whether
Speaker 3: it's around access control, authentication, something like that, you know,
Speaker 3: in the software base. And so I just sort of
Speaker 3: gravitate towards that idea that code reviews are always about,
Speaker 3: you know, finding code defects. And it's interesting because I
Speaker 3: think there's a lot to what you're saying that it
Speaker 3: really should be a lot about just getting the whole
Speaker 3: team together and sort of communicating and you know, sort
Speaker 3: of more on getting them on the same page, because
Speaker 3: you know, at least generically speaking, I can see a
Speaker 3: lot of value in that and then doing you know,
Speaker 3: if you've got specific purposes like what I'm describing, then
Speaker 3: that might be a different use case, a different reason,
Speaker 3: and maybe a different setting for running a code review
Speaker 3: outside of I think what you're describing. But I don't
Speaker 3: want to put words in your mouth, but I'm sort
Speaker 3: of just trying to get an old Sheldon in my
Speaker 3: own mind.
Speaker 4: Sure, you know, I think you're absolutely right, Jeffrey. I mean,
Speaker 4: the view that code reviews are about finding defects is
Speaker 4: primarily about finding defectses is a really widely held one.
Speaker 4: One of the things I mentioned in the article is
Speaker 4: there's a really interesting piece of academic research that we've
Speaker 4: done at Microsoft in I think twenty thirteen, where they
Speaker 4: examined hundreds of code reviews across large parts of their
Speaker 4: code base, and they analyzed each code of view in
Speaker 4: terms of what the actual outcome of that code review was.
Speaker 4: They looked at every comment on the poor request and
Speaker 4: they categorized them all, and they basically figured out that
Speaker 4: the most common outcome of code reviews was basically people
Speaker 4: asking questions about something, other people explaining things, and that
Speaker 4: process of communication, learning about the code or discussing the
Speaker 4: code is the most common outcome. Whereas when they interviewed
Speaker 4: the developers and said what do you think is the
Speaker 4: most common outcome of code reviews, they said, oh, it's
Speaker 4: all about finding defects. But there was a just found
Speaker 4: The funny effects is it does happen. Of course, it
Speaker 4: does happen. Sometimes people will find a bug in code
Speaker 4: just from looking at it visually, but there's actually a
Speaker 4: lot of other stuff going on. There's there's coaching and mentoring,
Speaker 4: there's you know, exchanging ideas and approaches.
Speaker 2: There's not all of it.
Speaker 4: It's just about saying, hey, we found a bug, you
Speaker 4: got this wrong, this needs to change, and although you
Speaker 4: know that is one possible outcome.
Speaker 1: Yeah, I like that in the sense that how do
Speaker 1: I put it? Because when we do the code reviews,
Speaker 1: a lot of the communication in the code reviews is
Speaker 1: about that, right, I didn't see anything wrong with this,
Speaker 1: and so I approved the pull request. That's kind of
Speaker 1: how we run at work. I mean, we do mob programming,
Speaker 1: so you know, we have different teams of like three
Speaker 1: four people sometimes two people, you know, and we just
Speaker 1: get on a remote call. It's exhausting, by the way,
Speaker 1: and then we just we code all day. But then
Speaker 1: we pass off our work in a PR to somebody
Speaker 1: else who does a code review on it. And yeah,
Speaker 1: a lot of it is just we want somebody to
Speaker 1: look at it and give feedback on it.
Speaker 2: But it's not that specific.
Speaker 1: And I think that's something that I'm kind of pulling
Speaker 1: out of this, out of your article and out of
Speaker 1: what Jeffrey is pointing out, and what you're saying is that,
Speaker 1: you know, we've got to basically open the door and say, hey, look,
Speaker 1: it's okay for you to say, hey, I don't understand this.
Speaker 2: Can you train me on it? Right? Or I don't know?
Speaker 1: I you know, I don't understand this approach. Can you
Speaker 1: explain to me why we went this way in not
Speaker 1: a different way? Or I'm trying to understand this particular
Speaker 1: area of code, you know, or maybe I do see
Speaker 1: that this thing could be problematic, either for maintenance or security,
Speaker 1: or you know, any of the other number of things
Speaker 1: that we wind up coming back around to because they
Speaker 1: bid us in the rear end at some point, right,
Speaker 1: and you know, in those kind of fall toward defects.
Speaker 1: But some of those are really kind of how do
Speaker 1: I put it, they're they're kind of cloaked to something else,
Speaker 1: you know, if it's a maintenance issue, and then we
Speaker 1: eventually clean up what's causing the maintenance issue, it's not
Speaker 1: necessarily a defect. It is a defect, but we don't
Speaker 1: think of it in the same way as we think
Speaker 1: of a bug, right because the code still works. It's
Speaker 1: just every time we go change it. We have to
Speaker 1: you know, jump through a whole bunch of hoops to
Speaker 1: make sure we didn't break anything. It's a maintenance nightmare.
Speaker 1: And so you know, and I can kind of imagine
Speaker 1: the same thing with you know, whether it's infrastructure or
Speaker 1: chef recipes or you know, whatever you're dealing with, that
Speaker 1: same kind of thing. And so yeah, if somebody can
Speaker 1: pass along, hey, look we do it this way because
Speaker 1: we found that it saves us all these other hassles
Speaker 1: in the back end. And what's funny is is sometimes
Speaker 1: you'll get the new person in my I have a
Speaker 1: fifteen year old who's playing video games now, so the
Speaker 1: total nube will come in, right, and they'll say, oh, well,
Speaker 1: why don't you try this other approach then? Right, that
Speaker 1: has all those benefits you just listed for why you're
Speaker 1: doing it this way, but also gives us this other
Speaker 1: benefit that I'm seeing we might be able to add.
Speaker 1: And then all of a sudden, you have a better process, right,
Speaker 1: And by understanding and documenting and pushing and communicating, that
Speaker 1: opens up all these doors. And that's really yeah, that's
Speaker 1: what we're talking about with these code views. And that's
Speaker 1: back to the original idea. It's all of the above.
Speaker 1: It sounds like you have a process, you know, after
Speaker 1: reading through this article, you have a process for conducting
Speaker 1: these code reviews that make sure that all these things
Speaker 1: get communicated about.
Speaker 5: Right.
Speaker 1: It's not just opening the door for it, it's explicitly
Speaker 1: calling out, hey, are we thinking about security? Are we
Speaker 1: thinking about code structure? Are we thinking about you know,
Speaker 1: these different levels of concern so that at the end
Speaker 1: of the day we know that we've covered our bases
Speaker 1: here and we're communicating about the things that we care
Speaker 1: about in our code.
Speaker 2: Yeah.
Speaker 4: Absolutely, I mean I think you've hit on an interesting
Speaker 4: point there, which is about who does code reviews or
Speaker 4: who can do a code review. We were quite clear
Speaker 4: in the discussions we had at the BBC that we
Speaker 4: thought that developers, engineers of all levels should participate in
Speaker 4: the code view process. It shouldn't be a situation where
Speaker 4: my code can only be reviewed by somebody who is,
Speaker 4: you know, a pair of mine, or somebody with more
Speaker 4: experience than me, or more familiarity with this than me.
Speaker 4: Just for the reasons you've given that that quite often
Speaker 4: you get really interesting perspectives and questions and challengers from
Speaker 4: people who are new to develop new to engineering, new
Speaker 4: to this particular code base, and so in order to
Speaker 4: try and help facilitate that, we put some some prompts
Speaker 4: and suggestions into our code reviews guide, where we're saying,
Speaker 4: if you're a new developer, if you're need to this
Speaker 4: code base, here are some things you can try when
Speaker 4: you're doing a code review. Here are some things you
Speaker 4: can ask Have you spotted something that looks a little
Speaker 4: bit inconsistent? I mean you could ask the author to
Speaker 4: explain that. Have you asked the author about if they've
Speaker 4: considered security, performance, accessibility, other kinds of non functional requirements.
Speaker 4: So a bit of a cheat sheet almost where you
Speaker 4: can say, you know, these are things we should be
Speaker 4: thinking about when we did code reviews. And it brings
Speaker 4: more people in the team into that process, right. It
Speaker 4: means that more junior engineers or less experienced engineers can
Speaker 4: participate and actually give just as much value to that
Speaker 4: process as people who you know, have been working on
Speaker 4: the code for years.
Speaker 6: What James is, when you're talking about kind of you know,
Speaker 6: having junior developers doing code reviews and these kind of things,
Speaker 6: it seems like a large part of what you're doing
Speaker 6: is kind of reframing the intent of the code review.
Speaker 6: And I don't know if this is a problem you
Speaker 6: guys have had the BBC, but I've seen teams in
Speaker 6: the past where junior developers very intimidated by the code
Speaker 6: review process, and you know, it's kind of seen as
Speaker 6: a gatekeeping role where they're checking in code and then
Speaker 6: senior developers are looking at it and kind of you know,
Speaker 6: going over it. So I really like the kind of
Speaker 6: idea of reframing it so that it's you know, code
Speaker 6: reviews are everyone's responsibility. It's a collaborative team process, and
Speaker 6: it's more about the communication rather than the gatekeeping, even
Speaker 6: though you still get maybe some of those gatekeeping functions
Speaker 6: if you do need to have security reviews or have
Speaker 6: senior developers reviewing code and looking over those things. Just
Speaker 6: by reframing it you get all the benefits and maybe
Speaker 6: a much better participation rate, particularly in a remote context
Speaker 6: where onboarding developers can be a little bit more intimidating,
Speaker 6: Especially for junior developers. You don't have that kind of
Speaker 6: face time. You know, it's a little hard build team
Speaker 6: cohesion remotely in those kind of things. Is that the
Speaker 6: correct kind of analysis of the direction you're going with.
Speaker 2: This, Yeah, absolutely, Caleb.
Speaker 4: We found that, particularly we're going more remote first, that
Speaker 4: junior developers, less experienced developers were quite wary of the
Speaker 4: process and quite reluctant to get involved. And you know,
Speaker 4: as we were saying earlier, you can't just lean over
Speaker 4: to the person sat next to you at your desk
Speaker 4: and you know, informally ask for help. Everything is a
Speaker 4: bit more formal, a bit more structured once it's done
Speaker 4: just via pull requests. We wanted to really encourage people
Speaker 4: at old levels to get involved in that process. And yeah,
Speaker 4: I think we were really reframing code of views a
Speaker 4: little bit and make it feel making it seem more
Speaker 4: like a collaborative process that is benefiting everybody in the team.
Speaker 4: I mean, I think we have to recognize as well
Speaker 4: that code views can be quite demanding, can be quite
Speaker 4: stressful in fact, for people of all levels of experience.
Speaker 4: You know, having your work looked at by other people
Speaker 4: can be challenging sometimes, But at the same time, it's
Speaker 4: part of being a software engineer that you people are
Speaker 4: to look at your code and you have to be
Speaker 4: able to receive feedback about your code and give feedback
Speaker 4: on other's code and get comfortable with that process. So
Speaker 4: there is obviously still a gatekeeping function within code reviews,
Speaker 4: and there's an important role for that, but we wanted
Speaker 4: to try and promote the idea that the team owns
Speaker 4: the code collectively. It's not like up to an individual
Speaker 4: person to decide whether something is okay or not.
Speaker 2: It should be a collective decision.
Speaker 4: People can have different perspectives on that, and to make
Speaker 4: it a bit more of an approachable process that it's
Speaker 4: not so seen as in a really intimidating thing where
Speaker 4: this really senior experienced person will come and give a
Speaker 4: verdict on your code. It's more of a dialogue where
Speaker 4: they say, okay, so why do you approach the problem
Speaker 4: this way?
Speaker 2: Have you considered it this way?
Speaker 4: It's not just, you know, just the kind of pure
Speaker 4: gatekeeping process that it might have been seen as occasionally
Speaker 4: in the past.
Speaker 1: Yeah, I'm going to step into my confessional here for
Speaker 1: a second, because so the job I'm in now when
Speaker 1: I got hired, so my full time job, I'm actually
Speaker 1: writing Ruby on rails and then I kind of dabble
Speaker 1: and react. We're kind of sneaking that into the code
Speaker 1: a bit now, and when I got hired. Just to
Speaker 1: give a little bit more context, Ruby Rogues, which is
Speaker 1: our longest running podcast on chat DOTV, has been running
Speaker 1: for it will be ten years in about a month.
Speaker 2: Oka.
Speaker 1: And so I'm widely seen as an expert in Ruby
Speaker 1: on rails and I was sold that way when they
Speaker 1: hired me. Kay, they told everybody that works in the
Speaker 1: office here in Utah, you know, this guy's an expert.
Speaker 1: He's a dream hire. Blah blah blah blah. And every
Speaker 1: time I do a code review, I feel like I
Speaker 1: have to live up to that, right, And so it
Speaker 1: feels that way for seniors sometimes too, right They feel
Speaker 1: like they have to be the one to catch it,
Speaker 1: they have to be the one to see it, they
Speaker 1: have to be the one to know the answer to that.
Speaker 1: And there are some parts of these applications that I
Speaker 1: just have not really done a whole lot with and
Speaker 1: I have to swallow my pride and take that too.
Speaker 1: And so I think it's important for everybody at whatever
Speaker 1: level you're at, to just realize, look, you've got to
Speaker 1: you know, this is an opportunity for you to level
Speaker 1: up as much as it is for an opportunity for
Speaker 1: you to help somebody else level up.
Speaker 3: You know, one thing I'm curious man, is well, I
Speaker 3: guess two things. One is, you know, with everyone that
Speaker 3: are coming into code views with a different mindset and
Speaker 3: some of it being around, hey, how do we you know,
Speaker 3: we want to find code defects? Did you or did
Speaker 3: your team sort of decide or sort of come out
Speaker 3: of this and say okay, in order to sort of
Speaker 3: keep people focused on what we want them to be
Speaker 3: doing and not just sort of you know, getting them
Speaker 3: too stressed out about, you know, trying to find something
Speaker 3: that may not even be there, right, did your team
Speaker 3: sort of relook at well, maybe there's a better way
Speaker 3: for us to find you know, let's get people's mindset
Speaker 3: completely away from you know, I'm going to find something
Speaker 3: wrong with somebody's code, right, and and and focus that
Speaker 3: on hey, maybe we'll do a better job, or maybe
Speaker 3: we'll sort of rethink how we formalize the QA function
Speaker 3: or you know, testing or something like this. This way,
Speaker 3: everyone understands that that's really where we do, that's where
Speaker 3: we find code efacts, right, and and to really focus
Speaker 3: people on the review process is not about that if
Speaker 3: it comes up great, if not, so that that's My
Speaker 3: first question is, you know, was there change in how
Speaker 3: you also.
Speaker 7: Thought about finding effects?
Speaker 3: And my second question is coming out of this, I'm
Speaker 3: not sure how long this has been put into practice now,
Speaker 3: I'm curious that what have the outcomes been, Like have
Speaker 3: you been you know, measuring instrumenting this and saying, hey, wow,
Speaker 3: this is really cool. What we're finding is that the
Speaker 3: result of all this effort has been that, I don't know,
Speaker 3: our developers are much more productive more, everyone's much.
Speaker 7: Happier because we're communicating better or I'm not sure. I'm
Speaker 7: curious about those two areas.
Speaker 1: Jesus team gets a thousand more code points per week, right, Yeah,
Speaker 1: I can try to answer the second question.
Speaker 4: So there's two sides to it, really, I suppose to
Speaker 4: the qualitive quantitive side. Really, in terms of qualitative, we
Speaker 4: we didn't really have a precise way of measuring that.
Speaker 4: We had some discussions earlier on some feedback from some developers,
Speaker 4: particularly ones that were new to working on the code
Speaker 4: base on the teams, that they were finding the process
Speaker 4: difficult and stressful. We then had some feedback later on
Speaker 4: that things had improved and that there was there was
Speaker 4: a view that things were now getting easier for especially
Speaker 4: for new developers. That's kind of a very kind of
Speaker 4: subjective thing. On the more sort of objective quantitive side,
Speaker 4: we could see we had some software that we were
Speaker 4: using to track the number of poor requests that were open,
Speaker 4: how long those poor requests had been in code review,
Speaker 4: how many could review cycles they've been through, and how
Speaker 4: many comments from the pull requests. And we saw that
Speaker 4: all of those measurements kind of moved in the direction
Speaker 4: we wanted them to go in. So code was spending
Speaker 4: less time in code review, it was going through less
Speaker 4: revision cycles, and the result was we were actually merging
Speaker 4: and shipping that code faster. Now, the code view process
Speaker 4: wasn't the only thing that we changed during that time.
Speaker 4: I've got to say there was a lot of changes
Speaker 4: going on at the time. One of the other things
Speaker 4: we were working on at the same time we tried, Charles,
Speaker 4: you've spoken about mob programming or swarm programming.
Speaker 2: We called it. We've tried that as well.
Speaker 4: So we were doing a lot of work with mobbing
Speaker 4: and additional pairing, and that may have also helped bring
Speaker 4: down the burden of code reviews. I'm really interested to
Speaker 4: hear what other people think about that because we found
Speaker 4: that by doing more collaboration upfront before you get into
Speaker 4: the code review stage, by having more voices and more
Speaker 4: kind of perspectives heard during the initial implementation phase, quite
Speaker 4: often that the sort of formal okay, now let's do
Speaker 4: a code review part of this is actually tends to
Speaker 4: be a lot smoother because a lot of that communication
Speaker 4: has already happened, a lot of possible objections or concerns
Speaker 4: have already been anticipated earlier on. So that was something
Speaker 4: else we were trying at the same time. And I
Speaker 4: think it's a complementary technique. It's not like you don't
Speaker 4: have to do just that or just change your code
Speaker 4: reviews process, that both things can kind of can kind
Speaker 4: of help you achieve the same goal. But yeah, we
Speaker 4: have seen we have seen improvements both in terms of
Speaker 4: the rate in which we're able to deliver stuff and
Speaker 4: also subjective feedback from anonymous feedback from developers in the
Speaker 4: team that they were finding the process just easier and
Speaker 4: more enjoyable.
Speaker 6: What are some tools that you've found helpful when doing
Speaker 6: code reviews or you know, you mentioned something you're using
Speaker 6: to track code reviews and things like that. What does
Speaker 6: this look like on a practical level as far as
Speaker 6: tools and process when you're doing the code amusement, are
Speaker 6: you using GitHub whole requests or do you have other,
Speaker 6: you know, sort of specialized software or less known tools
Speaker 6: that you're using to help with that.
Speaker 4: Yes, so we use GitHub for really most of our
Speaker 4: work these days, so it's good. Pull request is the
Speaker 4: main way that we track back, and then we have
Speaker 4: some tooling dot on top of that that we were
Speaker 4: using to keep an eye on the number of pull
Speaker 4: requests that were open and the how long things have
Speaker 4: been in the code review stage. And yeah, we still
Speaker 4: use things like jerror as well for tracking some more
Speaker 4: project level activity.
Speaker 2: So those are some of the tools we're using.
Speaker 4: We do have a few in house tools that we
Speaker 4: use as well to just just keep an eye on
Speaker 4: the rate that things are being worked on and how
Speaker 4: long it's taking things to seem to actually make it
Speaker 4: to production.
Speaker 2: Yeah.
Speaker 1: I'm going to chime in here too on a couple
Speaker 1: of things that got brought up. One for the mob programming,
Speaker 1: I completely agree it helps head off so many issues
Speaker 1: because you know, I'll be focused on the code. The
Speaker 1: other two guys that I work with every day are
Speaker 1: paying attention, and they'll call stuff out, Hey, why are
Speaker 1: we doing this? Why are we doing it that way?
Speaker 1: What about this? What about the other thing? And I
Speaker 1: do the same thing for them, and we just turn
Speaker 1: out way better code, you know, from the maintainability, from
Speaker 1: the reliability, from the performance, from pretty much any measurement
Speaker 1: you have for code. We just do, you know, And
Speaker 1: so they they make my code look better what I commit,
Speaker 1: and you know, all around vice versa. We do most
Speaker 1: of that over Microsoft Teams. I will not tell you
Speaker 1: how much I dislike Microsoft Teams, but it works. We
Speaker 1: also use poll requests on GitHub. That's our primary way
Speaker 1: of doing that, and so all the feedback goes into
Speaker 1: the pole request and then when it gets merged, then
Speaker 1: you know, it's all still in GitHub if we ever
Speaker 1: have to go back and look at it. We don't
Speaker 1: have any real in house tools, and we don't track
Speaker 1: how long they sit in pole requests because honestly, it's
Speaker 1: abnormal for a pole request within our organization because we
Speaker 1: actually review code from the other projects that we're not
Speaker 1: working on. Within the organization, we everybody reviews everybody's stuff,
Speaker 1: and so if you don't understand what's going on, in
Speaker 1: the other project.
Speaker 2: That's fine.
Speaker 1: You just ask, right, but you have to stay on
Speaker 1: top of your review, So if they answer, you have
Speaker 1: to be on top of it because you don't want
Speaker 1: to hold them up either. But yeah, that works pretty
Speaker 1: well for us. It'd be abnormal if anything stated in
Speaker 1: the queue for longer than a day for us, so
Speaker 1: that that hasn't been an issue for us. But yeah,
Speaker 1: those are the same tools we're using. I will also
Speaker 1: not tell you how much I dislike I mean hate,
Speaker 1: I mean completely hate despised Era. But we used zero
Speaker 1: as well. So yeah, you know a lot of the
Speaker 1: same approach. But I think we're also you're working for
Speaker 1: a fairly large company. I'm working for a large enterprise.
Speaker 1: I'm deliberately not saying where I work, but I work
Speaker 1: for a fairly large enterprise company here in the US.
Speaker 4: Yeah, I'm one of the you mentioned teams that one
Speaker 4: of the one of the things that we found when
Speaker 4: going through this process thinking about code reviews was I
Speaker 4: think some of this, probably myself included that I was
Speaker 4: guilty of this at one point, was thinking that a
Speaker 4: code review and a pull request are the same thing,
Speaker 4: and the way you do code reviews is you write
Speaker 4: comments on a pull request. And when we started to
Speaker 4: talk about code reviews and think about how we could
Speaker 4: do them, we realized there's so many other ways of
Speaker 4: doing code reviews. You know, the idea of code reviews
Speaker 4: long predates GitHub obviously, and often adding comments to a
Speaker 4: poor request on GitHub is the least efficient way of doing.
Speaker 2: A code review.
Speaker 4: You know, it can be very powerful, particularly where you've
Speaker 4: got distributed teams, as we've already said, people remote working
Speaker 4: people in different time zones. It can be very efficient
Speaker 4: if you need that asynchronous communication. But there are you know,
Speaker 4: there are situations where the most efficient way of doing
Speaker 4: a code review would be to get on a team's
Speaker 4: call or a zoom call or something else with the
Speaker 4: other person, the author if you're the reviewer, and talk
Speaker 4: through their changes and try and understand their reasoning, the
Speaker 4: thinking behind the change they made, talk about alternatives. Yes,
Speaker 4: you might want to then think about summarizing the results
Speaker 4: of those conversations in some forms so it can be
Speaker 4: persisted to the poor request or some other forms so
Speaker 4: that other people can can you know, see the outcome
Speaker 4: of that discussion. But one of the things we try
Speaker 4: to encourage our engineers to do is if you're having
Speaker 4: a conversation with somebody on a pull request and you're
Speaker 4: getting a comment and sort of back and forth comment report,
Speaker 4: comment reply, that's usually a sign okay, maybe this would
Speaker 4: benefit from a call. Maybe we should talk about this
Speaker 4: face to face, because it's just, you know, it's just
Speaker 4: not the most efficient way of two people explaining their thinking.
Speaker 4: You know, getting on a call is often going to
Speaker 4: save time and save misunderstandings as well.
Speaker 2: Man, that sounds like work.
Speaker 1: Sorry, I I it's I'm I'm being a little bit
Speaker 1: tongue in cheek. But the reality is is that that's
Speaker 1: kind of, at least for us, our default behavior. But
Speaker 1: I don't think anybody's like formalized that as something that hey,
Speaker 1: if you're having back and forth, get on a call,
Speaker 1: which I think would be helpful for us to do, right,
Speaker 1: because sometimes it does turn into a lengthy back and
Speaker 1: forth and we should at some point just pull the cord,
Speaker 1: get on a call, and make.
Speaker 2: It d Yeah.
Speaker 4: So this is this is I think that some developers
Speaker 4: do that kind of thing instinctively a lot of the time.
Speaker 4: It would come down to your experiences, maybe code reviews,
Speaker 4: you've you've worked on that have gone well or gone
Speaker 4: less well, or maybe even aspects of your personality type,
Speaker 4: you know, how you prefer to communicate. Some people will instinctively,
Speaker 4: you know, if they're in an office, go over and
Speaker 4: talk to the author of the code, or they will
Speaker 4: pick up the phone and talk to somebody. Other people
Speaker 4: because of the way they work, because of their communication preferences,
Speaker 4: would rather just write a long description of their thoughts
Speaker 4: on a pull request. So what we wanted to do
Speaker 4: through this, through writing this guide to code reviews, was
Speaker 4: to sort of at least give people the opportunities to
Speaker 4: think about the alternatives and why there might sometimes be
Speaker 4: better ways of communicating. So you know, we don't insist
Speaker 4: upon everybody going on a call all the time to
Speaker 4: discuss poor requests. It's sometimes it's just not practical, but
Speaker 4: it should always be there as a you know, as
Speaker 4: a kind of something that people can say, Okay, look,
Speaker 4: I think this might be a good idea. It's something
Speaker 4: we probably want to consider, and at least people are
Speaker 4: aware of the options.
Speaker 2: That makes sense.
Speaker 1: I'm kind of curious going back to earlier in our conversation,
Speaker 1: you know, and we talked about different areas that you
Speaker 1: call out or different questions that you tell people they
Speaker 1: can ask in a code review. What areas do you
Speaker 1: specifically give people that they can think about or call
Speaker 1: out in a code review?
Speaker 4: So I suppose the starting point, you know, I've spoken
Speaker 4: quite a bit about how we thought communication was really important.
Speaker 4: Some of the ideas that we kind of suggest in
Speaker 4: our guide is asking people to We've already spoken about
Speaker 4: it a little bit, to seek clarification. If there's things
Speaker 4: that don't seem completely obvious on the change, asking the
Speaker 4: author to clarify them. Sometimes we find that when people
Speaker 4: seek that clarification, the author might say actually, or you know,
Speaker 4: in a conversation talking about it, you might say, well, okay,
Speaker 4: if you're asking that question, then somebody else is going
Speaker 4: to think this in the future as well. So is
Speaker 4: there a documentation need here? Is the code readable enough?
Speaker 4: Do we need to put something? You know, kind of
Speaker 4: do we have to have some additional documentation or explanations
Speaker 4: make it easier to understand? So, yeah, getting clarification is
Speaker 4: an important first one. And then I mean everything really
Speaker 4: kind of is all about asking questions. So you know,
Speaker 4: the cliche about there being no stupid questions. We try
Speaker 4: and kind of spell that out in our guide to
Speaker 4: code reviews. We really want people to ask questions on
Speaker 4: the assumption that if you're thinking it, if you're going
Speaker 4: to ask the questions, somebody else is probably thinking it too.
Speaker 4: Somebody else is at least wondering the same thing. And
Speaker 4: as I already said, we try and encourage developers to
Speaker 4: think about things like non functional requirements quite often, things
Speaker 4: that might have been missed during the initial requirements analysis
Speaker 4: or during the implementation. You know, have we thought about
Speaker 4: performance on this? Are we load testing this? Have we
Speaker 4: updated documentation? Is their missing test coverage? You know, a
Speaker 4: lot of these things that can be very easily even
Speaker 4: if we have the most perfect engineering process from start
Speaker 4: to when things can get missed. And sometimes asking those questions,
Speaker 4: even if the answer is just yes, we've already anticipated
Speaker 4: all of those things, it's useful to have somebody checking
Speaker 4: those questions. And yeah, I mean that those are kind
Speaker 4: of those are the main areas really, and we do
Speaker 4: kind of try and encourage people to if they're adding
Speaker 4: comments on THEO pull requests to sort of offer links
Speaker 4: and examples as well. So if you're going to sort
Speaker 4: of say, you know, there's a better way of doing this,
Speaker 4: or there's an alternative approach to doing this, or there's
Speaker 4: a more I don't know, idiomatic way of doing this
Speaker 4: in this particular language. You know, it really helps it
Speaker 4: to sort of give a bit more context than that,
Speaker 4: either to give an example to link to some relevant
Speaker 4: documentation or a blog post that explains the technique in
Speaker 4: more detail, and it really kind of gives the author
Speaker 4: or the person reading the comments of the opportunity to
Speaker 4: do a bit of research and read up and understand
Speaker 4: what it is that you're saying and save some of
Speaker 4: that kind of time with back and forth explanations.
Speaker 6: Something we asked about a lot in the DevOps world
Speaker 6: is the kind of the shift left philosophy around things
Speaker 6: like bringing security to the forefront of design before you
Speaker 6: actually even start implementing that location or even infrastructure, right
Speaker 6: like understanding how the application is going to be deployed
Speaker 6: and designing around that during the initial phases. And some
Speaker 6: of the things that you said kind of brought that
Speaker 6: to mind as far as pull requests go, where it's
Speaker 6: like instead of kind of pushing all of the review
Speaker 6: and the collaboration to the end, you know, kind of
Speaker 6: the swarm programming approach and things like that seem like
Speaker 6: it could kind of be used in a similar manner
Speaker 6: to actually bring some of the review process to the
Speaker 6: beginning of the design rather than waiting until something's already
Speaker 6: implemented in order.
Speaker 2: To do that.
Speaker 5: Is that part of kind of what you guys have done.
Speaker 6: Do you feel like you've brought maybe some of the
Speaker 6: code review process into the design and made it more
Speaker 6: collaborative or had you thought about that aspect.
Speaker 5: Of it at all.
Speaker 4: I think that is a real opportunity, like and that
Speaker 4: is something that you know, we're quite excited about being
Speaker 4: able to do more of. I don't want to say
Speaker 4: that we've we've kind of necessarily completely solved that problem
Speaker 4: or we found a way of anticipating all of those issues,
Speaker 4: you know, ahead of time. My hope is that by
Speaker 4: improving our code view process and gradually pushing, as you say,
Speaker 4: more of this thinking earlier on in the process, it
Speaker 4: will gradually become more ingrained in the way we work,
Speaker 4: and we can and we can we can get better
Speaker 4: at anticipating those things earlier on. But yeah, I mean,
Speaker 4: I think from my point of view, the truth is
Speaker 4: that some of those things will will still get missed,
Speaker 4: and we need the code of view stage to sort
Speaker 4: of really just double check that we've we've not neglected
Speaker 4: any of those areas.
Speaker 6: Yeah, I think I guess my thinking of that is
Speaker 6: definitely not to preempt the code review, because, like you said,
Speaker 6: that is kind of the last stage, and it's I
Speaker 6: think it's important regardless. I think it's just more around,
Speaker 6: you know, kind of increasing that collaboration early on, particularly
Speaker 6: in a remote context. What I've seen in some teams
Speaker 6: is developers will kind of get lost in whatever they're
Speaker 6: doing and they'll forget to communicate because, you know, communications,
Speaker 6: it doesn't come naturally at all developers, right might be
Speaker 6: a stereotype or personality type, but it is what it is.
Speaker 5: And so I think having that kind of sharing.
Speaker 6: And communication built in earlier on can help with the
Speaker 6: types of situations where a developer works on something, implements something,
Speaker 6: and then maybe it's very technically clever, but during the
Speaker 6: review phase we find out that, oh, actually it doesn't
Speaker 6: quite do what it needs to do, and or those
Speaker 6: kind of things.
Speaker 5: So I think there's there's an opportunity there.
Speaker 6: To move some of that to the forefront as well,
Speaker 6: and just to work better in a remote context.
Speaker 2: Yeah, I think you're absolutely right kind of.
Speaker 4: And one of the ways that we one of the
Speaker 4: ways I think this affectsed US sometimes was we noticed
Speaker 4: when a certain code review had maybe been more taxing
Speaker 4: or more time consuming that it might than it might
Speaker 4: have been expected to be, or or that issues were
Speaker 4: only found out at the code review stage, which were,
Speaker 4: for example, quite significant architectural issues, things that should have
Speaker 4: been anticipated much earlier on, and we wanted to try
Speaker 4: and use use those insights that we got from the
Speaker 4: code of view process to try and improve the earlier
Speaker 4: stages further left than our process for the for the
Speaker 4: next iteration. So when we have team retrospectives and things
Speaker 4: like that, we'll often try and talk about code reviews
Speaker 4: that were difficult or issues that only came out and
Speaker 4: code reviewed that really could have been discussed or you know,
Speaker 4: would have benefited from more communication or more collaboration earlier
Speaker 4: on in the process. And I think that is actually
Speaker 4: quite a helpful technique, because sometimes I think there's a
Speaker 4: temptation you think, right, the code reviews finished, let's ship
Speaker 4: the code, let's forget about it and move on, And
Speaker 4: often you can actually look at the code of view
Speaker 4: and say, you know what, what have we learned from
Speaker 4: this that we could have, what insights we take away
Speaker 4: from this that we could actually apply earlier on in
Speaker 4: the development process next time we go through this cycle.
Speaker 5: I really love that being because I think what you're
Speaker 5: what you're.
Speaker 6: Describing is you know, a continuous improvement, which is a
Speaker 6: huge part of the DevOps philosophy. And b you're describing
Speaker 6: a feedback where you're doing something and then take the
Speaker 6: data you've gleaned from that process and improving your process
Speaker 6: as you go. So I think that's really that's really fantastic,
Speaker 6: and you know, I can really see how that ties
Speaker 6: into kind of the overall develops philosophy.
Speaker 1: So one thing that I'm wondering about because you talked about,
Speaker 1: you know, sometimes the review process might take longer than
Speaker 1: it should have, or that you might have wanted it
Speaker 1: to and things like that, and that made me think,
Speaker 1: and it's a question that you actually, you know, put
Speaker 1: up that might be a good when to ask. And
Speaker 1: I'm kind of curious, I mean, are there downsides to
Speaker 1: a code review process or or maybe downsides to a
Speaker 1: bad code review process? Maybe that's a better question. I
Speaker 1: don't know, are there are there reasons that you wouldn't
Speaker 1: want to do this or ways to avoid problems while
Speaker 1: you're trying to do this.
Speaker 4: I think for us, the real goal was to we
Speaker 4: knew that code reviews were something we wanted to do,
Speaker 4: and we had this attachment to doing them, but we
Speaker 4: wanted to be able to clearly explain to ourselves and
Speaker 4: to the non engineering parts of the organization why could
Speaker 4: views exist and what they're for, and have a better
Speaker 4: understanding of what they're for. So I think that's a
Speaker 4: useful exercise because you know, in the past we had
Speaker 4: a situation where, you know, maybe something would take quite
Speaker 4: a long time to get through a code review, and
Speaker 4: product managers or product owners might say, well, what's happening?
Speaker 2: Why you know what's happening in this code view process?
Speaker 2: Why are we doing it?
Speaker 4: And hopefully what we have now is it is a
Speaker 4: better set of answers for that and more of a
Speaker 4: shared understanding. The downsides, I think I can't see any
Speaker 4: downsides really about kind of reflecting on code reviews. I
Speaker 4: think I think reflecting on every stage in your development
Speaker 4: process at some point is going to give you some
Speaker 4: you know in that in that same spirit of continuous
Speaker 4: improvement is going to give you the opportunity to do
Speaker 4: things better or work smarter, or avoid pitfalls in the future.
Speaker 4: So I think reflecting on the process is a for
Speaker 4: us has been a really powerful way of of kind
Speaker 4: of getting more understanding of our process. But you know,
Speaker 4: code of views a it can be really complicated and difficult,
Speaker 4: and things do still go wrong. You know that there
Speaker 4: are situations where code views don't go as as we'd like,
Speaker 4: but it's something that we're constantly trying to work on.
Speaker 4: We didn't want this to be a thing where we
Speaker 4: just write a document about code reviews and then said, Okay,
Speaker 4: we're done, We've solved the problem of code views. We're
Speaker 4: going to move on. We wanted it to be something
Speaker 4: that we could keep on building on. We put it
Speaker 4: in our one of our open source repos so that
Speaker 4: it's kind of it's fronts and center that people outside
Speaker 4: the organization can see it, and we keep on iterating
Speaker 4: on it and adding to it and changing it as
Speaker 4: we get more, as we learn more about what works
Speaker 4: for us or what doesn't work for us. You know,
Speaker 4: anybody can do a poor request against it and say, hey,
Speaker 4: this technique really worked for me in when I was
Speaker 4: learning to do code reviews, and then it becomes something
Speaker 4: that can benefit other people in the future.
Speaker 1: So I guess kind of a follow on to that
Speaker 1: then is let's say that we've got a devaps team
Speaker 1: out there, right, and they've got you know, a set
Speaker 1: of tools and processes and people that use them and
Speaker 1: people that rely on them. Right, And some of this
Speaker 1: is codified in code, right, you know, be it Bash
Speaker 1: scripts or you know we talked about chef or I
Speaker 1: mean whatever, right, and some of it may be codified
Speaker 1: in just you know, a process that people follow for stuff.
Speaker 2: Right.
Speaker 1: I could see a code review being just as useful
Speaker 1: for that, right, But you know, whatever it is. Let's
Speaker 1: say that they're listening to this and they're going, you know,
Speaker 1: this is a really good idea. We should definitely have
Speaker 1: people looking over you know, what we're putting down as
Speaker 1: the way that we get this work done, right, be
Speaker 1: it you know, formal programming code or you know scripts
Speaker 1: or whatever, or yeah, even just you know, hey, do this,
Speaker 1: then do this, do and do this and do this. Right,
Speaker 1: How should they start implementing that if they haven't been
Speaker 1: doing that today.
Speaker 4: Well, I mean, the first thing to say is there's
Speaker 4: lots of great resources out there already, So it's not
Speaker 4: that the article that I wrote is kind of summarizing
Speaker 4: a process that we went through to think about code
Speaker 4: of views. But there's a lot lot of great advice
Speaker 4: online about code reviews, and if you google code review
Speaker 4: best practices and guidelines, there's loads of loads of articles
Speaker 4: out there, and I linked to a couple of them
Speaker 4: in the article. Some teams might find that the information
Speaker 4: in those resources is a good fit for them. So
Speaker 4: you might read I think it's gaily as post which
Speaker 4: was a big inspiration for me about code reviews, and
Speaker 4: you might say, well, that's actually a perfect description of
Speaker 4: high I want my code reviews in my team to work.
Speaker 4: So we're just going to say this is our process,
Speaker 4: We're just going to follow this. For us, it was
Speaker 4: a little bit different because we felt that we had
Speaker 4: there was lots of specifics about how we worked in
Speaker 4: our organization, our specific technical stack, how our continuous integration,
Speaker 4: because the r delivery process has worked, how we used
Speaker 4: githubs specifically in our teams. We wanted to have something
Speaker 4: that was a bit more tailored to our process. So
Speaker 4: I would say decide if any of the existing online
Speaker 4: resources is a good fit for you.
Speaker 2: If it is, great, use it.
Speaker 4: If not, then you might want to go through the
Speaker 4: process that we went through and actually come up with
Speaker 4: a guide yourself. But you know that a lot of
Speaker 4: this information is not and these and these pieces of
Speaker 4: advice is not brand new. You know, it's kind of
Speaker 4: it's it's it's wisdom that's kind of been going around
Speaker 4: for a few years. So it's a question of picking
Speaker 4: out the things that make the most sense to you
Speaker 4: and are most relevant to you, know, your team, the
Speaker 4: structure of your organization, the technology you're working on, and
Speaker 4: then have somewhere for developers to find that information so
Speaker 4: you know and get help. You can obviously have pull
Speaker 4: request ten plates you link to a document with these
Speaker 4: guidelines and bits of advice that you want them to follow.
Speaker 4: And I think the other part of it is, as
Speaker 4: I said, just to just to keep on reviewing that
Speaker 4: process and reflecting on it in the future. You know,
Speaker 4: if you see how it goes and try it for
Speaker 4: a few sprints, or try it for a few months,
Speaker 4: and then have a look at the process again, see
Speaker 4: if it's working and see if it needs any changes.
Speaker 4: The other thing I would say is one thing that
Speaker 4: really helped us was about in terms of reducing the
Speaker 4: burden of code reviews was to try and automate anything
Speaker 4: that you can.
Speaker 2: So I know, one code.
Speaker 4: Base that I worked on for a little while, a
Speaker 4: lot of the pull requests would we would have a
Speaker 4: lot of comments where people were just changing bits of
Speaker 4: white space or semicolons or minor formatting issues, which we're
Speaker 4: all completely valid, but you know, robots are much better
Speaker 4: at those kind of code reviews. You know, if you've
Speaker 4: got linting tools available for whichever your whichever technical environment
Speaker 4: you're using, use those instead, you know, apply automatic formatting,
Speaker 4: to use automation so that when people are doing code
Speaker 4: views they can focus on the stuff that really matters.
Speaker 4: So yeah, and also, as we already said, I think
Speaker 4: pairing and mob programming can be a really good way
Speaker 4: of making code of views less difficult.
Speaker 6: Is your guide to code reviews? Is that public or
Speaker 6: is there any plan to make it public?
Speaker 8: I think a lot of people would be very interested,
Speaker 8: especially in an organization as large as the BBC AD
Speaker 8: as well respected as the CBC and understanding you know
Speaker 8: kind of how you guys do it and actually seeing
Speaker 8: maybe maybe the full the poor guide if that's something
Speaker 8: you guys are thinking about releasing or already have.
Speaker 2: Sure, Yeah, it's actually already Sorry, go ahead.
Speaker 1: I was going to say, I want to pile one
Speaker 1: because you brought up linting a minute ago. And we
Speaker 1: do that, right, We pull in the linking setup from
Speaker 1: some other company, right that they published, and then we
Speaker 1: say we're going to use their linking strategy, accept this
Speaker 1: and this and this, and yeah, I'd love to get
Speaker 1: the BB season and say.
Speaker 2: That doesn't apply, that doesn't apply.
Speaker 1: We're going to add this, this, this doesn't quite work
Speaker 1: for us, but something similar and yeah, and then I
Speaker 1: spend half the time putting it together and I look
Speaker 1: really smart.
Speaker 2: Yeah, we all have a bunch of those. We have
Speaker 2: a bunch of those as well.
Speaker 4: You know, other other company style guides that we've we've
Speaker 4: we've followed and incorporated into the way that we work.
Speaker 4: And I think you know that's that's the great thing
Speaker 4: about open source collaboration is you can reuse work that
Speaker 4: other people have done. A code of view process is
Speaker 4: obviously harder to you know, run automatically than a Linter.
Speaker 4: But the guide that we wrote is publicly accessible. I can,
Speaker 4: I can share the link with you and your listeners,
Speaker 4: and it's out there. It's in one of our open
Speaker 4: source repos because the project that we developed it for
Speaker 4: is an open source project itself, so we wanted to
Speaker 4: put it in the read may say, look, this is
Speaker 4: how we do code reviews. If you're going to submit
Speaker 4: a poor request to this project, this is what you
Speaker 4: can expect is how we're going to approach our code reviews.
Speaker 2: So yeah, it's.
Speaker 4: Already out there, and we'd really welcome people's comments on it,
Speaker 4: pull requests on it, and just get more feedback from
Speaker 4: and if people find it useful in their organizations and
Speaker 4: they want to just link to it and say, hey,
Speaker 4: this is the approach we're following, then we'd love to
Speaker 4: hear about it.
Speaker 1: Yeah, that'd be great if you put it in the
Speaker 1: chat in zoom, then we can add it to the
Speaker 1: show notes.
Speaker 2: Any other questions you guys before we got to picks.
Speaker 1: Nothing on my side, anything we forgot to bring up
Speaker 1: that you wanted to talk about.
Speaker 2: James, No, nothing from me. I think yeah, we've covered.
Speaker 1: Everything, all right, Well, let's go ahead and dive into
Speaker 1: picks then. Now, James, I don't know if you've listened
Speaker 1: to the show, but picks are is the segment at
Speaker 1: the end of the show where we talk about stuff
Speaker 1: that we like. So it's just anything that we really
Speaker 1: want to shout out about. I'll let Jeffery go first
Speaker 1: since he's kind of a little more experienced of this.
Speaker 1: Then we'll have Caleb go and then I'll throw out
Speaker 1: some picks and then we'll let you share what you
Speaker 1: want to shout out about.
Speaker 7: Well, so I'll you know, talking about just pick I've
Speaker 7: got for this week. Is an interesting trying to leave
Speaker 7: called it.
Speaker 3: It's really a learning platform called Learnistic, and it is
Speaker 3: a I mean, this is where there's a field full
Speaker 3: of all these different platforms for building like whether it's
Speaker 3: like actual formal courses you're trying to provide or just
Speaker 3: you know, sort of video.
Speaker 7: Or audio content.
Speaker 3: Right, there's a lot of different ways to do this,
Speaker 3: but I found that Learnistic has a really interesting platform
Speaker 3: where what you're trying to do is get your content
Speaker 3: out there to your audience's mobile app, you know, mobile
Speaker 3: devices through a mobile app. They are doing it, so
Speaker 3: you can basically create a custom app for you know,
Speaker 3: your company, or your podcast or whatever is that you do.
Speaker 3: It goes under it sort of bundled under the Learnistic app,
Speaker 3: but it's it becomes a separate app underneath that.
Speaker 7: So it's sort of interesting.
Speaker 3: And they give you a lot of control as a
Speaker 3: content developer to publish what content you want for each
Speaker 3: individual user. So what shows up for eachooser is going
Speaker 3: to be a little bit different based on you know,
Speaker 3: how they have their access control set up. So it's
Speaker 3: a really interesting and what they're doing for you is
Speaker 3: basically taking care of all of the sort of bits
Speaker 3: and pieces that make all that work. So it's it
Speaker 3: really is a pretty robust platform. I'm starting to look
Speaker 3: at it, starting to use it for just in my
Speaker 3: practic how I provide content. Sometimes it is course courses
Speaker 3: that are customed for specific clients. Sometimes it's just you know,
Speaker 3: sort of you know, content that I just want to
Speaker 3: provide to either you know, all my sort of audience
Speaker 3: and prospects and clients and you know, just everyone. And
Speaker 3: it's a really like I said, what I've done so
Speaker 3: far is it's really cool way, really efficient way and
Speaker 3: cost efficient as well, just to get your content out
Speaker 3: there to the folks that.
Speaker 7: You want to get into.
Speaker 3: So yeah, it's well, they're doing something interesting that's a
Speaker 3: little bit different from all of the other like learning
Speaker 3: platforms that exist.
Speaker 2: Nice.
Speaker 1: Now I want to go check it out. Yeah, I've
Speaker 1: been using Teacha ball. I'm pretty happy with it. But yeah,
Speaker 1: I'm always on the lookout for something new that might
Speaker 1: give me a little bit of an edge on yeah,
Speaker 1: just getting people what I want to give them. So anyway, Caleb,
Speaker 1: what are your picks?
Speaker 6: Yeah, so my pick for the week is a tool
Speaker 6: called Harness. You can find it at harness dot io.
Speaker 6: It's a pretty established player in the devop space. I've
Speaker 6: used it before, but recently I was kind of looking
Speaker 6: at how in a new organization, how we can get
Speaker 6: things like Canary deployments going blue green deployments.
Speaker 5: How do we manage you know, if.
Speaker 6: We need to deploy interdependent services together, how do we
Speaker 6: track that, you know those kind of things. And so
Speaker 6: I was able to go through a demo the tool
Speaker 6: recently and start looking at implementing it again, and it
Speaker 6: just kind of brought it back the top of mind
Speaker 6: for me and a it is actually better than it
Speaker 6: ever was.
Speaker 5: So when I use it a few years ago. It
Speaker 5: was good.
Speaker 6: It's gotten even better, and I think that's something that
Speaker 6: a lot of teams are missing as kind of a
Speaker 6: developer self service platform for handling. You know, how do
Speaker 6: we deploy to these different platforms, how do we kind
Speaker 6: of track that, get visibility across the organization, how do
Speaker 6: we kind of implement standard workflows and things like that.
Speaker 6: So this is a really really interesting tool does what
Speaker 6: it does really well.
Speaker 5: It's a little more on the enterprise.
Speaker 6: Side of the DevOps sort of tooling space, so probably
Speaker 6: not for tiny startups, but if you are at the
Speaker 6: point where you're scaling and you're running into issues like
Speaker 6: standardizing deployments, trying to scale ups and let developers kind
Speaker 6: of self service deployments and define their own workflows and
Speaker 6: those kind of things, it's very worth looking into.
Speaker 2: Awesome.
Speaker 1: I'm going to jump in here with a few picks,
Speaker 1: just making sure I'm not muted. I'm going to jump
Speaker 1: in with a few picks, so I do want to
Speaker 1: shout out about dev Influencers. I'm not going to go
Speaker 1: into too many more details than I went into at
Speaker 1: the beginning, but you can get the podcast at dev
Speaker 1: Influencers dot com a's Dev Influencers with an s dot
Speaker 1: com slash podcast, you can also apply for the Accelerator
Speaker 1: Dev Influencers dot Com Slash A reply and I've been
Speaker 1: helping people get their podcasts started and build an audience
Speaker 1: so that they can build a career.
Speaker 2: In the future that they want. And I'm I'm really
Speaker 2: really enjoying it.
Speaker 1: I just I did not realize how much fun helping
Speaker 1: people like coaching direct coaching is and I just I love, love,
Speaker 1: love love doing it. So and I've been recording videos
Speaker 1: and putting them up on teachable So that's that's where
Speaker 1: the teachable mention comes in a few other picks. So
Speaker 1: I don't know how things are in other parts of
Speaker 1: the US, but here in Utah things are pretty much
Speaker 1: opening up. The mask mandate lifts for everything except schools,
Speaker 1: and I guess certain spaces with certain numbers of people
Speaker 1: where you can't social distance, But for everywhere else, the
Speaker 1: mass bandate lifts. In like three days, my wife and
Speaker 1: I actually went on a date and we went out
Speaker 1: to a movie. We were like two of the four
Speaker 1: people in the movie theater watching the movie, but we
Speaker 1: really really enjoyed it.
Speaker 2: It was called the Career.
Speaker 1: Has Bennetett Cover Badge in it.
Speaker 2: It's a spy movie.
Speaker 1: Now, before you get all excited like James Bond, No,
Speaker 1: in fact, I have to tell this story because it's
Speaker 1: pretty funny. So my wife and I we were walking
Speaker 1: out of the theater. I was waiting for her outside
Speaker 1: the restroom, and the girls who were sitting in like
Speaker 1: three rows behind us were walking out and one of
Speaker 1: them goes, did you like it? And the other one goes, yeah,
Speaker 1: it was okay, And she goes did you like it?
Speaker 1: And the other girl goes, yeah, well it was okay.
Speaker 1: But I was kind of expecting more of a James
Speaker 1: Bond movie. And I'm sitting there thinking to myself, you
Speaker 1: didn't watch the trailer, did you? Because the trailer it's
Speaker 1: very obvious it's a Cold War spy based on a
Speaker 1: true story kind of thing, right, and so it's going
Speaker 1: to be about tradecraft. It's not going to be about
Speaker 1: somebody jumping through windows and shooting guns. Sorry, but I
Speaker 1: really enjoy some of the historical contexts that some of
Speaker 1: these films have brought up.
Speaker 2: Yeah.
Speaker 1: I know they take some license right to make the
Speaker 1: film more interesting, but you know, generally I find that
Speaker 1: mostly they stick to the facts on most of these films.
Speaker 2: You just don't have to go check. Right.
Speaker 1: But this guy, he was a salesman in Great Britain,
Speaker 1: and the British were still allowed to do business with
Speaker 1: the USSR in the sixties, and so he opened up
Speaker 1: accounts and was selling machine parts to the Soviets in
Speaker 1: Moscow in the nineteen sixties, and six recruited him on
Speaker 1: behalf of the US to carry intelligence back. And so
Speaker 1: this official in the USSR winds up becoming a trader
Speaker 1: to the USA and he's feeding them all this information
Speaker 1: and some of it like you see it and you're like,
Speaker 1: that's how they knew about that. Oh, that's how they
Speaker 1: knew about this. So it was really really fascinating. But yeah,
Speaker 1: so he would just pass it off and this guy
Speaker 1: would just take it away, and I never knew what
Speaker 1: was in a lot of it, right, And anyway, it's
Speaker 1: a terrific film, and it's really fascinating because you're spending
Speaker 1: the whole times that they're going is he gonna get caught?
Speaker 1: And yeah, anyway, I'm not gonna spoil the end of it.
Speaker 1: I have no spoilers policy. If it's been out less
Speaker 1: than a year. In this movie has been out less
Speaker 1: than a year, so go watch it. It's terrific. He
Speaker 1: does such a terrific job too, because you kind of
Speaker 1: see him in a lot of these other movies as
Speaker 1: kind of this svelt kind of action figure, and you know,
Speaker 1: he's been a at coub badge and so he's he's
Speaker 1: in shape, but he definitely pulls off playing the kind
Speaker 1: of normal, friendly, jovial salesman guy who you know isn't
Speaker 1: the action figure that's going to go in save the Day.
Speaker 1: So I loved it, absolutely loved it. And so yeah,
Speaker 1: that's the courier if you're out looking for a movie
Speaker 1: to go watch.
Speaker 2: James, what are your picks?
Speaker 4: Okay, so my pick is about diagrams. I've been thinking
Speaker 4: a lot about diagrams recently, and a large part of
Speaker 4: my work at the moment is trying to make sure
Speaker 4: we've got architectural diagrams for some of the projects we're
Speaker 4: working on.
Speaker 2: So my pick is, well, it's not new.
Speaker 4: In fact, it's really old, and I'm sure a lot
Speaker 4: of people are already aware of it.
Speaker 2: But there's a particular.
Speaker 4: Website that I found recently, So plant mL is a
Speaker 4: tool that you can use to generate diagrams. Some people
Speaker 4: may already be aware of it. I only discovered it
Speaker 4: fairly recently, but I found a website called real World
Speaker 4: plant mL, and it gives some examples that make it
Speaker 4: much easier to see some of the things that's possible
Speaker 4: to do with plant mL. For those who are thinking, oh,
Speaker 4: I don't want to do UML diagrams, it actually generates
Speaker 4: lots of different types of diagrams, not just UML diagrams,
Speaker 4: and we're using it quite a bit of my work
Speaker 4: for creating threat models for some of our services. One
Speaker 4: of the benefits of you plant YOUML rather than another
Speaker 4: diagramming tool is that you actually write the diagram in
Speaker 4: a textual format and then it generates the graphics from
Speaker 4: that for you, which means you can keep the source
Speaker 4: of the diagram in version control. People can do pull
Speaker 4: requests against it and that kind of thing. Anyway, this website,
Speaker 4: real World plan YOUML, is really helpful because the syntax
Speaker 4: can sometimes be a little bit forbidding if you're not
Speaker 4: used to it, and it shows you some examples of
Speaker 4: what can be achieved with it and how you can
Speaker 4: achieve it. So that's been I've been copying quite a
Speaker 4: few things from that recently just to help with making
Speaker 4: my diagrams.
Speaker 2: Awesome, very cool.
Speaker 1: All right, well, before we wrap up, I'm assuming that
Speaker 1: people can find you online. Looks like you published a medium,
Speaker 1: so if you want to let people know where you
Speaker 1: do that, and then if you're on GitHub and Twitter
Speaker 1: and places like that, if you can let people know
Speaker 1: where you are there too, that would be great.
Speaker 2: Sure.
Speaker 4: Yes, So my username on Medium on Twitter is well
Speaker 4: my name without the ue at the end, so it's
Speaker 4: James Donald jam s d O n oh and the
Speaker 4: same one get hub as well, so you can find
Speaker 4: me that same on Twitter.
Speaker 2: Cool. Well, thanks for coming, This was fun, Thanks for
Speaker 2: having me. It's been great. All right.
Speaker 1: Well we'll go ahead and wrap up here and until
Speaker 1: next time, folks, max out.