Soft Skills Engineering - Episode 156: How to move from web development into other software engineering roles and dealing with slow code review processes

Episode Date: May 6, 2019

This episode is sponsored by the O’Reilly Velocity conference. Register today and use discount code SKILLS for a 20% discount: http://velocityconf.com/skills. In this episode, Dave and Jamison answer these questions: Hey! I love your podcast, you have definitely helped me improve my soft skills in my career. I am a full stack web developer and I have been pretty much loving it. Web development was not my original career plan though, I graduated with a Bachelor’s in Computational Mathematics & Computer Science, and I knew I wanted to be a software dev since working with robotics in middle school. I kinda fell into Web Development from my IT work study job in college. I have been doing this for 4 years, and I am ready to transition over to applying for Software Engineering jobs. How do I get over this scary feeling of leaving my safety net? How can I encourage myself that I can make this new career transition? There will be jobs I see posted, and I just wanna go for it, but I always get scared at the thought of leaving since it’s just so intimidating, especially coding interviews and interacting with new people, new workplace, etc. What if I end up regretting my choice? Any advice is appreciated! Thanks guys! I always look forward to your episodes every week - I share your podcast with my fellow nerd friends! I work at a bureaucratic company where we move fairly slow. Recently, I’ve been getting more and more frustrated with our code review process, but I’m not sure if this has to do with my quality of code. It can take weeks for one of my pull requests to actually get merged. Someone will review my work, I will make some changes, then they will come back some days later with a new truckload of very nitpicky details that they want changed. This makes me long for the days of me working at a startup where we had no code review, and no testing process, and it’s making me sad. How do you draw the line over what is reasonable code review and what is too much?

This episode is sponsored by the amazing O'Reilly Velocity Conference coming to San Jose, California June 10th through June 13th. It takes more than great spring auto wiring skills to be a great engineer. This is episode 156 of the Soft Skills Engineering podcast. I'm your host, Dave Smith. I'm your host, Jameson Dance. Soft Skills Engineering is a weekly advice show for software developers about non-technical topics. You know, I don't know what spring auto wiring means and i don't want to i don't want to either today let's thank our wonderful patrons thank you so much to the folks supporting us on patreon thank you to matthew voitovich the agile ventures charity zach grannon louis santos nick cantar sean clayton sunny tie sonic the hedgehog marie

rousseau and chris hogan thank you so much to all those folks and other people who are supporting at different levels if you would like to support the show and pay for editing and hosting and stickers and design and all that stuff you can go to softskills.audio and click support us on patreon yeah thank you so we have a comment from a listener today can i share that with you please okay this uh says greetings from episode 138 i asked the question about pay raises and making a case for myself before the decisions are made i took your advice and had a chat with my manager i ended up getting what i wanted and now i am much more in line with my colleagues and have been rewarded for my work. Thanks so much for giving me a push in the right direction.

Congratulations. That's fantastic news. We've helped one person. It's all been worth it. I'm just glad that our commissions are so low. I mean, we only take 10% of each raise. Yeah. Yeah. It'll be nice to have a second gold-plated microphone. All right. That's awesome. I think I'll read our first question here. please this comes from a listener named arelli who says hey i love your podcast you have definitely helped me improve my soft skills in my career i am a full stack web developer and i have been pretty much loving it web development was not my original career plan though i graduated with a bachelor's in computational mathematics and computer science that sounds really intense by

the way and i knew i wanted to be a software dev since working with robotics in middle school i kind of fell into web development from my IT work job study in college. I have been doing this for four years and I am ready to transition over to applying for software engineering jobs. How do I get over this scary feeling of leaving my safety net? How can I encourage myself that I can make this new career transition? There will be jobs I see posted and I just want to go for it, but I always get scared at the thought of leaving since it's just so intimidating, especially coding interviews, interacting with new people, a new workplace, etc. What if I end up regretting my choice any advice is appreciated thanks guys i always look forward to your episodes every week

i share your podcasts with my fellow nerd friends thank you what nerd friends what i am offended that they're not jock friends what do you mean well i mean i feel like the insinuation is that we might be nerds how dare you i've accepted it i'm gonna go ask all my jock friends if they think i'm a nerd now i think you have to prove it by arm wrestling them oh great i am not the best arm wrestler hey brick brack brock am i a nerd no dave check out how good you are at arm wrestling what if you are and they've just been letting you win because they're just really supportive jocks no because i fixed their computers

