03:42 - Derek Prior Introduction

04:01 - Code Reviews

05:14 - What happens when you don’t do code reviews?

06:30 - Not Emphasizing Code Quality, Setting Code Review Up for Failure

10:43 - Code Reviewing Yourself: Answering Your Own Questions

12:03 - The Evolution of Code Review (Code Review as an Asynchronous Process)

14:51 - Small Changes, “Pull Request Bombs”

23:49 - Making Code Review a Supportive Process

30:32 - What qualities should reviewees have?

34:27 - Getting Code Reviews Introduced Into Company Culture

38:30 - Making Sure Code Reviews Get Done

40:47 - Tagging Specific Team Members

44:39 - Other Handy Code Review Tools

47:49 - Code Review Feedback Resources for Solo Programmers

Picks

Code Newbie Podcast: Sandi Metz Part I (Saron)
Code Newbie Podcast: Sandi Metz Part II (Saron)
If Google Were A Guy (Saron)
LEGO Ideas - Lovelace & Babbage (Coraline)
CoverMyMeds is offering Ruby on Rails training for experienced developers (David)
CoverMyMeds Billboard 1 (David)
CoverMyMeds Billboard 2 (David)
The Bike Shed Podcast (Derek)
The Ember RFC Process (Derek)
tota11y (Derek)
Eileen Uchitelle: How to Performance @ GoRuCo 2015 (Derek)
Olympus SP-100EE (Avdi)

Special Guest: Derek Prior.

 

I’m not dressed. I’ll be right down.

All right, so who exactly do we have today? So we have Saron. We have Coraline and maybe David.

Maybe he was serious. Maybe he does have to get dressed to come out.

Somebody needs to tell him how the internet works.

[Laughs] No, it’s much funnier this way.

Welcome to the Ruby Rogues podcast. This is episode 216. On our panel today, we have Coraline Ada Ehmke.

Hello from Chicago.

Saron Yitbarek.

Hey everybody.

David Brady.

Hey, so normally I do a joke here but I need to do an announcement. But I have to do a joke here. So, CoverMyMeds has put up the world’s largest Ruby logo. Are we compensating for something? Come work for us to find out. We are looking for a Java and .NET programmers now to come learn Ruby. I’ll talk more about that in the pick. Those of you who listen to the show that don’t do Ruby, you know who you are and those of you who listen to the show that turn the show off before the picks, you know who you are. Listen to the picks.

Well done.

I saw a picture of the poster and made me want to learn Ruby.

It’s monstrous.

Well, joining us today is a special guest, Derek Prior. Derek, would you mind introducing yourself for a moment?

Sure. I’m a developer at thoughtbot here in Boston. I also co-host The Bike Shed podcast which is a technical podcast about Ruby on Rails, JavaScript, whatever it is we’re doing that week with my friend, Sean Griffin.

I love that show.

Oh great! Good to hear it. The reason I’m here today is at RailsConf, I gave a talk about code review cultures and how to do code reviews well and what you can get out of them when you do them well. What code reviews are good for and what they’re not good for, et cetera, et cetera. So I think that’s probably why I’m here today.

So code review, is that the sort of things that we stopped doing when we started pair programming, right? [Laughter]

Exactly. Code reviews mean a lot of different things to some [inaudible] different people. There are people who have been doing development for a long time for whom code review means like you’re getting the room. You put the code on a projector and you go through every change in the release kind of thing. That’s not what I’m talking about.

I’m more talking about a modern process. Modern code review isn’t really my term but it is actually a term referring to reviewing a change asynchronously with some sort of automated tool. In our case, it’s like GitHub pull request reviews would be what most people are familiar with, I think.

People ask all the time, do we need to review code if I’m doing pair programming? And I think the answer to that is yes. I think those are different practices. If you only have two people on your team and you paired on it, obviously it’s difficult to get a review. But having a third person review that wasn’t involved in that entire – the thought process that led to your solution, right? So if it stands on its own alone from the process that led you down that path.

Derek, what happens when you don’t do code reviews?

Yes, what happens when you don’t do code reviews? I’m in a situation right now where I am the only developer on the project. I can sometimes pull in some of my thoughtbot co-workers to review changes. But I have to make a decision about whether or not I want to bother them with this particular change or not. So what happens when you don’t do code reviews?

First of all, there is an element of quality that you can get out of a code review. I try not to stress that and actively avoid stressing that. So that’s one thing you do miss out on but that’s lesser, I think. The bigger thing is that you are now the only one that’s familiar with the change that you introduced. So you don’t have that knowledge sharing benefit that comes from doing code reviews with everybody where you’re going to get like somebody else might have a different take on the problem or may have some additional background that wasn’t previously exposed, some information about the problem that you’re not aware of. Or you might be able to, just by showing the code to somebody else, you’re making them familiar with it. So that if there’s a problem with that next week when you’re on vacation or you’re working on something else and you really don’t want to step back to revisit this code you wrote last week. Everybody’s familiar with those types of solutions. There’s also a great benefit that come out of doing code review that aren’t entirely clear just from everybody focusing on – we’re going to find bugs on this code review process, that kind of thing.

I’m interested why you don’t want to emphasize the difference in code quality that you get when you do code reviews because to me that seems like the most obvious thing. Why is that not the big thing for you?

It is an important thing. So when you’ve done code review on code, it’s going to have fewer defects.

But there are a couple of problems I see with that. The first is that if you tend to look at code as a way that people – if code review is a way of like – I submitted code review, people are going to find the bugs with it, it’s easy for you to view code review negatively as like a thing where people are going to comb through your stuff and find where you did everything wrong. That was actually my experience from many years doing code reviews because I drive them.

Why would you view that negatively?

Because I feel like it’s a judgment. It’s easy. I feel this way and I know other people do too. That it can be seen as a judgment on your skill as a developer.

Ah okay, because it’s on you. It’s on you.

Right.

I guess I’m just a freaky weirdo but we all knew this. But I love having people destroy my code. I learn so much. I guess I’ve just been really lucky that every time I’ve gone through this even just like a total 75 WTFs per minute meat grinder code review, I’ve always felt like everybody in the room was on my side of the table trying to make the code better.

Yes, and I think that’s true for some people and not true for other people. I need to be careful with that, right. Some people just feel really piled on. Particularly if you’re somebody new to a team and you get 75 comments on a pull request.

Yes, that’s fair.

That is certainly part of it. So when you find a bug in a code review, you need to point that out.