And now hand over your lunch money. Oh my gosh. Okay. This is a good question. So there's the specific about moving from web development to non-web development. I guess in my head that line is fuzzier, but the question is at the end about kind of career change and job change as well, getting out of your comfort zone a little bit, right? Yeah.

From what I know about your career, some of your job changes have been pretty wildly different in terms of domain right oh yeah can you talk about how that was for you was that scary for you it was great i'm kind of a weird person i mean great now but like was it scary in the moment no i mean i change jobs because i want change like i am uncomfortable when things stay the same too long i've come to realize that not everyone is like this took me about took me about 15 years of in my career before i realized not everyone likes to change their job but like i chose new jobs specifically because they were a complete reboot to totally different skills different languages different technologies and that's actually what compelled me to change

that wasn't the thing holding me back so i'm kind of weird this way and and so i just loved it i'm thinking through my career and it's all been you could kind of squint and call it broadly similar domain so i haven't done a wild switch from from like embedded systems to web development or something like that i did that yeah actually that's true you did it was great so be like dave that's the first advice how can i encourage myself that i can make this new career transition listen i don't even know what computational mathematics means but it sounds hard yeah so i think you you are capable of doing hard things that require you to be smart oh yeah i feel like you just need a pep talk well i think that's what we're here to do yeah let's do this go team

rah rah rah oh now we have to do it and it turns out we're bad at pep talks there will be jobs i see posted and i just want to go for it but i always get scared i mean i don't know what to say besides go for it like the cost of failure is pretty low you talk later about the cost of picking a new job and not liking it and that's scary because that cost is pretty high but just doing an interview and bombing it you might feel bad but nothing is different about your life yeah uh and it turns out doing a lot of interviews is the best way to get better at interviewing when i look for jobs i certainly interview a lot and fail some some proportion of that but i almost feel better after that because i feel like i get some of the horrible

mistakes out of the way and and it does feel like that's kind of part of the process where every time i switch jobs i'll have some interviews that go really badly and then i think you know good thing i don't work there because that was horrible and if they hire me after that that means their interview process is really bad or if if if i want to join it after that that means i'm a really bad judge of like what would be a good fit for me that's funny i i know you don't understand that because you don't do bad interviews but some of us no i've been i've been in that situation i've interviewed a couple places where i was like if they make me an offer i'll be surprised and and I'll say no and I'll say no because it was too it was like weird interview process you know I'm like

I wonder who else kind of slipped through this process without getting really vetted you know yeah I mean I could turn this into a rant about certain kinds of interview questions but I will not let's just say I hope I never end up on a bridge needing to get a candle across under certain very tight constraints because I would not be able to figure it out on a whiteboard That's hilarious. I wouldn't either. I can only figure those things out after a good night's sleep and maybe in the shower. Yeah.

The other part of this question that I think I could share a little bit of experience with is interacting with new people in a new workplace and leaving your current co-workers, especially if you really like your job. And the very first job I had out of college, I was there for 18 months. And I really didn't like the material I was working on, the product we were working on. A lot of my work ended up getting shelved. And so I just thought, I've got to go find a place where I can actually ship things that get used. The problem was, though, that the group of people that I was working with,

it was a small, tight-knit group of about a dozen engineers who had been working together for 20 years. Like literally this core group of engineers and scientists had been working together for about 20 years. Did they follow each other from job to job? Yeah, this is like four or five jobs in a row. One person would move and then all the others would come along. And so they were super tight-knit. And I just felt like I was stabbing them in the back, you know, to leave. And I felt so bad.

I'm like, oh, but I got to go. I'm not having fun. I'm brand new in this career. I got to get started on something cool. And finally, you know, after I told them I was leaving, I just felt they were all just going to hate me and it was going to be so terrible. And I talked to one of them and I'm like, look, I just feel so bad. And he was like, why? Like, what's the problem?

And I'm like, well, I'm leaving. You know, I feel like I'm stabbing you in the back. He's like, you're fine and we'll be fine. Don't worry one bit about it. And he completely put my mind at ease about it. And I realized, you know what? He's right. Like, no one expects you to stay somewhere forever.

And not everyone is expected to be a perfect match. And then when I went and started my new job, it was one of the greatest jobs I've ever had. I met some of my favorite people of all time. This is almost 15 years ago. And I still keep in touch with a lot of these people. So I would not worry one bit about that. You will find new people, the people that from your old job that you like. You can stay in touch with them because we have things like LinkedIn.

you know it's very easy ah yes the best way to stay in touch with friends this is like the second week in a row we've had a linkedin a linkedin reference drop and you're welcome yeah we'll take that commission now secrets i thought you were gonna say that they were like don't worry about it you haven't been working with us for 20 years like you're nothing to us yeah i know like we never cared about you anyway that's probably part of our club maybe that was like if i had read between the lines i i would have come to that conclusion no i mean i'm sure if they've been together that long there have been tons of people who have been with them part of the way

and then dropped off and that they've they've survived yeah probably yeah that's a good point i mean some people just left a handful of folks just left my current job or not my current job but some of the teams that i work with and they're brilliant and talented and do really great work and we were sad to see him go but no one was like how dare you do you know what this will do to us yeah that's i don't know that's part of life yeah i think we were all pretty genuinely happy for him when they moved on to opportunities they're excited about they've done good work here and we're gonna go do good work somewhere else yep i could see how adjusting to new people in a new workplace would be kind of scary sure a little i'm struggling to say something that feels smart

about it it is and then you just do it and it's okay yeah well also i think you should know that this is not a one-way door you can come back and i've actually done this i quit a job went to a startup and then six months later i said you know what this startup isn't for me and i went back to my previous company and they took me back and it was fine so um we are in a job market right now especially for software developers that changing jobs is pretty easy and there's tons of opportunities out there so if you don't like your next job and you know it's a bad workplace or co-workers that don't jive with you like you can probably find a new one pretty quickly especially if you have a coveted degree in computational mathematics yeah that sounds awesome i wonder if there's

some amount of feeling like because the question askers experiences in web development and they want to transition to something else maybe they don't feel like they're qualified or have the experience to do these other kind of jobs yeah okay and you should be a hiring manager sometime because you will see you will see there are people who do not care about that whatsoever they just machine gun their resume at everything that moves and like totally not a fit and it doesn't matter there's no consequence to you applying and someone turning you down even before the interview and if you get the interview then that's good news because that gives you a chance to show this experience you have is actually relevant and you could be successful in it the the cost of applying

and nothing happening is so low, though, that I don't know that you need to be overly concerned about it. The other thing is, there's a dirty secret that most job requirements are pretty fungible. And all the things that say they are hard requirements, often what that is, is some person's, maybe it's the person hiring, maybe it's some HR person's ideal version of what the perfect candidate would all have and pretty regularly that's not what actually ends up getting hired yep and people are willing to make trade-offs based on other things most of the time my experience has been that the hiring manager who's actually making the final decision has never even seen that job description that lists all these requirements it was written by some recruiter

or hr person yeah it's just like don't even worry about that yeah just go for it you say you want to go for it go for it yeah i mean i've been in this on the other side of this table a lot and i gotta tell you i have never put together like a perfect checklist where i say this engineer that i want has three years of x four years of y and a smattering of z i've never ever gotten that perfect candidate and the fact is very few companies i think hire that way anymore because they know that the best candidates are those that can learn on the job anyway because the technologies we're using today won't be the technologies we're using next year and so we want to find candidates who aren't locked into those things and are willing to learn new things

with us so i wouldn't worry one bit if your skills don't line up perfectly and also you're moving from based on the job description or not jobs based on the question here you're moving from a more specialized to more general software engineering role is what i'm saying like you're in web dev now you want to move to something more general that's i think easier than going into a specialty where you could get hammered in the interview process with i mean Let's say you're going the opposite direction. I'm a generalist. I want to become a web dev.

I apply for a job. And I got hammered in the interview on questions like, tell me about this DOM API or tell me about this web framework you've never heard of, right? Like, it's actually easier, I think, to move to more general-purposed software engineering roles. Yeah, that is, we have talked before about kind of the role of degrees, and that is something that a four-year degree is good at, is it can give you a broad base, which makes it easier to to do these more general moves where yeah if you if you come in a different way to