The other reason why I think that we’re setting ourselves up for viewing code review as a failure if we stress finding bugs too heavily is that particularly with these asynchronous pull request type reviews, we’re looking at a small slice of a change. If you make a change to do some object in your system and there’s some unit test for it, you’re like, “All right, great. This seems to make sense.” But unless you know entirely how that system’s going to interact with the change you just made, what I’m trying to say I guess is you can make micro-level judgments on the quality like this line looks correct. But knowing how the entire system interacts requires you to know a lot about the application. As applications grow, that’s harder than necessarily know right off the bat.

So you can judge it in individual change looks good based on the lines that you see but not necessarily interactions. That’s why I think particularly in languages like Ruby, task coverage is really important to catch those. So code review is going to help you I feel like more get towards the right solution, in a more interesting solution, a more flexible solution, that type of thing than it is going to catch a bug. What we tend to catch in code reviews are edge cases and studies have actually shown this. Edge cases are interesting but they’re not the truly dangerous stuff.

Are you talking about stuff where someone says, he’s looking at your code and they say. “Well, what if XY happens?”

Right, what if this is new? What if I pass you something that’s new? And it’s like oh well under ordinary circumstances, that wouldn’t happen but yes, you’re right. Okay, I can guard against that. That’s important. That’s a bug that’s caught and now you can address that. But those tend to be edge cases that they’re going to come up but they’re not the type of thing that’s going to take the entire system down, generally or that lead to corrupt data, that kind of thing.

So I imagine that with larger systems, too, it’s harder for one person to hold the system in their head. So having a group of code reviewers maybe who have different familiarities with how different interactions take place that will be a benefit as well?

Right exactly. So everybody has different familiarity with the system. And also everybody has different takes on how they think something should be done or different expertise around, like maybe I’m really good at SQL performance stuff and I can tell you how to write that query better. Coraline, you’re really good at web security and you saw that I was doing something interesting with Brands that was probably not quite right and you can give that kind of feedback. So having the whole team give varied and diverse feedback is interesting.

That’s where in the talk, I talked about having a conflict on the team is good. If you’re not having any conflict, you’ve got this model culture where everybody is doing things the same way all the time. What you really want is a diversity of views and that’s going to lead to some conflict on how you approach different problems but that’s for the overall greater good.

There’s another, I guess for me at least, value to code reviews which is that when I am doing something just on my own for a side project that no one’s going to look at but me, I just solve the problem and I move on. When I’m working on something that I know I’m going to get feedback on, I know is going to be reviewed, I can perceive the questions that my peers will ask and I’ll ask myself that and then it’ll inform my code. Do you know what I mean?

So it’s a difference in code quality that I notice in myself, not so much in terms of finding its crushing bugs, but as in terms of okay if I put this in and then Derek is going to wonder why I did this. Why didn’t I do this? It leads me down this thought process that I wouldn’t get to if didn’t know what was going to be code reviewed. Have you experienced anything like that?

Yes, that’s very well said. I think that’s the exact experience I have when I’m writing code and preparing it for a review is I’ll take one last look at the diff and I’ll be like oh I feel like somebody’s probably going to ask me why I did it this way, right.

Hmmm.

I have to answer myself either do I have a good answer for that? If I do, let’s go ahead and put that right in my pull request or in my commit. So that they’ll read that and then they don’t have to ask me because I explained it. If I don’t have a good answer for that, why not? Is it something I should address now or is it something I feel like we should address later? Either way, I’m going to address that in my pull request immediately, upfront. Or I’m just going to fix it, that type of thing.

Exactly.

When I was introduced to code reviewing, it was typically this thing where we would get together in a conference room and somebody would put the code up on the wall. And you go down through it at the same time. But it sounds like you’re talking more about an asynchronous process. Do you prefer that asynchronous process?

Yes, I do. I’ve done the everybody-in-the-room kind of thing. I feel like that’s effective in short bursts. It’s also instructive like I have also been more recently involved in teams where somebody will – a particularly interesting change from the last week that’s probably already been merged frankly but let’s go through it. Let’s see how they did this really interesting, how they solve this interesting problem. That’s like a tour of already completed code that’s like a code review. But I have done the once a week or once a sprint or once a release cycle. We’re all going to get in the room and we’re going to put it up on the projector and we’re going to go through line by line. I found that that got really boring really quickly.

Yes, I always had trouble staying away for those.

Yes and everybody is waiting on somebody. In those meetings, somebody tends to take the lead and that person is the one’s that commenting on everything and the people who are a little more tentative are just like well, someone else’s handling this so I’ll wait for them to say, see if he covers what I’m going to say or whatever.

Right.

So I feel like the asynchronous thing works well. Also, one of the things I stress in the talk is the importance of realizing that because these are asynchronous, you’re asking something of the people that are going to review them. You’re asking them to take a minute out from what they’re doing or take five minutes or whatever from what they’re doing to look at your change. So the things I say when you’re preparing your change for somebody to look at that you really want to do is keep them small, first of all, so that they’re easy to review and easy to keep track of what’s going on in this change.

More importantly, also provide as much context about the change as you possibly can because a lot of times, you’ll end up I’ll be working on client projects and I’ll get this giant PR that just has a link to a ticket or maybe not even that, just like a summary. The summary is just like a restatement of exactly what was done in the code and not necessarily why this is changing. So without knowing why something’s changing, it’s really difficult to discern whether or not there’s a better way to go about it or even really learn something from the change.

If all I do in my change is essentially translate the code into pseudo code, if all I do in my change description is that, there’s a really missed opportunity I feel. So those are the things that I think where you’re doing asynchronous pull request reviews are particularly important. Make sure you’re sharing as much context with everybody as possible. And keep them small. I say in the talk also 10 minutes will be a really long time for me to spend in that code review and naturally like five minutes is probably the max I actually want to spend on the code review.

And there’s also more interesting changes that have to be big for some reason or another are going to require more than that. But as a rule, five to ten minutes is probably my max on a code review.

I think the small changes that’s so important, I’ve talked about something called that I call Pull Request Bombs where you have a single pull request that changes 500 lines of code. There’s that old joke that with the thin line code review, you get 10 comments; with 500 lines, you get no comments at all.

Yes, I made a reference to that as well. With larger changes, what you see is either like you said there are no comments because nobody wants to wait in Twitter like you badger enough people that somebody’s going to finally look at it. They look at it and they start at the top and they have a few comments. And they scroll all the way to the bottom and there’s a comment and nothing in the middle. I fulfilled my responsibility. I looked at some of these that kind of thing.

And like I said some changes are really difficult to make small. If you have a larger refactoring and you can’t make that small without committing a broken app. So what I tend to suggest there is that you actually take some very small commits stops that can be consumed as one chunk and reviewed as one chunk. And yes, like some other part of the app is broken after this commit but in you pull request, you’re going to submit something where all the tests are green. You need to commit, you’re going to step along the way like tell a story with each one of those commits. So that in that case whenever we have a pull request like that, or if I’m submitting a pull request like that, I would say like this is a really large refactor. Your best bet is to step through commit by commit. Unfortunately on GitHub, commenting on commits is not as nice as commenting on the actual pull request for various reasons but it still is going to make a better experience for everybody I think if you take that story approach with each commit in those cases.

I have an allergic reaction to committing code where the tests break. It just makes my teeth itch. But I would be fine co-existing in an environment where we did that but I would be strongly tempted to leave the old architecture in place and then replace it with new architectures piece by piece by piece so that the old stuff is still there and then the new stuff gets built. That gets PR’d and then eventually you’d turn it on and switch over to the new stuff and you stay green.

I’m wondering if three steps into a 10-PR process, do you run the risk of having people basically say, “Oh your architect in this is completely wrong. Why not go back and do it this way?” I wonder about the granularities. You can lose the plot of where the 10 PRs are going. Does that make sense? Do you run into that problem?

Yes, that definitely happens. What I would say is when you’re undertaking a large chains like that, typically this isn’t just something that sprang from your head. We’re not doing waterfall development here. We’re doing requirements, design, all that stuff. But when you’re going to embark on something that’s going to take you five or ten PRs to actually get through, typically you will have discussed the overall arch of that story. You will discuss that with some other developers on your team and got in a little bit of buy in typically, correct?

Sure.

That is so critical because if you have an architectural disagreement about the way a pull request went, that seems like at the end is the exact worst time to bring up that sort of difference at all.

There are times when even just a one PR change. So, something simple where you’re introducing a new model and there is going to be some architectural disagreement with how that was done. That I feel like is a little more okay. There’s going to be some disagreement and we’re going to discuss like, “Did you consider doing it?” I might say, “Did you consider doing it this way that would require fewer associations,” or something like that? I feel like that’s okay because the change in itself is still small. You didn’t spend a significant amount of time on it.

But if you’re in one of these five to ten – if you’re on this refactoring odyssey, this new architectural odyssey, it’s really hard to get bogged down. Like David said on the third step, somebody telling you you’re doing this all wrong which is valuable feedback to have. But it would be nice to have from the beginning. If you do find yourself in that situation, I would say trying to see like do we have the right seams here? Like I can make the types of changes that are being suggested later if it proves necessary, that type of thing. It would be an interesting path to take.

That’s interesting because I just realized this is one of those things that – I can’t remember if we’re doing the pull request and that style. It’s the first time that I’ve worked under this model. So I’m still coming to grips with it. You’re exactly right and I’m a little embarrassed that it’s the answer to my own question because there’s a service. It’s one of our core services, internal and external plans all depend on it and I need to make a major fundamental architectural change to it in order to get the one wafer thin change that I need out of it. Like it’s an unauthenticated public service and I need to have a private authenticated internal-only service.

So I went to the people that know the most about it and said, “I need to add this. But in order to add this, I think it needs to have this huge architectural change done to it.” Am I crazy or is this the right way? They were like, “Hmm…no. Yes, that’s right. You’re going to have to do all that crap.” You’re right. We had a half an hour discussion of how that would be architected and how the best way it would be. Then they patted me on the head and said, “Go do it. Send us PRs.”

You’re right. I just realized that this worry about having a 10 PR arch and getting three commits in or three PRs into it and having people review it and say, “You’re doing it all wrong!” Yes, you’re in trouble but in reality, you ran into trouble back at PR one when you didn’t have a conversation with the other people about how this 10 PR arch was going to happen.

Yes, I think that’s definitely true. I do think that these are interesting things to think about, like how are you going to handle these larger changes? But I also feel like day to day, that’s not what we’re working on usually. Usually what we’re working on is fixing a bug, introducing a new model, introducing a new feature. That type of thing. Those are a lot easier to reason about. Like keeping small, giving good contexts, that type of thing.

These larger changes, there’s several different strategies. We identified like you said, you’d rather build up like an architectural off to the side that’s not being used. I commented that maybe you just do it in a series of commits where you’re actually breaking things along the way. But in the end, the result is green and you squashed those down.

Yes, yes, I’m okay with that.

There are also different ways you can go about these larger changes to stay with them in the process.

There’s a thing that really struck me, Martin Fowler’s Refactoring book doesn’t actually mention this explicitly. But if you read through each of the refactoring steps, they all say things like extract method that says ‘copy the code you’re going to extract and paste it into a new function. Ensure that the code is still compiles. Now, extract the variables…’ and at no point does the code not work. Every single refactoring follows this pattern.

Because Martin didn’t give a name to it, I chose the name ‘don’t rip your bridges’ for the pattern. Literally, what I mean is you got one foot in the old code, you got your other foot in the new code. When you’re doing a refactoring, you always want to have this moment when you have both codes in place and working so that before you turn off the old code, the new code is working. If you step forward too far, if you remove the old code and then you have nothing that works and then you write the new code and you make it work. I call that ripping your bridges, that you have that moment in time when no code works and solves the thing.

I would agree with you that if you want to plunge ahead and then go back and squash commits so that the PR is still green, I’m totally down with that. I’m totally fine with that.

I like that name.

Yes, it’s a good name.

Now that you’ve explained anyway, it makes a lot of sense.

If you draw on a whiteboard over time, you have two rows. You just draw a bar graph of ‘here’s the old code and it’s working right up until we remove it’. Then you take the new code in green and you draw a bar graph off of ‘here’s when we got it working and here it is working on into the future’. It’s very obvious when you look at that graph that if those bars overlap, then at some point, you have both codes working. If the bars don’t overlap where there’s a gap in between them, that’s what I call ripping your bridges. You’ve got this moment when your pants are down on the internet. [Laughter]

I always do feel better when I follow a process where that happens. It always does feel good. But I

think I’m probably just not disciplined enough all the time to end up doing that.

So Derek, something strikes me about code review when I think back over my experiences with it. It can be very powerful both in detecting defects – yes, in defecting and just getting feedback from other people. But on interpersonal level, it can be pretty rough sometimes. I’m curious if you have any insights into making code review a supportive process.