the industry generally your your knowledge is more focused on problems you're encountering and solving and if you haven't worked in a domain you might not know much about that domain so i think you're in a pretty good position to make a move like this yeah i do too like you maybe you've taken some operating systems courses or something like that and and you want to do systems engineering like good news you you know some of those concepts already so that's cool yep i say go for it what if i end up regretting my choice that's kind of a different question about when you are interviewing how do you evaluate if you will like the role or not or or maybe even i messed up in the interview and didn't evaluate the role and now i'm three months into my job and i hate it now yeah well

ask a different question we'll answer that one but i think the the short version is while you're interviewing you do need to be evaluating the company as well and you should ideally have some idea of how you like to work and what you like, because otherwise you have nothing to evaluate them against. But you should be asking questions about how they work and how you might fit in and what your day might look like and who your coworkers would be and what, I don't know, what the culture's like. Like you should be, you should be trying to find out just as much as they're trying to

find out about you so that you don't take a job and then say, well, I wonder what this is going to be like. And then just show up and kind of roll the dice. Yeah. All right. Well, did we answer the question? I think so. Good luck.

Good luck. You know, I've been thinking about which conferences to attend this year. What a coincidence. This episode is sponsored by the O'Reilly Velocity Conference in San Jose, California, June 10th through the 13th. Yeah, I checked it out. Velocity looks like a great event to learn new skills for building and managing cloud-native systems. They have a diverse lineup of 92 speakers from companies like Spotify, Netflix, Google, Dropbox, and Cloudflare. There will be talks about cloud application development, microservices, security, and of course, the darling of the internet right now, Kubernetes. It looks incredible this year. You should come to Velocity if you want to learn about chaos engineering, cloud native systems, and serverless. And you get to hear firsthand from

the engineers who have built some of the world's largest scale and highest performing internet applications. My team works in this domain, and it actually looks directly relevant to the kind of stuff we're facing right now. Really cool. You can even become a certified Kubernetes application developer while there. And you get to meet a bunch of interesting people, which is one of the main reasons I attend conferences. We worked out a sweet deal with the velocity organizers for soft skills engineering listeners you can get 20 off when you use code skills during registration i did the math and with that code you can get a pass for as low as 908 dollars right now go to velocityconf.com skills to register and use discount code skills you want

to read our next one i work well this is from an anonymous listener their name is not i work i work at a bureaucratic company where we move fairly slowly recently i've been getting more and more frustrated with our code review process but i'm not sure if this has to do with the quality of my code it can take weeks for one of my pull requests to actually get merged someone will review my work i will make changes then they will come back some days later with a new truck load of very nitpicky details that they want changed this makes me long for the days of me working at a startup where we had no code review and no testing process and it's making me sad how do you draw the line over what is reasonable code review and what is too much

um well too much is not no code review back at this startup days i can tell you what's not too much yep i've lived this very deeply where it it feels like pulling teeth to get code in and it sucks it's a morale drain and not to mention the time drain and and the extra time it takes to get anything done uh so i feel you this is this is painful yeah it sounds pretty bad what do you think they should do well i think i do think that you the listener has maybe painted a picture of this grass is greener fallacy where they're remembering this day of no code review at startups but you're forgetting all the production issues and outages and and like tribal knowledge and siloed information that also come along with not having code reviews that's the thing like you

don't care too much about tribal knowledge when there are two people on the team or whatever there's there isn't everyone just kind of knows everything except when that one person is on vacation, who's the only person who knows this bit of code they wrote. Yeah, that's true. That's when the nightmare scenario happens. And by the way, you're all on call all the time. So it's like, anyway, I don't know. This is definitely a spectrum where on the one hand you have total paralysis, can't ship anything because the code review process takes weeks and weeks. And on the other hand, you have complete autonomy and freedom to do whatever you want, throwing whatever code you want at production, which also results in paralysis eventually. Yeah, that's true. To me,