Yes, absolutely. I talked about this a lot in the talk as well. I see lots of feedback that is wellintentioned in code reviews but not necessarily well-phrased, I would say, or nicely put. [Chuckles]

I think what it comes down to is, especially when we’re doing written stuff with the pull request review, there’s negativity, bias in written communication. So if I give you some feedback and I write it down for you, you’re going to perceive that one way. But if I give you that same exact feedback and I say it to you even just over a voice call or something like that or face to face which would be even better, you’re going to perceive that much better. Just having the conversation and the tone in your voice softens the feedback or softens the conversation that you’re having. When you write that very same thing down, it does come off much more harsh. It’s very much more subject to the mood of the person reading it is in, that kind of thing.

So I talk about this a little bit in the talk that I gave and suggest that instead of saying, “Oh, do this,” like issuing a command saying, “Extract the service here because you’ve got some duplication,” that type of thing. Just softening that just a little bit to ask the question to try to enter into a discussion rather than issuing a command. So you could say, “What do you think about this solution instead,” or, “Did you consider this other thing?” Rather than giving your feedback as a series of commands trying to open up a discussion to see like, “Did you already think about this?

Why didn’t you do that?” That kind of thing versus just giving the command.

That’s essentially bringing in Socratic Method, right?

Right, exactly. I mentioned that as well. What we’re trying to do is ask questions so that we have a good discussion around why the solution exist as it does versus like if I issue a command and you either are just going to be like, “Yes, okay. I’ll do that.” And maybe you don’t feel that great about it. Or maybe you’re just going to ignore me or whatever the case may be. Asking the question is going to lead more to better results, right.

I find this time and time again when I’m doing code reviews of the clients is a lot of times on more established companies, what I do a lot of is reviewing code. When I’m doing my 15th code review of the morning, it can be really tempting for me to just forget about that whole that I talk about often and just start issuing commands. Then I catch myself and then the next one I’m like okay, get back to being nice. Soften the speed back a little bit with some questions and enter into a discussion. Every single time, the discussion is better when I start asking questions.

So that would be the number one thing I think that people can do when they’re giving feedback is to stop issuing commands and instead ask probing questions. And you can still shape the discussion in the way you want to go with the questions that you ask.

If I can make a suggestion, there’s a specific three-word trigger that I highly recommend to people. Just memorize these three words and never let yourself say them. Those three words are “Why didn’t you?” “Why didn’t you,” and then insert a preferred solution here. The reason why is because when you say ‘why didn’t you’, it’s actually a complicated verbal linguistic hairball because you are presupposing a whole bunch of things. You’re presupposing that when I say ‘why didn’t you X’, it entails you didn’t do X. You should have done X. I, who am judging your code, obviously think it’s obvious to everyone that you should have done X. I would like you to explain to us all why you didn’t do it. That kind of thing. So you get very defensive very quickly.

The thing is you can ask that same question. You can ask, “Why didn’t you use the visitor pattern here?” You can just come around with that and just say, “It seems like the visitor pattern would have been a little more efficient here if that have been… did you consider that or would that have been something?” It takes them off the defensive. Because if you ask somebody, “Why didn’t you use the visitor pattern?” And their answer is, “Oh, I didn’t even think of that.” Now they look really dumb. It’s very much one up one down conversation where you’re one up and they’re in a one down position. If you’re like, “Would visitor pattern have been better here?” Then if it would have, they can go, “Oh man, that’s a great idea. I can take it.” Or if they actually have a legitimate defense, instead of bristling their defense with, “Well, the visitor pattern obviously require da, da, da, da, da,” they can actually come back quietly and calmly and say, “I thought about visitor pattern but I didn’t have this in place to support that. So this trade off would have been more inefficient.” And you can go, “Oh you’re right. That would have been less than efficient.” And you can go on down.

So yes, ‘why didn’t you’ is a great phrase that I encourage people to just develop people an allergy to, if they can.

Okay, I have a question for that. Can I instead say something like, “Did you consider using this pattern?”

Yes, absolutely.

Okay.

How do people feel about leading with ‘that’s interesting’?

I love ‘that’s interesting’. Oh, that’s my go-to phrase. It’s amazing.

I hadn’t considered that.

Let’s say my first mediocre reaction is ‘that’s stupid’. [Laughter]

Don’t say ‘that’s stupid’.

But instead I say ‘that’s interesting’. In the time that I buy myself to say ‘that’s interesting’, I also begin to think about why somebody might legitimately have chosen that course. Also I feel like it can also have a softening effect on the ‘why didn’t you’ or ‘have you considered’ - a question that you might follow it with.

I would often follow ‘that’s interesting’ with – because you do. You want to ask ‘why didn’t you do this obvious act’, right?

What’s wrong with you?

Yes, exactly. What is your deal? ‘That’s interesting’ followed and you got nothing. You’re like, okay, I bought myself some time. Now I need to ask why they didn’t just use the visitor pattern. So you say, “That’s interesting. I might have used the visitor pattern here. Had you considered that?” And so you can say ‘I might have used’, ‘that’s interesting’, ‘I might have used’. I will say if you use the word ‘fascinating.’, it will come across as sarcasm. [Laughter]

Ask me how I know.

A lot of what we’ve talked about is putting the emphasis on the reviewer. But what kind of quality does the reviewee need to have to make code review effective?

The reviewee being the person who submitted it?

Yes.

Yes, I think it’s important to try and realize that no matter how the things are phrased, people are generally trying to help. So, it’s great if everybody does what we were just talking about where they soften their feedback, if you’re continually having a problem with people giving this harshly worded feedback. Maybe point them to this discussion or other discussions that coach them along to give more effective feedback. But if you’re having your code reviewed, you need to look at it more like -this isn’t a judgment on me, like what I said earlier. I think it’s easy for people to think that it’s a judgment on them. But this isn’t necessarily a judgment on you. Through this whole -- like everybody’s asking questions. Now you’re doing this discussion, you’re having this discussion which I feel is rewarding right off the bat even if you disagree. You’re like, “Now, we’re going to talk about the visitor pattern.” They keep hammering on that. Maybe I’m going to learn something or maybe I’m going to teach David something about why the visitor pattern is a bad fit here or whatever. These are much more rewarding things to get into than the ‘why didn’t you just…’ kind of thing.

Other things that you can do...

Why didn’t you just – the ‘just’ is a times ten multiple error on the why didn’t you because it makes it explicit that you think it was obvious.

And Derek, you have an entire section where you talked about the word ‘just’.

Yes and the statement that David made earlier about ‘why didn’t you’ is basically the entirety of it. Only I also included ‘why didn’t you just’. That actually got a really good reaction from Ryan Davis who’s in the crowd. He was very happy to hear somebody say, “Stop saying ‘why didn’t you just’.”

Going back again to what you can do is I guess this is both people doing the review and people having their code reviewed. At some point, you’re going to have to say like you can both say ‘that’s interesting’ at each other. But you’re going to ship some code at some point. So, you’re not always going to have come to 100% agreement on everything. So realizing that and saying like, “Okay, I hear what you’re saying about the visitor pattern. I think this is a simpler solution for right now. What do you think about going with this for now and revisiting if we need to make a change to this?” That kind of thing. Looking for those ways to agree to disagree versus just talking circles at each other for weeks while this thing doesn’t get merged. Weeks is an overstatement but maybe a day or two versus this could just be a conversation that we say, “Okay, yes we both need some good points here. Let’s table it. Let’s go with one of the solutions for now. We’ll come back to it.”

I have a very important question that’s been bothering me this whole hour. When I look at the slides from your talk on the fourth slide and I think the fifth and the sixth as well, there’s a picture of bugs and I just need to know, are those real bugs? Are those fake bugs because they look disgusting?

I believe that they are real. At the very end, there is photo credits at the very end of the talk. I got all those off Flickr. So you can look that up and see.

That makes me very sad.

I do believe they’re real and several people told me that they were disgusted by them. [Laughter]

Because they’re like these really bright orange. So I thought maybe these were just made of clay. I was being optimistic. But no, okay.

The brighter the colors of the insect, the more poisonous and venomous it is.

Oh no! I don’t need to know about that part.

That’s right. Sorry, maybe I need to soften that image. [Chuckles]

I used to run a photo site called InsectPOD which was the insect picture of the day. I learned a lot about macrophotography and I also learned that nobody wants to look at pictures of insects every day.

The site’s down and long gone and lost to the history but I’ve had some fascinatingly disgusting photos. It was awesome.

So we’ve talked a lot about code reviews and why they’re good but let’s say you’re at a company that doesn’t currently do code reviews, how do you even get started with instituting as part of the [inaudible] culture?

Yes, I’ve seen this go one or two ways. In my case, when I first started doing code reviews, it was top down. We have to do this because we need to generate this documentation for compliance. That type of thing. That ended up being toxic for a few years because I just resented the whole process. The other way I’ve seen it done is like a senior developer on the team just decides that, “Okay, we’re all doing pull request reviews starting now.” That can be equally toxic from a perspective of this person who thinks that they’re the leader of the team said we have to do it this way. Everything has to be approved by them, that kind of thing.

What I would suggest doing instead is if you want to do code reviews, just start doing them on your code. Just start saying, “Oh, I got this change, Derek. When you got a second, could you take a look through it?” Or like maybe go through it with somebody. If you know the type of feedback that you want to hear, have them sit down and actually at the pull request screen in GitHub, start going through and be like, “What do you think about what I did here?” Coach the process a little bit. We’ve had some success in that. We’ll go on to more established teams, maybe just one or two of us from thoughtbot to a more established team. We’ll make sure we’re doing code reviews on all of our stuff. We’ll encourage pull request to be open by other people and we’ll give good feedback there.

It’s important I think when you’re dealing with newcomers to pull request to not bombard people with feedback. Try and keep the feedback at a high value, very high level thing. To bring them along and get them used to the process a little bit. Give them some quick early wins. And be sure, like you’re saying if you’re going to review somebody’s code, you may be not entirely bought into this process. Maybe they’re afraid of being exposed to somebody who doesn’t know as much as they should or whatever. They have some impostor syndrome going on like we all do.

Then being sure to say, “Oh, this is really interesting.” And not in a way of, “That’s interesting, here’s an alternative.” But being like, “Hey, that’s really interesting, I didn’t know you could do that. That’s great. I’m going to do that next time I come across this problem.” So not just giving critical feedback but also giving praise. So, if you start really small by just being the change that you want to see in your organization and trying to win friends that way or win people over to your side that way. And then saying, “Hey, we’ve been doing this for the last few weeks. I’ve noticed some really interesting benefits. What do you think for the next month, we all try to do pull request and pull request reviews?” That type of thing rather than having it be a commandment that comes from either on high or your most senior co-worker or something like that. It tends to work a little better in my experience.

Yes, finding something positive in the code review is a good way to really invest emotionally in the other person and make it clear that you’re trying to improve the quality of the code, not tear them down. We had a test engineer that just wrote on a pull request in one of the specs. She wrote, “OMG, I love it when people write specs like this. Thank you.” It’s like holy crap! That’s a thing you can totally write on a pull request. You don’t have to just tear everything down.

Yes, it’s great to see that. At the last client I worked with, they had seen this talk after I gave it then I continue to work with them some more. At that point, they knew what I was doing. They knew all my secrets. But it didn’t matter. It still had the same effect like being nice, asking questions. It still had the same effect of spurring conversation, making people feel better about their changes. I’m not like -- when I’m giving compliments, it’s not entirely out of like okay I’m going to give a compliment here and then I’m going to be a little more negative down here. That’s a benefit but it’s also like I just want to give people credit for doing something that I didn’t – like teaching me something or doing something really interesting or whatever. Just acknowledging that, “Hey, this is a difficult problem and this is a really good solution for it, an interesting solution,” that kind of thing.

Yeah.

So assuming you do have a team’s buy-in for code reviews, how do you just make sure that it gets done? Maybe some people really enjoy doing it. In my experience, it’s always been one of these overhead things that are harder to get people to do. One team I worked on, we had basically like once a month or once an iteration or something, we would select a new person who was expected to spend less time coding but more time going over pull requests and code reviewing them. Do you have strategies for making that a regular part of the team’s process?

Yes, I found it successful to try and make it a little less of a process especially if you can keep people working in the mindset of having small changes that are quick to review, that type of thing. For us anyway, it works out pretty well to do some reviews in the morning of stuff that came in yesterday that you didn’t get to. Maybe a review or two right before lunch. Maybe a review or two right before you get coffee or right after you go and get coffee in the afternoon and then maybe right before you go home. There’s all these natural breaks in our work like we’re about to pick up something new or we have a test suite that, God forbid, takes five whole minutes or something like that. You need something to do to occupy that time or you just need a break from what it is you are pounding your head on for the last hour and a half or whatever and not making much progress with.