there is a missing enforcement mechanism here. I'm seeing two problems. First of all, code review response times are slow. They're long. So it's taking weeks to get your code reviewed. And then secondly, when it does get reviewed, you're just getting a bunch of nitpick, garbage, useless comments that just delay you even further. So I think maybe it's time for an SLA to get put in place where management actually tracks the turnaround time on these code reviews and has some kind of mechanism in place to ensure that they get done fast. And if they don't, people who are assigned to do the reviews get a talking to, a stern talking to. Get a finger wagged in their face. Listen, young man, have you been eating your code review vegetables? Yeah, I was going to say

that same thing that just visualizing the problem might be helpful. That's kind of like the look how bad we're doing shouldn't we do better approach there's also the other approach which is kind of rewarding or recognizing people that are putting effort into reviewing code in a timely manner but but either way some some way of showing what the cost of this is if you show kind of what the what the lag time is for getting features finished off or how long stuff sits in code review over the past week before it before it or in pull requests over the past week before it gets reviewed that kind of thing some way of of making it clear what it's costing the team i think might motivate people to improve it there might also be a broken windows thing where it's just so bad

that uh have you heard about the broken windows theory remind refresh my memory so i don't know if this is true or not but the theory is basically that evidence of things being in a bad state makes people kind of accept that bad state as normal and not do anything to improve it i think it was vaguely related to new york in the 70s or some i don't know a while ago and they they basically tried to fix all the broken windows as part of kind of cleaning up the city with the idea being that that would make people take better care of it after the fact so like if you have 100 prs waiting adding 101st is no big deal if it sits there for weeks you know Yeah. But if things are in a good state, then that one PR that sits around for three weeks is

now sticking out a lot more. So I guess that means fix the problem and then you won't have the problem anymore. Oh, yeah. Real helpful, Jameson. I think what I'm saying is it can get better over time, but it's easier to maintain than it is to fix up front. Yeah. It's going to require basically you have accumulated debt not tech debt but you've accumulated negligence debt right yeah and paying that off is going to take an extra amount of effort beyond the normal day-to-day before you can get back into a maintenance state this this stuff drives me bonkers too because there's there's potentially years of human effort just sitting there right someone wrote all this code to solve some problem and it's it's doing nothing on the shelf not only is it doing nothing

it's getting more expensive over time to actually integrate it and do anything about it right so it's it's yeah it's it's worse than useless like if they had just done nothing over those weeks you would be instead of working on that code you'd be in a better state than you are right now so i i feel this pain very deeply i hate it what do you think about this nitpick truckload garbage like when you know i now that that i like dave that part sounds great okay i'm just kidding you know i've been guilty of this in the past where i do a review i write a bunch of little comments and then they send a new revision and then i make a bunch more comments on the second revision except a lot of the things i'm commenting on were actually present in the

first revision i just yep i've done that i just didn't notice them and i think some of that is like normal. I think you just, your mind just takes time to kind of percolate on these things and then new, new ideas occur to you, but really shouldn't we be putting in a little more effort the first pass? Yeah, I think so. And that seems tied to the original problem that it's taking a long time to get reviews that it's, it doesn't feel like it's a priority or maybe they don't feel like they have time to do it. I've, I've found that the example of one person putting in a lot of effort and doing a good job in code reviews can help other people kind of set a standard where if you point out and say this person does a great job look look at the way

that they do it look at the kinds of things they do and don't point out um establishing some kind of standard of how you do code reviews is helpful and that ties into the nitpicking stuff too if it's like spacing or variable names or i don't know little fiddly things like you should you should have something to point to that says these things are in scope of the code review these things aren't and and you should push that to tooling as much as possible so that it's not a thing people spend time nitpicking over yeah and then for stuff that you can't easily push to tooling you should have some kind of agreed upon standard so that uh because the thing that gets me about nitpicking is like the pain i feel is that someone has this own standard that they feel

like should apply to other people and i don't think it's true but like if i want their thumbs up i just have to jump through these hoops that they put right so so they have this thing they feel strongly about i don't care but because they're the reviewer they have this power to say like change all these things and since we haven't agreed on kind of how we should do it in enough detail then i either have to argue with them or just do it so that i can move on right yeah i guess the the defense against nitpicking is agreeing either in tooling or some other form what code should look like what what's what's in scope of code reviews and i really like the tooling because computers should do what computers are good at which is reformatting code calling out you know