So that’s the process we typically try to favor. It’s just like very asynchronous. When you have a pull request, put it in slack, somebody will click on it and give you a review. And you’re waiting for typically one review with a big change. Maybe you want a couple of people to take a look at it. You’re waiting just for one thumbs-up or one approval and then you move on. Having it be very lightweight and not bogged down in that process works, at least in my experience, better than having a set person that’s going to be most responsible for the reviews. Or there are people at RailsConf talking to me about a process that they were in where you needed two thumbs-up to ship anything but if somebody gave one thumbs-down then that counted. That was a blocker and you have to get them to clear the thumbs-down. There are all these rules that they had around like what kind counts for what.

What I keep coming back to is this is just a discussion about code. Code is mostly tradeoffs. The problem isn’t with some gross quality problems. Then at some point, you just got to be like, “Okay, interesting. We’ll revisit this kind of thing.” So trying to make sure you don’t enter into those spirals of ‘this isn’t the way I would do it’ kind of thing saves in on time as well.

Do you tag someone to do the review for you or do people just pick a pull request to review or what?

It depends on the size of the team really. Sometimes if I’m on a team that’s a larger team where I know that, for instance, Colin or whoever on the team is really most familiar with this code, I will just pull the pull request out for a general review like in the chat or whatever. Then maybe I will also follow it up with like, “Colin, it will be great to get your thoughts on that because I know that you dealt with this code a lot three weeks ago,” or whatever the case may be.

But I’m actively trying. One of the benefits I think of having everybody try and take a look at code reviews is that you start to get -- like you start to share this knowledge, it’s no longer like, “Oh, Derek and Colin know that area of the code.” So when they’re on vacation, uh-oh. It’s more of like everybody has seen this code go in. We kind of all have said, “Yeah, that looks reasonable,” that kind of thing. So, trying not to do that.

Also I’ve seen situations where only the senior people on teams do reviews and I think you really need to try and get the junior people involved in those as well. I think doing the things we’ve talked about today like not being negative, asking questions, that type of thing makes it a more welcoming environment for them to do that.

We use a semi-formal, it’s an informal process but it’s officially informal at CoverMyMeds where you need an LGTM which is it ‘looks good to me’ comment from somebody who didn’t write the code. We will usually just go in to our team room and just say, “Hey, can we get the phones up on this. It’s surmise on this PR.”

The only time we will tag somebody is if we are really deep in the bowels of something that’s highly specialized and we know somebody else used to work on that. We’ll say, “Hey, can somebody look at this?” Also, “Ryan, can you maybe take a look at this,” that kind of thing. We’ll also tag somebody just like a random person on the team if we want to fast track it because they get a notification that, “Hey, you just got mentioned about this.” Then they can say, “Oh yeah, I can jump on that.”

Yes, I think the other two great cases for tagging somebody – you know that there’s some intimate system knowledge here that this person has and it’d be great to have them look at it. Or you really need to get this out there. It’s a bug in production. You need to ship it.

I’m in a situation where the person who knows a lot of where the bodies are buried in our code has been promoted to management to another team. And so, we will tag him occasionally just to let him know that his promotion means nothing to us. [Laughter]

I love you Mark!

[Inaudible], we have a pretty formal process. We use a tool called gerrit and it basically requires a +2 report, any code can ship to QA. QA has to +2 it and [inaudible] has to +2 it. Only at that point is it even physically possible to merge which I think a formal process has some advantages but it definitely has some disadvantages. Your talk [inaudible].

You have to weigh things for the organization that you’re in. At thoughtbot, I’m working with a lot of generally smaller organization. Sometimes it’s just like me and another thoughtbot developer and a thoughtbot designer. So we have a smaller team and I don’t want to have a restricted process. I want to have rules on where these JIRA cards can go, that kind of thing.

But as your team gets bigger, sometimes those things make sense. I would say waiting until they absolutely have evidence that this is a problem that needs to be fixed and processed rather than changing some habits. It’s probably a prudent thing there but you have to do what makes sense for your organization.

Are you aware of other tools that come in handy during code reviews or is there anything you’d recommend?

Yeah, I talk about this a little bit. I would say one of the things people get a lot of comments on or leave a lot of comments on is style. If you’re on a team that has a style guide or maybe you don’t actually have a written style guide, you just have somebody who really cares about writing the code the way that they would have written it. That type of feedback, I think, is important particularly if you do have an adopted style guide. I think it’s important that people try and follow it where it makes sense.

But there’s been studies that show like feedback on that type of thing in a code review tends to be looked on negatively. It’s like, “Oh, you’re harping on this little style thing. What do you think about what I actually did?” That kind of thing. In Ruby, we’re lucky to have, I’m blanking on a name, a rubocap. Rubocop, you can give it some style guide rules and it’s going to look at your code and do that for you. We also have JSHint. It will do the same for JavaScript and we have sass-lint, will do the same for your sass code.

So there are all sort of tools you can do to not have people reviewing code worrying about what the style looks like. This is the part where I’m going to plug a service that thoughtbot sells called Hound. I do so of my own volition because I think it’s a good tool and it’s like $12 a month or something like that for a [inaudible]. But it will take those rules and all those linters we’ve just discussed and run them and give you comments as if it was a person commenting on the pull request that you can either take or leave. It’s not going to fail or build for you, that kind of thing.

Oh, cool.

You can either take it or leave it. But again, it’s like a way to discuss. After we introduced Hound on teams, what we start to see is people have discussions with the robot that has left the feedback which, I think, is actually really good. That’s what I want to see. I want you to explain to me. If you’re not going to follow a style rule, I want you to explain why you shouldn’t follow the style rule because it’s just a robot leading that feedback. Maybe you feel negatively towards the robot but it doesn’t really matter.

I could make you want to kill that robot because I would totally program the robot to say, “Fascinating. Why didn’t you just…” [Laughter]

Like any more on what they know what to do.

That’s good. So yes, I think tools like that. Obviously having CI that runs tests I think is very important because like I said, I’m not necessarily going to be able to catch this like how-thesystem-interacts type bugs. Having something like Code Climate can also be valuable to see. I find it most valuable in a situation where something has improved because Code Climates like, “Hey, the changes in this pull request moved this file from a C to a B,” or whatever. That’s actually really gratifying feedback. That’s another form of getting a nice feedback. So I think tools like that, anything you can automate I think is worth it.

I’m curious about Hound now. How configurable is that to reflect the styles of an individual organization?