errors that are subtle but easy for a machine to find and humans should do what humans are good at doing which is focusing on the developer ergonomics the design the abstractions make sure the domain is being you know the domain problems are being solved in a in a good way and that's what review reviews should be about but it's just so easy to slip into the nitpick mindset because it's easier like and sometimes it's you know you get more volume of review and you feel like you've done a good job because now this code is all indented a little better because of your comments you know but yeah and you're like yeah it's it's easy to count the log statements that shouldn't be in there and just say like don't don't do that don't do that don't do that yes i have

reviewed the code yeah right but that's bad yeah there's also the other side is there are things you can do as a code submitter to make it easier to review your code oh yeah by providing more context around what it is doing why you're making this change i think a lot of times i see pull requests submitted that are just they have a title that's kind of like do the thing and then there's no description and then there's like 400 lines of changes yeah and then i as a reviewer have to stare at it for a long time to figure out what it's doing and why and sometimes i can't figure out why even if i can figure out what so it increases the cost of reviewing the code that's right don't make the reviewer reverse engineer the purpose of the review yeah and and it's hard because the

person who makes the pull request is they they've been thinking about this for a long time they have all this context in their head that they needed to accomplish it so it's easy to forget that other people don't have that context but i mean github has pull request templates other tools probably have other ways to do this of saying like here's the information you could include you should include when asking for code reviews and i think that should be why you're doing it and what it should accomplish and if it's visual maybe some kind of uh images or gifs describing how it works like the more context you can give the better the better people can help provide feedback on those design and and kind of human squishy things oh yeah for sure and like if there are specific

concerns you have with the approach call those out and say look like for example this is a refactor that shouldn't have introduced any functional changes so please verify that the logic still works the same as before or you could say look i chose this abstraction i don't know if it's the right abstraction can you comment on on that give me some feedback you know but and sometimes like even in the code in the code review itself i will leave comments that say like please look here how does this look to you like i did this because of x y and z but i'm not sure if it's the best way and call people's attention to it and it helps like push their mind into the right direction for the review yeah i do that a lot too if there's things that seem weird or it might be a little

bit subtle and then i'll then i'll leave little comments in the code review from me to the reviewers saying take a look at this this is why this is here this is why i made this change that kind of thing here's the other thing and i'm a little hesitant to say this because it doesn't scale but i do this anyway which is i will actually reach out to individual reviewers outside the code review and say hey could you please review my thing today you know and tell them why like i've got this deadline or whatever i'm trying to make progress and i'll kind of hassle them and be like hey would you review this and then if they don't do it for a couple hours i'll be like hey how's that review coming you know and i'll just stay on top of them and they they know

that when I submit a code review, like they're going to get bugged until it gets reviewed. And like I said, this doesn't scale because it would be a disaster if everyone did that. But, you know, I do it. So my reviews get reviewed. But please, no one else ruin this shared commons for me. Yes.

Let's avoid the tragedy of the commons. Let's just have it be Dave profits off of the commons. So that's interesting you brought that up. We actually kind of normalize that on my team and say hey you can bug people about code reviews like it's always okay to interrupt someone and say can you review this code and it's gotten a little bit better because of that there's still a little bit of way to go but i've worked on teams before that it was literally you dropped whatever you were doing to review a pull request when it came in and there were some trade-offs there but one

of the trade-offs was not it took weeks to get your code reviewed and we had all these all this code sitting there unreviewed like stuff got if if things were good stuff flowed very quickly into the code base so i i don't mind that too much as a solution and it also it can be kind of a it's kind of like hey solve this in a better way or else like you'll get interrupted all the time okay it creates an incentive system yeah that's a good way of putting it creates some incentives to fix the problem because otherwise dave the destroyer will come just blow up your precious flow time yes your inbox will be full of nothing but nags from me yeah exactly so you turn to slack for relief and what do you find more nags for me yeah so i want to go back to

the nitpick thing really quick i think nitpicks should either be rejected or adopted as some coding standard and if you see the same thing pop up over and over again you should either decide this is a thing that we should fix and write down and and hold ourselves to or we should say this does not matter and like i'm gonna just say no when you say change this thing because that nitpicking cycle the cycle of understanding it better and giving more feedback i've done and is valuable but i've also done the other cycle of just reading more of the code and finding more little like there's not a space before this comment or stupid things like that like hi i got you again yeah and and that is useless it doesn't do anything except make me feel good in the moment

and then worse afterwards yeah and and it is so demotivating to receive that as a code reviewer or a code review requester yes like it just feels like i put all this work in this thing and you're not caring about the thing you just found something stupid that doesn't matter so i think you should try to eliminate those as much as possible by agreeing on standards there's a so go the language they actually have a wiki that is a page of go code review comments and it's a bunch of stuff like that of like things that could be nitpicks or things that could be standards but they've this is kind of goes agreed list of stuff to look out for in code reviews and um i think what happens is people often just link to these and so so if you if you want to adopt this as

your standard you kind of read through it and see how it works and then ideally you make those things happen before you submit the code review and and uh you avoid this nitpick cycle by just meeting all these standards basically that is cool i like that and isn't it a weird mindset you get in as a reviewer when you find a knit and you're like oh found something you mark on you make a comment on it and then you're like you know i think i might be done now you know like yeah my work here is done i pointed out the comment was too long that line too long and then it's like check it's like the ultimate way to just absolutely delay a code review but at the same time it like you do have this weird like human nature thing where you're like okay

i made my contribution i'm gonna move on i got an inbox full of crap to do you know yeah it's like i look like i gave it some effort yeah one one other thing i've seen happen is there's disagreement and it's unclear how to proceed and no one wants to push hard one way or the other and that causes stuff to just be left so a person submits a request for a review someone reviews it and says you know i think you should change this thing about it and the person asking for the review doesn't necessarily agree but they also don't say like nope i'm not gonna do that feedback ignored like merge you know right it just gets left in this limbo state and i've seen that quite often where it's it's not really clear how to proceed so stuff just sits there and you get kind of

paralyzed and i think you you need to be aggressive about resolving that impasse like that is blocked and you should resolve blockers quickly and that doesn't mean you have to be aggressive and say people are dumb and wrong and call them jerks and be rude and stuff but you should you should recognize when things are stuck and move to unstick them instead of just saying well i don't quite know what to do about that so i guess this will just sit here i'll go fix some unimportant bugs for a while yeah i'll you know let me just do something else instead and then it's been three years i think i think a good mechanism is that when you can't reach quick agreement in code review comment you should call an in-person or live meeting right away and just work on it because

what i found is that a five to ten minute discussion can often resolve something that would otherwise have taken hours because of the latency involved in turning around comments on a code review site yeah i like that well have we solved the problem oh yeah this is definitely solved good news is once you solve it then it won't happen any anymore yeah and some of this might be inherent like this says the caller or the listener says it's a bureaucratic company and it's like well if that's kind of baked into your culture then there might be a certain amount of this latency that just is inherent unfixable yeah i mean if you if you have really long release cycles or something maybe there's not that pressure to get stuff yeah out if you're not

going to deploy it right away anyways what does it matter but i think you you could if you want to it you could do some work to pitch this as a better way to live it's just more satisfying when your stuff gets done so true and gets gets released in some form even if that form is just you don't have to worry about merge conflicts just in the back of your head forever it it just feels nice to be able to move through things and this can help you do that and and it's kind of like you know those trust exercises where everyone like lays back on the other person's knee or whatever and you make little circles, everyone's supporting each other.

It does seem like a little bit of work to put code reviews into part of your process and workflow and spend more time on it. But if everyone does that, then you're just moving faster. You're all kind of supporting each other, even if you're taking a little bit more time than you did before to review all these changes.

What a beautiful metaphor to close the show on. Thank you. I've just been thinking about summer camp. It is summertime. Yep. All right, we helped. Good job. Good luck. What should people do if they want their own questions answered?

Go to softskills.audio and click on ask a question. You can fill out as much information there as you like. Thank you so much to everyone who has done that. You are the lifeblood of the show. If you want to support the show, feel free to click support us on Patreon and join the illustrious list of people who support us. As little as a dollar a month will be beneficial to us. And also, if you can, follow us on Twitter. We are softskillseng on Twitter. You can follow us there we occasionally tweet interesting things and episode announcements as well as you can support us by leaving a rating on your favorite podcast app thank you so much we'll catch you next week