Very. It depends. Hound is running Rubocop. For Ruby code, it’s running Rubocop.

I see.

So whatever you can configure in Rubocop, you can configure in Hound. The same for JavaScript, it’s running JSHint, so whatever you can do in JSHint, you can do in Hound, that type of thing.

Cool.

You can turn different things off and on or whatever. It’s configurable to whatever you need.

We’ve been talking a lot about code review and the context of teams. But I can imagine there are probably some people listening who are working alone or maybe they’re just getting started and they aren’t lucky enough to be on a team yet. They’re wishing they could get some of that good code review feedback. Are there any resources out there or any ways for people to experience code review when they’re not working with a team?

I am not aware of any. There’s somebody that’s aware of some. I think it’s a great idea like trying to buddy up with somebody.

exercism.io. It’s nothing but code review. Yes, it’s [inaudible] but the [inaudible] are brain dead stupid. The first one, the Bob example is just like Bob’s a teenager and if you ask him a question, he’s like, “Whatever.” You have to write a class that returns whatever. I don’t like these three rules. I went like seven freaking iterations on that thing with Katrina saying, “Well, what about this,” or, “Why do you consider this?” “Have you considered trying…” I’m like, “Holy crap! Are you actually going to make me write good design in this code?” And the answer was yes, she was.

Yes, I do think tools like that are great but I also think it’s really valuable when it comes down to getting whatever project you are working on actually reviewed. That’s when you’re going to start applying maybe some of the things that you got back in those [inaudible] or in stuff that you read in Sandi Metz’ book or whatever the case may be. So, I think getting the actual applied stuff would be the best feedback.

Yeah.

Yeah.

Trying to find somebody like if you’re a freelancer, finding another freelancer or things like that. I’ve also thought about just like on a Friday being like, “Hey, do you have code to review? I’ll do that for you.” But obviously, that doesn’t scale particularly well.

That’s a good start though.

Yeah, I made…

You get to meet new friends too.

Start doing some stuff like that. I think Avdi, didn’t you have like a service at one point? Am I misremembering – maybe it was for pair programming?

Oh, Pair With Me, yeah.

Pairprogram.me is not a service. It is just paid with a whole lot of resources on it for different ways of remotely pairing with people and finding people to pair with and stuff like that.

Yeah, I would say that same type of thing is not pairing but it’s asynchronously reading somebody else’s coding, getting to learn from it. Looking at people who are interested in remote pairing is probably a good way to find somebody who might be interested in doing some remote code reviews for you.

One of the things that we started doing, I think, a few weeks ago is we started having these evening study sessions. So we have on Monday, we do Ruby. On Tuesday, we have JavaScript. On Thursday, we have Python. What we started doing is having team projects. The whole code review, pull request, team collaboration part is the focus of those projects. So JavaScript is doing like a Hangman game which is relatively simple but in the process of doing that, like we have a tally board and we’re organizing our feature cards by priority. You have to get the thumbs up before you can merge in your pull request. And for a lot of people who’ve been mostly learning on their own and doing things there just by themselves, it’s a really interesting opportunity to say, “Okay, now I have to know what a pull request is and how to name my branches and how to respond and how to communicate.” We do that exactly for that reason. It’s a huge skill. The thing there is just knowing how to code and good design patterns and that but then working on a team collaboratively to ship a product is a whole other skillset that I think is hard to pick up when you’re learning on your own.

That’s fantastic, to pick a simple project and just put in all of the process and the overhead where yeah, you’re basically just practicing the process in the overhead.

Exactly.

The code itself is pretty simple. There’s a really good motto that I heard about a year ago and it just keeps coming up over and over again. Of all places, I think it’s from the Navy Seals but the motto is ‘Go Slow to Go Smooth, Go Smooth to Go Fast’. And I really liked that motto of let’s take some code where we’re not panicking, we’re not trying to get this shipped to keep the company from going bankrupt. All we’re trying to do is just practice our process and make sure that everything is going out and coming back right in the way it needs to do. Once you start to get in the habit of write the code, push the commit, ask for the PR, wait for the LGTM, then merge the code. Yeah, now you start to get smooth and now you can start to go fast.

Sounds perfect.

It’s pretty awesome.

All right, does anyone else have any questions for Derek?

I’m good.

This has been a great discussion. I really enjoyed it.

Yes.

Thanks for having me.

Let us get into the picks. Saron, do you have any picks today?

Yes, I do. So, the first one - two interviews that we did recently on the Code Newbie Podcast that I’m so excited about. We had Sandi Metz on and she was so phenomenal, so honest and open and incredibly accessible. It was so good. We actually broke it up into two pieces. So, Episodes 41 and 42. I’d love for everyone to check that out. The second one is do you guys know the YouTube series ‘If Google Was A Guy’?

No.

I love when I know YouTube videos that people don’t know. So, it’s called ‘If Google Were A Guy’. I think there were a couple of them. I’ve only seen the first one but I think there are two or three versions. It’s so funny. It has Google personified as this college professor. And you come in with your request and he gives you the results and the reaction and the story. It’s really funny. It makes the end user look dumb but I think it’s justified. So definitely check that out, it’s absolutely hilarious and incredibly accurate. So, those are my picks.

I need to make a video of me trying to use ‘Okay Google’ to get us to understand my voice. I have yet…

One day.

I totally second the Sandi Metz interview pick. I really enjoyed that.

Thank you.

Coraline, any picks?

Yes, I have one pick today. I am so excited about this. Basically, Lego has this mechanism by which people can pitch a Lego set to be developed and people can vote on it. If it gets a certain number of votes, it actually gets designed as a set. There’s a proposed set right now to celebrate Ada Lovelace and Charles Babbage. December 10th of this year marks the 200th Anniversary of Ada Lovelace’s birth and she, of course, is one of my namesakes. So this project will be a great commemoration of the Bicentenary, and potentially inspire a new generation of computer programmers because there’s a capacity in the Lego model to house a mini computer like a Raspberry Pi which I think is the most amazing idea. The brick set is monochromatic to look a Victorian atmosphere. The engine’s sort of cyberpunk-looking. It’s pretty cool looking. But I think the thing that sells this for me is including a Raspberry Pi and making that available to kids. And getting them excited about programming; as excited as Lovelace and Babbage were in their time. So I think that’s pretty awesome. So I’m going to put a link to the voting link and the description of the set including pictures in the show notes.

How about you, David?

Okay. So, I promised only one pick. So I’m going to make good on that and that is CoverMyMeds. We have an intern program and it’s full. We are still looking for really high quality Rubyists. And so, we have decided to try to do something unusual which is to poach from other verticals of our industry. So we are looking for Java programmers and .NET programmers that have really strong engineering skills. Right now, the big push in the Ruby community is to bring up newbies as much as we can. And we do have a coop program. Like I said, it’s full and we still need more really sharp engineers because we are just riding a tiger right now. We are saving people’s lives and it turns out that people want that. It’s absolutely fantastic.

So we did a publicity stunt. We hung up what we think is the largest Ruby logo in the world. It’s 50 feet tall. It’s like one of those – is it a billboard? Is it a building? Is it a bird? Is it a plane? That kind of thing. It is a billboard that covers the entire side of an entire skyscraper. I say skyscraper. It’s 120 feet tall. The billboard just flat out says it’s the largest Ruby logo in the world. It’s also accidentally the largest Java logo because it’s a cup of coffee with a Ruby in the middle of it. The logo is ‘come get a better cup of coffee’. We are definitely looking for Java and .NET programmers. If you are interested in this or if you know someone who is, please feel free to contact me on Twitter @dbrady or the billboard has the URL right on it and I will give that here which is CoverMyMeds.com/Ruby. That’s the landing page where you can learn more about this and find out what we’re looking for and whether or not you’d be a good fit for us. But the long and short of it is the prior authorization request mechanism for insurance companies is completely broken and we are fixing it. We are getting people the medications that they need by forcing their insurance providers to actually pay for them when they should. That’s freaking awesome. We’re saving people’s lives. I get to work every day feeling l did something important.

If you are working in Java or .NET and you want that sense of fulfillment and you would like to switch to Ruby, we are basically doing – I should have said this at the very beginning – what we’re doing is a series of Bootcamps on Ruby on Rails for people who already are expert in another’s author language. It’s not just dover.net. If you’re a Haskell guru or you know Erlang, definitely come talk to us because we’re definitely interested.

The number one question I’m getting asked by people on Twitter is do you have to work in Columbus, Ohio at the headquarters or can you work remote? The answer is yes, you can work from anywhere that you can see the sign. I can see the freaking thing from Utah. So yes, remote is okay.

That’s my pick.

I want to see this billboard. How do I see it?

I will post a picture here in the chat at the end of the show notes and I will also post a link for the show notes.

Awesome!

Derek, what about you? Do you have any picks?

Yes, sure. I’m going to selfishly plug BikeShed.fm again. That’s the podcast I host with Sean Griffin. If you like this podcast, you like Code Newbies, you might like that. So check it out.

Then for picks, the first thing I have here is the Ember RFC Process which is not software pick but just an idea. In Ember, if they’re going to make a large change to the framework, it goes through this RFC process that gets comments. I wish very much that Rails had something like this or things like Action Cable. Unfortunately, it does not. I very much admire the way a lot of the Ember project [inaudible] and I think their RFC process is one of the things that’s really interesting about it.

My second pick would be this thing called tota11y. If you’re going to Google it, replace the l’s with 1s. So it’s tota11y. That 11y is for accessibility. So I went to a talk from [inaudible] when I was at RailsConf. It made me realize how very little I know about accessibility despite having been a web developer for 15+ years. I’ve been really interested in how to get better at accessibility. So this tool called tota11y, it can run as a bookmark or you can include the script in your development server and it will run some accessibility audits on your page for you and give you a little icon on the lower left that you click and it will give you the results from that audit. They’ll tell you things like you’re missing labels on these form fields or your link text is very generic which is like click here link text is not particularly helpful to the screen readers. Your headings didn’t follow the proper cascading, things like that. It’s a really interesting tool to play around with and learn more about accessibility.

My final pick is a talk called How to Performance and it’s by Eileen Uchitelle. She gave it at GoRuCo which was recently, a couple of weeks ago, I think. I really admire the people who do like the down the weeds performance work and she’s one of those people doing that work. I’ve always been confused, I guess, as to how to get into it myself and this is a good talk that goes through exactly what she did to do some benchmarking on a Rails change that she was doing and then how to get a baseline and what to do with that information once you have it. That type of thing. So, I really enjoyed that.

Cool!

All right, cool! Well, I have a couple of picks. Actually Derek totally stole one of my picks because it was going to be The Bike Shed Podcast which I do listen to on the occasions that I manage to listen to podcasts. I used to listen to this one Ruby podcast but now all they talk about is Elm and Clojure and stuff like that, weird stuff.

[Laughs].

Bike Shed is cool because they still get into the technical stuff about Ruby on Rails. It’s a good podcast, I’m enjoying it.

I will also pick my new camera. This is a camera that I asked for, for my birthday and my wife got it for me and actually gave it to me a bit early. I realized now that I live in the woods, I’m wanting to take pictures of things more often than I used to. The sensor in my Nexus 6 phone is actually really good so I’m pretty much covered for close stuff and pictures of my kids and stuff like that. It’s really the long range dim shots that I was missing out on. So I went. But what I really didn’t want to do is I didn’t want to get back into photography as a hobby. I did that when I was in my late teens, early 20’s. I got that out of my system and I really didn’t want to open up that money hole again.

I did not go for the Micro Four Thirds System or anything like that. What I got is an Olympus SP100EE which is basically, it’s a fancy point and shoot camera with a monstrous zoom lens on it. It doesn’t have quite the sensor quality of a proper DSL but it’s good enough. Like I said, it has this great zoom lens, it has great lens stabilization. It has this brilliant feature that currently no other cameras have which is a dot site, a laser dot site like you will see on some firearms. It’s hard to explain but basically, you can look through this space at the top of the camera and through fancy optics, the dot always falls where the lens is pointed even if your eye is not perfectly lined up with it. The great thing about that is with a long zoom lens, a lot of times, if you lose your target, you have to zoom all that way back out to refind it and then zoom back in again. The dot site enables you to zoom in and then keep the lens on your target without going through that process so you can actually catch shots of birds flying and stuff like that without that whole rigmarole. I’ve really been enjoying it. If you get it, don’t expect the most perfect DSLR’s quality shots but I’m totally getting shots that I was missing before. I’m really looking forward to taking it to Cades Cove and getting pictures of the bears that are just like little black blobs in the distance where you say, “I swear this is a bear. I promise you.”

I hate that.

Yes, it also takes some great macro photos and generally it’s been working pretty well for me. Those are my picks and I think that about wraps up our show. Derek, thank you so much for joining us.

Thank you.