How to Create PRs That Get Merged The Same Day

Quick takeaways

• Prioritize reviews over new work - treat PRs as work that’s almost done and needs to be pushed to production quickly
• Big PRs create a deadly loop - when reviews take ages, developers make even bigger PRs to avoid multiple long waits
• Knowledge sharing is the hidden benefit - code reviews aren’t just gatekeeping, they spread understanding of how things work across the team
• One-day cycle time is possible - start work in the morning and merge by end of day with proper team culture and practices
• Split work vertically and horizontally - break features into small slices and layers that multiple people can implement in parallel

Introduction

In this episode, we discuss how to make code reviews fast and effective by keeping pull requests small.

We explore why big PRs are problematic, what causes them, and practical strategies to create PRs that can be merged within a day.

Instead of waiting days for reviews with 200 comments, we focus on techniques that help teams achieve smooth, fast review cycles where work flows quickly from code to production.

Show Notes

• Feature flags - technique for merging code that’s not ready yet
• Mob programming - multiple people coding together with one driver
• Clean Architecture - helps with splitting features layer by layer
• Linters - automated tools for catching style issues instead of nitpicking in reviews
• Draft PRs - for getting early feedback on experimental work
• Shadow mode - running new code alongside old code to compare results
• The Phoenix Project - book mentioned about bottlenecks in teams

Quotes

If you have a couple developers that are independently working on some features, they are actually not a team. They are a set of individuals working on something. And at the end, there is no shared responsibility to deliver some features.

It’s a well-known phenomenon that if you have small PR, people will find three defects, but if you have huge PR, they will just write LGTM.

I like the phrase that five days of coding can save one day of planning. And I think it’s often true and it’s often a problem in multiple teams.

I sometimes see people mention that code reviews are a sign of lack of trust. As in, “You don’t trust your teammates because you need to review code they write.” I think it’s funny because I find it the other way. So I actually trust them to review my code because I don’t trust myself enough to know I don’t make any mistakes.

I think it’s one of the most important skills for product engineering, and I think it’s super rare as well. Because most developers, when they get a clear description of a problem from a stakeholder, will just say, okay, we can do it, because they want to be the hero.

I know that a lot of people are like, let’s skip planning, let’s just write that and ship that and it will be everything fine. And I know that I was also like that when I was younger and less experienced, but later you can kind of learn that, okay, it can give you some acceleration at the beginning, let’s say, but later it can be very problematic.

Timestamps

• 00:00:00 - Introduction
• 00:01:43 - Why review code
• 00:07:12 - Problems with big PRs
• 00:16:13 - Causes of big PRs
• 00:23:27 - Planning importance
• 00:35:17 - Breaking down changes
• 00:44:35 - Big refactoring strategies
• 00:52:43 - Code review culture
• 01:04:24 - Accelerating review cycles
• 01:12:04 - Q&A session

Transcript

Robert [0:00]: Ever waited days for Code Review only to get 200 comments and endless discussions in these PRs, so maybe you wonder what’s the reason of this kind of big PRs and why it’s happened that such big PRs are happening.

Robert [0:18]: And what’s often the problem, it’s getting worse. I mean, when you are waiting ages for PRs to be merged, it’s creating some kind of dead loop, let’s say.

Miłosz [0:33]: It gets even worse.

Robert [0:35]: It gets even worse, because if you know that you wait ages for merging a PR, you are just making them bigger, because you know that if you prepare 10 smaller PRs, you will wait longer for those PRs. Today, in this live podcast, we’ll discuss what are the problems that are causing that PRs are big and some strategies that we used in our teams to make those PRs merged much faster. So by much faster, I mean how to create PRs that are merged within a day. So let’s imagine a scenario when you are starting to work on some task in the morning and it’s merged by the end of the day. Sounds like a perfect word that doesn’t exist, but our experience is a bit different.

Miłosz [1:24]: Can’t be possible. This is our last live episode, so feel free to leave comments in the chat, or we’ll pick them up during the discussion, or at the end we’ll have a Q&A section. So let’s kick off with why we need to review code code at all.

Robert [1:45]: Yes, I think it’s important to start with the fact that a lot of people are tracking code review as gatekeeping, so basically to ensure that changes that are not, expected are not merged. And I think it’s bad. It’s a bad sign if code review is kind of gatekeeping. So from my experience, if code review is gatekeeping, it usually means that you didn’t make a good job earlier on agreeing how things should be implemented. So it’s a matter of some good practices in the team, but it’s also a matter of designing things. So in other words, if you spend time earlier on planning that, it should be not a surprise what’s in the PR.

Miłosz [2:37]: So if someone opens a PR and they start wondering what exactly it is about, then maybe it’s too late. Maybe they don’t have enough context and they want enough to review it in a reasonable pace. I sometimes heard of people starting PRs with checking out the code and running the applications, trying to understand what’s going on. I think we can agree with this. This should be an anti-pattern, unless something unexpected happens, like your team is busy with something else, I don’t know, you ask someone else from outside the team to review your code. But most of the time, you should know beforehand what the PRs will be about.

Robert [3:30]: So, if it’s the case…

Miłosz [3:32]: It’s a perfect word.

Robert [3:34]: That can exist, but we’ll go into that a bit later. But if gatekeeping is not the reason why you are doing code review, it should be some reason why you are actually doing code review. And from my perspective, one of the most important reasons why you are doing code review is the knowledge sharing. And I think it’s not mentioned very often, and I think it’s some kind of hidden advantage that maybe we don’t think that often. But this knowledge sharing is important because when you’re doing review, you’re learning how something is implemented, and it’s helping to spread this knowledge how something is implemented in the team. And it’s pretty important because if you’re spreading this knowledge, it’s easier later to extend this functionality by more people in the team.

Miłosz [4:25]: Because you know where to look for changes if you need to extend them or implement your own feature.

Robert [4:31]: And while usually it’s not the best idea that one person has some area in the code and just this person is touching this code, well, I’ve seen it sometimes in my life. And okay, while in the short term it can be a good strategy because this person really knows how this code works, but at some point it may not scale if it will be more functional to implement there. And the problem starts to be a problem at this time.

Miłosz [4:58]: Also depends how big your team is. For smaller teams it’s probably optimal because if you have a small PR, everyone can take a look and have a rough idea what you are doing. The bigger team is probably a bit more complex, because not everyone can see each PR in progress.

Robert [5:22]: Definitely. But still, if you have a bigger team, we’re not talking about, for example, five people. Because I think if you have five people, it’s a bit easier to share this knowledge and be in the stage that everybody knows what’s done. But for example, if you have 15 people, it’s a bit harder and obviously it doesn’t make sense to not share for everybody. But I would say that if you have some subset there, that makes much more sense.

Miłosz [5:49]: I sometimes see people mention and code reviews are a sign of lack of trust. You don’t trust your teammates because you need to review code they’ve write. I think it’s funny because I find it the other way. So I actually trust them to review my code because I don’t try to trust myself enough to know I don’t make any mistakes. So it’s good to have another pair of eyes. Just take a glance and very often they will have some context you missed. If we had no comments on PRs, we would just stop doing them. But they come useful.

Robert [6:30]: In other words, you should not look on PRs like gatekeeping, but rather something positive that can help you to improve your stuff. I think it’s also important that it shouldn’t require from the reviewer to verify the changes, because I also heard that some teams were doing it like that, that somebody is doing or doing review and verifying if it’s worked properly. I think it’s probably more your responsibility to ensure that the functionality that you implemented is working.

Miłosz [7:02]: Sounds a bit like QA, but anyway, you should be doing QA on your own code. so all right um

Robert [7:12]: Okay i think let’s maybe start with why having big prs is a problem because i think if you are working with software most of people agree that it’s big elephant in the room that big prs are problem but i think a lot of people are not doing anything about that like yeah big prs are bad, but whatever.

Miłosz [7:34]: Or they just say out loud, okay, guys, let’s not do it again.

Robert [7:38]: Let’s not do big PRs.

Miłosz [7:40]: But then it always happens. For me, the first one is the most obvious one. It’s just hard to review. It’s a well-known phenomenon that if you have small PR, people will find free defects, but if you have huge PR, they will just write LGTM. And, yeah, I think we know this paint well. It’s very easy to just glance at a huge change set and not go very deep into the details.

Robert [8:17]: Obviously, we’re losing in this scenario the knowledge sharing that we mentioned at the beginning. If you have really huge PR, there is no way that you’ll read that and that you’ll be able to learn from that how it works.

Miłosz [8:32]: Exactly. And then all the processes like reading, understanding code, comments, and whatever else goes on in the PR just takes longer. And no one likes long discussions especially asynchranos so if you take a huge PR and then on top of this you have 50 comments that will take ages to review and if someone spends weeks or longer working on this PR and then you drop 20 comments on it they are probably not eager to to listen to what you want to say, your suggestions.

Robert [9:19]: You’re just thinking, I would like to get it out as soon as possible.

Miłosz [9:23]: I just want to be done with it and push it through to prod. So, yeah, it’s probably not encouraging to change this. It becomes kind of like an artificial review process but doesn’t give you much.

Robert [9:38]: Probably in this case, it wouldn’t change much if you would not have any cool review. The chance we can push to mine and… Yeah, exactly. Yeah, and another problem with big PRs is that, as you said, when you have the situation when, we are working on this PR for longer time, it’s a big chance that you receive 20 comments and okay, it depends on the team, but usually it may end up with a big rework of the job that you’ve made. So in other words, you will lose a lot of time on writing this code and you’ll lose a lot of time on rewriting it later.

Miłosz [10:20]: And you are very late in the process because someone spent already a week or two writing it. And now if you want to rework it now, it probably will be a huge change.

Robert [10:32]: And even worse, probably in the meantime, when you were working on that in your basement, people were doing other changes and you probably will have a lot of conflicts. It’s even more funny if other person in the team have PR like yours and this person merged it earlier. Okay, if you are not a lot of people in the team, you can always not review this person’s PR, so you are safe that it will not introduce conflicts. But you see the problem, the conflict of interest. I mean, it’s also problematic for you if the other person is merging some big PR, so you are not doing a review for this person because it’s too late for your PR.

Miłosz [11:10]: Or you’re raised to do it first, so you don’t need to deal with conflicts.

Robert [11:14]: Or you can add a lot of comments, so this person PR will be also blocked, so you can merge your PR first.

Miłosz [11:25]: And then, when the conflicts happen, you get an approve and you think it’s ready, and then you just resolve the conflicts. And two hours later, you are finished, but it takes time to do something more productive. So just spend time on maintaining this PR instead of writing code. And this merging can also introduce new bugs or challenges that no one reviews, so it’s another risk.

Miłosz [12:03]: There’s also a longer feedback loop, because communication is asynchronous in the comments, so someone gets sick or has days off, you need to wait for them, they come back, they lost some context, we need a separate discussion about all of this. And also that’s a paradox people might think that small PRs require context switching because you have to very often review code and review what you are doing but in reality big changes are even worse because of this because you need to every time you come back to it you need to refresh this huge context in your mind instead of something very small. So that’s another one. And also if you want to stack PRs, so you want to branch out of an existing branch because you need the changes in there, which is often useful. With small PRs, it’s quite easy to do, not risky, but with big PRs, you block everything. The big PR gets merged.

Robert [13:20]: And later you have PR that depend on PR that depend on another PR. And if the first PR in the chain will need to be changed largely, it’s just an horror to keep it up to date. I have PTSD if I think about such PRs.

Miłosz [13:40]: And then someone asks when this will be done and says, Yeah, we only need to wait for Robert’s PR to be merged. We’ve been waiting for two weeks now, so at the moment. Yeah, we’ve seen it too many times. And other ideas? Yeah, this lack of visibility is also risky because… If you don’t know when the feature will drop, because a PR takes us long to merge, you may be tempted to use estimates, which is also problematic, but this comes from the fact that no one knows when something will happen. You have this huge PR, which seems almost ready to merge, but you keep being added to it and discussed, and you just never know when it’s finished. And the worst of all, you can create a long-living branch. One that takes three months or so to merge. And it’s a completely different version of the software.

Robert [15:03]: It keeps living in parallel.

Miłosz [15:07]: If you ever work with this, you probably don’t want to do it again.

Robert [15:12]: So, it all sounds bad. I mean, there are multiple reasons. Why we should not do big PRs, but from the other side, for some magical reason, from my experience, having big PRs is very often the problem in multiple teams. And there are a couple of things that I believe are creating big PRs. And again, I think it will be mentioned multiple times in this episode that, in my opinion, we very often have good intentions, but despite that, the problem still occurs. And the same is with big PRs. I think that’s why it’s important to be conscious about what can cause big PRs. I think one of the things that is coming to my mind at the beginning is that we have some kind of complete feature mindset.

Robert [16:13]: We like to create a feature and have it work on production ASAP. So it makes sense that we’re working on something, and it’s just nice when you write that and it’s going directly to the production. And it sounds good, but unfortunately often features are not that simple that we can easily implement it within one PR. If we’ll try to do that, okay, maybe someone sometimes will estimate that, yeah, it’s just one day of work. But how often do you think that something is one day of work and it’s ending up with a week of work because there is some hidden complexity that you didn’t take into consideration at the beginning.

Miłosz [16:54]: And splitting it seems like additional work. So you might be tempted to avoid it. You wouldn’t want to go. It should be easier, right?

Robert [17:05]: Yeah. And I think it’s connected to, planning, but In many cases, when we’ll discuss about causes why we have big PRs, it’s connected to how we plan things, how we did some shortcuts maybe with planning, and I think often big PRs are connected to some surprises that we are creating. So what I mean by that is that…

Miłosz [17:37]: So-called missed requirements?

Robert [17:41]: Yes, yes.

Miłosz [17:51]: If we don’t know some edge cases before we start the work, then you’re in progress of working on a PR, you discover something new, you have to stop, maybe discuss with someone else,

Miłosz [18:05]: and then it starts to get tough to push through. Because you put some work, you started some writing some code already, it’s half done, but something blocks you.

Robert [18:19]: Yeah, and obviously, if you include something like that in the PR, if somebody will be reviewing that, it will be kind of surprising. Even if you have some planning process at the beginning, if some person is reviewing your PR, this person might be surprised. I mean, okay, we’re planning this, but why does PR have this, this, that, and this? And this is triggering discussions. and discussions is triggering a slowdown of PRs, basically.

Miłosz [18:50]: Yeah. Sometimes, if PRs get reviewed slowly in general in your team, you may think, like, no, it makes no sense to… What happened?

Robert [19:08]: Oh our camera died.

Miłosz [19:12]: Yeah, so let’s maybe take a minute break.

Robert [19:20]: It’s tough. Yeah. So, this episode is special in a couple dimensions, because the first fact is that our room that we usually are using is used, so we were not able to use that. And our camera is overheating, so…

Miłosz [20:01]: Great. Summer is there.

Robert [20:02]: Summer is there. Cool.

Miłosz [20:04]: So, as I said before…

Robert [20:06]: What do you see? It’s live. if it’s not pre-recorded.

Miłosz [20:10]: So if your PRs get reviewed slowly in general in your team, you might think like, okay, it makes no sense to quit additional PRs because I will wait for all of them for a long time to be reviewed. Maybe let’s just make a bigger run and review it once.

Miłosz [20:30]: But again, the huge PR gets reviewed even slower. So it’s not a good solution really.

Robert [20:40]: And I think it’s also one anti-pattern that I often see. It’s the teams that are not real teams. What I mean by that is that if you have a couple developers that are independently working on some features, they are actually not a team. They are a set of individuals working on something. And at the end, there is no shared responsibility to deliver some features. So, if you have no shared responsibility to deliver features, it’s hard to convince somebody to read your PRs, basically. Because nobody cares.

Miłosz [21:16]: It’s not their job.

Robert [21:18]: My job is to implement my features and save you.

Miłosz [21:22]: I don’t want to spend time on your work, because I’m responsible for mine and there are stakeholders waiting for my work to be done.

Robert [21:32]: Exactly, exactly. And I think it’s a big problem, because if you are not working as a team, but a set of individuals, well, there is no pressure or nobody feels obligated to review stuff.

Miłosz [21:50]: Yeah, so in this case, review is not the team’s responsibility. Basically, no one’s responsibility. Just beg people to do it for you. That sounds like an issue. You can see the setup when there’s a feature mentioned and some stakeholders know to which developer to talk to about it. Because they are seen as owners or masters of this area. This is one of the indicators, I think, that this happens.

Robert [22:33]: We already covered a couple reasons why having big PRs is a problem and how big PRs happen. I’m not sure if you agree with me, but I think one of the most important parts here and reasons for them is lack of planning, basically. Maybe I would say deep enough planning. I like the phrase that five days of coding can save one day of planning. And I think it’s often true and it’s often a problem in multiple teams. I mean, we’re sort of developers, engineers, we like to solve problems with the code. So if we hear about planning, meetings, no, no. Yeah, yeah. It’s always like, no, no. Yeah, yeah. Talking to people, especially non-developers. We are pretty allergic to that.

Miłosz [23:27]: Especially after you hear about the future, you already have a database schema in your mind. You already know how to solve it. All you need to do is just sit down and write.

Robert [23:40]: Yeah, and I kind of understand why people are allergic to deep learning, but from other sides, I think it’s also creating a lot of problems. And often it’s visible in CodeReview, because I think a lot of people are blaming the CodeReview process for many things like code review is such bad, it’s such a waste of time, it’s taking that much time. But I think in previous episodes, we also sometimes had this, let’s say, non-direct, visibility of some errors. So for example, some people are blaming DII for making complexity of the applications because dependency injection is so complicated, etc.

Miłosz [24:30]: So it’s like the tip of the iceberg. Yeah. Everything is the issue, but underneath there’s some more complex issues.

Robert [24:36]: And I think it’s a similar case with code review. A lot of people blame code review for a lot of bad things, but I think it’s just surfacing other problems that you have in the team. For example, if you have, I don’t know, 200 comments in the code PR that you submitted, Probably a good question to ask. Okay, why you have 200 questions there? Why you didn’t agree on that earlier before you started implementation? Because when it’s already implemented, reverting that, changing that, it will be super expensive. If you spent more time a bit earlier during planning and planning properly, probably you’ll waste much less time. And I think it’s not about always planning everything for 100% to not have an unexpected complexity, because it will always happen. And trying to plan that accurately, it will be super expensive in terms of time. But I think it’s, from our experience, we see that spending more time on planning, it can definitely…

Miłosz [25:47]: It’s easy to change the whiteboard. you erase it and rewrite it. It’s much harder to change a 10,000 long 10,000 lines long PR with 100 comments. The earlier you discuss things and agree on how to do it, then the easier you iterate this.

Robert [26:11]: I know that a lot of people are like, let’s skip planning, let’s just write that and ship that and it will be everything fine. And I know that I was also like that when I was younger and less experienced, but later you can kind of learn that, okay, it can give you some acceleration at the beginning, let’s say, but later it can be very problematic. Because, again, you lose many of the advantages that you will have from this code reveal. Knowledge sharing, or if you are doing a kind of more strict process of code reveal, it will be just blocking at some stage, because this stupid approach will be at some point, probably will go with some strange direction that you didn’t agree with somebody else, and it will be just surprising the PR, the surprise that we were mentioning a bit earlier. And again, PRs shouldn’t be surprising, so it should be implementation of what you agreed on high level earlier.

Miłosz [27:16]: Yeah, so it’s another paradox. You save time on planning, but in the end, you spend even more time on the reviews. Just like with the paradox of context switching, when you think smaller PRs cause context switching, but actually the big PRs cause even worse.

Robert [27:40]: And yeah, I think it’s interesting because on the first side, my thing that, yeah, splitting to multiple PRs, it will just add a lot of overhead and it sounds not logical to have multiple PRs instead of one big, but I think what I can recommend is trying to try using smaller PRs and see how different it will be. Obviously, it requires a team culture that supports that, because if you create 10 smaller PRs and nobody will review it kind of immediately, it will not help. And you cannot do much about that, and probably you will end up with big PRs at the end anyway, because it will just start to stack. So yeah, it wouldn’t make sense, but we’ll go into that, what you can do in the team to encourage teammates for a quick review.

Robert [28:40]: So, yeah, we started to mention that missing enough planning obviously can help to create bigger PRs. But again, it’s also important to not go into extreme, because I think it’s also easy to go into really extreme and try to plan for everything, to go really deep into the planning. But it will be very expensive to do. I think it’s probably not a possible event because without touching the code it’s really hard sometimes to find all edge cases and complexities that you have.

Miłosz [29:16]: The balance is in deciding what you want to agree on. For example, we skipped on most implementation details like exact database schema or naming of things. That was up to the implementer most of the time. High-level architecture, like what endpoints do you want, what services this impacts, and so on. Some very high-level picture of it, that’s super useful to have early.

Robert [29:47]: I think it’s all about this non-surprising PR at the end. To think what you should plan earlier, to not surprise the reviewer when you are reviewing that. And if you were not working like that earlier, obviously, it will take some time to learn how to do that. But I think it’s a skill that you are just getting with time. You’re implementing more, you’re learning more how, okay, this is surprising somebody in the PR. Okay, maybe we should raise it during that.

Miłosz [30:20]: Next time, let’s agree with what endpoints they will be exposed. This is a quick discussion, right? Of course, it’s better to have before any code is written. Like, do we want endpoint in this service, or do we want a message handler in this service? High-level, that can take 5 minutes. But after someone implements it, we can make one hour to revert and replace it. Or even worse, if the discussion is asynchronous.

Robert [30:52]: Another thing that it’s worth doing is also including in the planning discussion some product person, let’s say. So it depends on each company how it looks like, but often you have some, maybe not stakeholder, but maybe some product owner or product manager or whatever. And it often may be helpful. So obviously it’s required not to have some discussions that are not super technical because this person will be just bored and this person will not understand anything.

Miłosz [31:23]: So they will do it first. First understand the product.

Robert [31:28]: But I think it’s nice because it also can help to cut scope a lot. So I remember that And often when we are doing it like that, we included product people during the planning phase. So when we have some planning meetings and we have this product person in the meetings, it sometimes helped a lot to simplify scope. Because we started to discuss some features, but we had like, okay, it will be very complicated because this, this, and this. And the person in the same room said, okay, so if it’s complicated, we can just keep that because it’s not that important. And sometimes you can lose hours as a developer to try to figure out some super complex problem, but at the end, nobody will care that much.

Miłosz [32:11]: I think it’s one of the most important skills for product engineering, and I think it’s super rare as well. Because most developers, when they get a clear description of a problem from a stakeholder, will just say, okay, we can do it, because they want to be the hero and show, and we’ll be like this.

Robert [32:32]: And we are problem solvers, so if we see problem, okay, we need to solve this problem, it will be so cool.

Miłosz [32:38]: Especially if it’s well defined, if you have all the requirements and so on, you might be eager to just jump into it. You will tell them, okay, we can do it tomorrow, no problem. They will be like guys you are the best team in the company but then you get stuck on these complex cities and you need to talk to the stakeholders again and it takes a long time to read about everything So, I think it’s a super important skill to be able to pull them early to the discussion and see where you can cut the scope. Or, even if it’s not out of scope entirely, just find the V1 you want to deploy. And that’s super useful to have.

Robert [33:28]: And I think we’re often kind of missing this, that we are implementers of some

Robert [33:35]: external requirements and again, we’re trying to be heroes or.

Miłosz [33:39]: I am just a developer tell me what to do and I will do it so that’s a common approach and E-definance because you can just trust people know what they want to help them figure out what exactly it is they want so basically,

Robert [34:01]: One unexpected strategy to make your PR smaller, implement less things.

Miłosz [34:08]: Yeah, or start with less. That’s maybe more precise. Try to start with a small scope.

Robert [34:17]: But sometimes it’s not possible. I mean, sometimes we’ll ask product master or camera, right again. So, okay, can we simplify that? No, you can. So, what’s the strategy in this case?

Miłosz [34:34]: I guess, breaking down changes, right? So, our ideal scenario would be having PRs that are implemented within one day. So, as you said at the start, someone posts a PR in the morning, it is merged on production in the afternoon. Something like this. This cycle time would be ideal.

Miłosz [35:09]: And there are actually some strategies you can use.

Miłosz [35:17]: Probably the simplest one is to merge code that’s not ready yet. behind the feature flag. But it’s critical that you’re able to manage feature flags in your project one way or another, even if it’s just some configuration. But it allows you to merge the PR, so it’s already on production, even if it’s used. But you avoid these discussions and conflicts, and so on. We just work on the code that’s already on the main branch. Even if not exposed yet. And you can have the tests running, you can enable it on some pre-production environment, you can show it to stakeholders in some very early form, some MVP form, and get some early feedback from them. So that would be my number one for breaking down changes and for small PRs.

Robert [36:30]: Another thing that comes into my mind, it sounds pretty obvious, but basically to have some discussion to some RFC, ADR, some design document, and basically discuss it with the rest of your team and have some plan how we can lead it to some smaller parts. We already mentioned it multiple times. So, I think this magical value is one day that I know for so many people, it sounds like, no, it’s not possible to start implementation in the morning and merge something by the end of the day and not working until midnight. I mean, I know that for some people it sounds crazy, but it’s very possible.

Miłosz [37:14]: Yeah, I remember having five minutes cycle time. If it’s small, you can just ping someone and then take a look and in 10 seconds you get an approve.

Robert [37:26]: And the rest of the people is aligned because you spent some teamwork to discuss how it should be implemented. And it’s not surprising for people. So somebody can take a look quickly on that. See, ah, yeah, it’s what we discussed. Looks great. Merging.

Miłosz [37:43]: And because it’s merged, for the next PR that’s built on top of this, Those changes are already out of context, so you don’t spend time discussing them, but that’s your dream.

Robert [37:57]: Do you have maybe some tips from our experience, how you can split this work

Robert [38:01]: to make it working nicely?

Miłosz [38:05]: Yeah, so you can either split vertically or horizontally. And both kind of make sense. Probably vertically makes more sense at first, so instead of big chunks of the feature, you’ll deploy small parts of it. So for example, you can… Let’s say if you beat a dashboard or something like that, you can deploy just one chart or one button. And the endpoints behind it and so on. So it’s something you can deploy, for example, on staging environment or even in production. And show it to your stakeholders and ask them, is this what you want? It can be a very simple feature, part of the entire feature, but it’s already something you can ask them about.

Robert [39:03]: Yeah, and I think you can go even one step further because, okay, you can have some vertical slice to prepare a chart, but often though vertical slices of entire functionality, it can be still pretty complex. You can also slice this vertical slice horizontally. For example, have separate tasks for SQL repository. So it works pretty nicely with clean architecture that we’ve been discussing in the previous episode, so I recommended to check it out. What Longstar showed is that it helps pretty nicely with splitting these features layer by layer. So it can be implemented by one person or by multiple people, and you can implement… Again, it’s good for more complex features, because for some features it doesn’t make sense to split that because it will just use a solar head. But if it’s a more complex feature, let’s say that it’s one week work for one person. You can always split it by layer. And for example, every person in the team can take one layer. And instead of implementing something for an entire week, you can have five people that are just separate slices with a grid API layer, and it can be even implemented within a day. And it’s cool, because you can show it to some stakeholders after this day and ask, okay, this is something but yeah? No? Okay, so let’s iterate on that. And it’s much, much, much faster.

Miłosz [40:24]: Yeah, I think it’s another superpower that’s very rare in tech teams in general. It gave you to work in parallel on a single feature. More often you will find this approach of, okay, so this person is responsible for this feature, see you again in two weeks on the Spring demo.

Robert [40:41]: And usually it’s not two weeks because there are some challenges or block errors.

Miłosz [40:46]: So instead, if you can agree on the interfaces, then one person can implement the HTTP handler, the other one the message handler, the third one the database adapter, something like that. And it’s quite simple, because you agree on the interfaces first, and then you implement them. It’s really straightforward, and we know it works because we’ve seen it live.

Robert [41:11]: And we have some comparisons. It was a process that we worked over a time, and we have comparison how it worked earlier, when we were not doing splitting, and later, when we did the splitting, and we were able to iterate that fast, and it was cool.

Miłosz [41:27]: Except both vertical and horizontal, splitting is not that easy. Maybe the horizontal is easier because it’s a technical one, but the vertical split is related to product so you need some product sense to understand which features make sense at all and you need to discuss it with someone probably to understand better Oh no,

Robert [41:50]: Talking to people.

Miłosz [41:51]: I think it’s worth doing I’m just saying, I think it’s rare because it’s not trivial you need some effort from the engineers to do it

Robert [42:01]: But after you learn that, and the team will learn that, it’s…

Miłosz [42:05]: That is quite natural, yeah. For sure you can learn it. The entire teams can learn it. And yeah, it will be the best if, side note, there’s no single team lead doing this, but it’s encouraged so everyone can own this with time.

Robert [42:25]: And I think it’s another, we again see the same pattern, that it’s some kind of overhead myth here. You may think that, okay, cutting it by horizontally and vertically, it’s that much overhead for that. But it’s not logical that in theory it will require more time. But from the other side, if you will not cut that and one person will implement that, for some magical reason, it will take longer anyway at the end, even if there is some overhead by cutting that. But if only one person is implementing that, this person may be bored, may have other interruptions, context switching. So at the end, there is also some hidden cost of one person doing all entire work for two weeks. And if you add all the complexities that we mentioned with the non-splitting PRs, but having one big PR instead, it’s starting to be much, much, much harder and take much more time. And again, at the first sight, it may sound like it’s requiring much more effort, but I recommend to check that because after you see that, you can see that in practice, it’s much, much faster. the planned things.

Robert [43:51]: But you may think that, okay, it all sounds nice, but it’s not possible to split all functionalities that are maybe okay. Those functionalities are a bit easier. You can probably split most of them, but sometimes there may be some work that is not possible to split. And the first thing that I have in mind is some kind of big refactoring. So, if you’re doing some big refactoring in a project, sometimes it may be hard to split that. So, I like to compare it to Fatality from Mortal Kombat. So, you know, it’s like you’re getting backbone and, you know, it’s getting all the bones.

Miłosz [44:35]: So, there are lots of unknowns. You just don’t know what you will find.

Robert [44:39]: Yeah, but I also mean that sometimes touching one thing is creating some kind of domino effect. So you touch one thing, but to make it work, you need to adjust a lot of things in the project and need some kind of atomic change at the end. So if you touch that, you probably need to spend one week to just fix everything. And it’s, I think, also a pretty interesting case how to deal with that. Because, OK, this one person can do this big refactoring for a week or two weeks. Later, give a PR and, guys, can you review that? Because, you know, it’s important refactoring. If you are looking at, hmm, okay, two weeks of work, 2,000 files changed, 200,000 lines of code added, the same removed, okay, good luck reviewing that. So, one of the tactics here may be, okay, it just, okay, sounds good, let’s merge that. But I think it’s not the best, because usually you can end up with some brain changes in the code base, and everybody later will be, maybe not surprised in the PR, but surprised if somebody will be, because I’ll take something like that.

Robert [45:48]: So, do you have some examples from our teams? What we did in such scenarios to avoid this? I think probably it happened to us multiple times to do this big PR and close eyes and okay, let’s merge that, whatever. But I think it maybe wasn’t a disaster, but it wasn’t the best strategy.

Miłosz [46:11]: You can try mob programming.

Robert [46:13]: Sounds like an app.

Miłosz [46:14]: If you are brave.

Robert [46:17]: So, what is mob-programming? Because I think a lot of people may not know mob-programming. So maybe some of you know what spur-programming is, but mob-programming, I think it’s much more exotic.

Miłosz [46:30]: It’s spur-programming, but more than a pair. It’s basically a group of people coding together, and one person is the driver with the keyboard, and the rest comment and observe. It’s very similar to per-programming except there’s an entire team, if it’s small enough. Like people, I’d say. And yeah, and you take turns coding and implement the feature together.

Robert [47:02]: Sounds like a big waste of time, isn’t it?

Miłosz [47:06]: Yeah, like all meetings. I think we should all code alone,

Robert [47:12]: Not discuss it in the basement.

Miłosz [47:16]: Yeah, so for many, maybe not for many, but for some kinds of work, this can work well. Because of the knowledge sharing, primarily. So you don’t need to waste time reading PRs, especially if they are big, because we do some refactoring or scaffolding of the project and so on. Instead you do it together. So for sure it doesn’t make sense to do everything like this. If you implement an HTTP handler, there’s probably no need for four people to watch how you do it. But if it’s some critical domain code or some huge refactor, it’s probably quicker this way than if everyone reads the PR separately and comments.

Robert [48:06]: I think it’s probably good to consider alternatives, if you are thinking that it’s a waste of time. Because, okay, what are alternatives? So you can probably just close eyes and merge these big refactoring PRs. It’s some solution, but usually it doesn’t end up well. Sometimes, okay, the person that created this big PR can arrange some meeting and show some highlights of how this feature or refactoring was done, it’s probably a bit better, but still, it’s no way that you can go over, entire thinking process that you did in one or two weeks of development.

Miłosz [48:50]: So you need to consider if it makes sense.

Robert [48:53]: But do you have maybe some tips how to run more programming sessions to keep it efficient? Because you have an entire team in the room, potentially, maybe on the call. I think it’s harder. I mean, I think it’s easier to do it in person, but…

Miłosz [49:12]: Everything is harder on the call. So watch out. But yeah, if you do timebox that should help, so make sure there’s no one-person coding, but you switch seats.

Robert [49:24]: Yeah, I think it’s very important because it’s easy to end up with a situation when one person, sometimes some team lead or whatever, is coding everything and everybody is looking on their phones to update the code because it’s…

Miłosz [49:38]: So I need to keep everyone engaged. Don’t speak away. Watch out for CO2 levels in the room if you use a room make sure your team knows the process and everyone is aligned for example a big risk is if you let people drift into a topic and start discussing every line in the code that can end up terribly I think it works best if your team has been working together for a while. They know each other and I remember we had sessions with some new joiners to the team and that wasn’t going that well because they were not aware of some patterns we were using. They questioned everything.

Robert [50:37]: Yeah, so I think it’s good to have some facilitator.

Miłosz [50:41]: Exactly, you need some heavy facilitator. We can cut discussions.

Robert [50:46]: I remember that what often works for us was that, okay, if we’re parking some discussions, sometimes we left a task for that, and this task could be done asynchronously. Because, again, running a session for an entire team is just expensive in terms of time, basically. And you need to be sure that you are using this time very efficiently.

Miłosz [51:16]: So, sometimes you can also do it with a short session just to start a project. I remember when we started new services, we just use Mood Programming, where we just bootstrap the project or something like that.

Robert [51:30]: Yeah, and it was pretty cool because we had really nice boosts at the beginning, so everybody was aligned. how it was implemented, and it was speeding up work at the beginning very, very much. Because, again, it’s also the theme that is going over and over during this episode, so knowledge sharing. So this very deep knowledge sharing that actually accelerates the work a lot. Because you may have multiple tasks to implement, everybody knows how everything else in the project works, so everybody can pick up the task and tasks are not blocked because, for example, this task can be unimplemented by somebody. Everybody can take that, everybody can review that, and it’s accelerating work a lot. That’s kind of hidden functionality of that, let’s say. But yeah, it can help a lot. And yeah, this is also the same with mob programming. So basically you can mob program the feature at the beginning of the project and and later iterate really, really fast.

Miłosz [52:38]: Maybe we can talk about code review culture, going back to the topic.

Robert [52:43]: Yeah, because I think it’s pretty important because a lot of ideas that we have here, it requires some nice culture in the team. Because again, you can do small TRs, but if nobody will review them, it’s pointless because you end up with waiting for ages for the reviews, so it will be not helpful. So what do you have in mind from our experience? What are the important traits of the team that have high review culture?

Miłosz [53:19]: Maybe what you mentioned before, making the team responsibility, not individual responsibility. The team is responsible for delivering the entire feature product. Anyone should be able to review code for knowledge showing. Avoid the silos where people are closed in their own parts of the code and they know everything about it. No one else is able to suggest changes there.

Robert [53:52]: And by everybody we mean that, okay, if you have 15 people team, or maybe not entire team, but you can have some… Okay, it’s really problematic if your team is 15 people.

Miłosz [54:03]: I guess ideally we have two or three people working on a single feature at a time and they can review each underscore.

Robert [54:11]: I would even say that maybe five. Five is also good because you can have some extra capacity for that. And it’s a number out of an hour.

Miłosz [54:22]: Yeah, but I mean, it’s probably an anti-pattern to have one person responsible for all the reviews. So like the leader with the grey beard who knows everything and everyone just asks them to review their code. That’s probably not what you want, because this person becomes a bottleneck.

Robert [54:44]: It’s also not good when you have your buddy, for example, that is doing your reviews. because it’s a bit better, because it’s not in the hands of one person. By the way, I think many of you may not know the Phoenix Project book. I don’t remember the name, but it was covering a similar situation of one person that was the person that known everything, but it was also a bottleneck at the end. So it’s a very similar situation.

Miłosz [55:16]: I would usually just ask the person who has more experience in the area than I have. So, they can give you some insights on the way that or maybe

Robert [55:25]: Just have a team channel and.

Miłosz [55:28]: Oh yeah

Robert [55:30]: And pick up it and yeah.

Miłosz [55:32]: Yeah, that’s yeah, that’s the best thing times, I remember. What I mentioned about the 5-minute cycle time is when you just post a PR, post a link to some Slack channel and then you get an approval for comments 10 minutes later. That was my ideal working condition.

Robert [55:56]: Yeah, it’s possible. It requires times and good culture.

Miłosz [56:03]: I think the main concern is there is context switching. But once again, switching context to a 50-line long VR is something completely different than 500-line VR.

Robert [56:16]: Or even 200 lines. I mean, it’s also something that you can review pretty quickly.

Miłosz [56:21]: Yeah, I just mean the size in general. If it’s in tens of lines, hundreds of lines, probably still kind of fine, but if it’s thousands, then yeah, probably someone will open it and then they will go for a coffee break or back to their own code and we’ll just make a mental note to come back to it later. If it’s 50 lines or 100 lines, they can just read it in one minute and tell you what they think.

Robert [56:54]: I have actually one thing in mind when we’re discussing that, that one of the problem with the discussion that we have now, it’s that having this so having everything working requires multiple things. For example, if one thing doesn’t work, it can break the good PR flows. For example, if, for example, it takes ages for people to pick up PRs, so everything else can be problematic. So it’s important that to not pick some parts of this, but try to, improve it from multiple angles. Okay, we’re going back to the strong code review culture. So other thing that it’s maybe also not obvious is actually how we are doing reviews. So I have two things in mind.

Robert [57:46]: So the first is the feedback culture and feedback mindset. So you should not try this last.

Robert [57:59]: You should not take this code review feedback personally, let’s say, because I think it’s often that people are looking like, oh, somebody commented on my code, I’m so stupid, and this person is also stupid because he doesn’t like me or whatever. So, try to avoid that and try to separate that thought. This is the cult, this is you, and this is a separate thing. It’s also always good to assume good intentions, because it’s easy to go in a direction like, ah, somebody is commenting on that, would like to make my life harder, and why he’s doing that. And I think it’s very rarely true, so most often it’s that actually somebody cares on the other side, and this person would like to create code that is maintainable and easy to work with. So I think it’s important to start with mindset by default that the person on the other side have good intentions. So this person cares and this person would like to just have nice code. Obviously, sometimes it’s going into extremes. Sometimes the person can have also some bad intentions, but it’s more about the default approach so I think by default and it will be probably true in 80% or 90% cases that people have good intentions unless.

Miłosz [59:19]: They need to pick yeah

Robert [59:23]: And I think it’s another problem so if you don’t know what nitpicking is so you know it’s all those comments like okay it’s not important but maybe you should use spaces here or, change how it’s formatted to a different…

Miłosz [59:41]: Can you order the variables alphabetically?

Robert [59:46]: Yeah, yeah. And all those comments that are…

Miłosz [59:50]: Basically, I would like this code to look like this, but you do it differently.

Robert [59:55]: So you can resolve this comment. I don’t mind. But, yeah. So this is nitpicking, long story short. And in my opinion, If I do a code review and I think about adding a nitpick, I don’t do that. Because if it’s not that important that it’s not required for merging, it doesn’t make sense actually to add any comment, spend other person’s time on resolving that or maybe addressing that, because it’s just not important. In my opinion, all those nitpicks should be covered by the Linter, basically. So if you have some styling requirements, just put Linter for that and not spend human’s time.

Miłosz [1:00:46]: Because they are often cosmetics, so our Linter is good at catching that.

Robert [1:00:50]: Exactly. And Linter have also one nice feature that it has a pretty quick feedback loop. Because if you are leaving a comment in the PR, some person will read it with some delay, some person needs to address that. It’s just a lot of waste of time. And with Linter, you’re just running Linter. You can see, in the worst case, a couple of seconds later. In the best case, in less than one second, that everything is fine or what should be fixed. You can format that and it’s fine. So I think this is how it should be solved with NitPix. So if something is that important enough to check for that, fine. Let’s put linter for that and linter will ensure. If it’s not important, why to do that?

Miłosz [1:01:34]: Makes sense. Also, as the person submitting the PR, you can do some things to make it easier. Something I like to do is being my first reviewer. Just checking the trendset and often you will find some leftovers. Instead of someone commenting it for you, you can just do it yourself. Make their job a bit easier. and they can also include a short description, like why you did something. We sometimes comment on the onlines ourselves just like a heads up for the reviewer like, you know, I know this can look strange, but I did this because of something.

Robert [1:02:21]: Or even better, leave some comments in the code that explains why it’s done in some way. And I think it’s important that you mention that to describe why not how. Because how it’s written, what’s written there, is visible in the code. I mean, it is the source of truth. But why? It’s not in the code. You can only see how it’s done.

Miłosz [1:02:44]: You generate the how with AI. Summary, but it’s not really the point. The point is to give some extra context, not what is already there, but different words.

Robert [1:02:54]: Exactly.

Miłosz [1:02:56]: Maybe one other tactic is draft PRs. If you have some very rough idea, especially if it’s something experimental or something your team didn’t do before, I would create a draft PR and very quickly, in a sloppy way, share with everyone and ask them to give me some first impressions.

Robert [1:03:20]: Especially if you discovered something unexpected in a PR. So remember, don’t surprise the reviewer, and if you feel that, okay, this may surprise somebody, yeah, good place for a draw.

Miłosz [1:03:34]: This works only if you have this early feedback culture. You can get someone’s comments in 15 minutes. I think it’s way better to discuss it early, because if you go deeper into this and you have more tool you work, if you have some insights. And if you ask them early, it’s even better to have some quick meeting to align and agree and then implement.

Robert [1:04:02]: It’s also connected with this idea that you are working as a team, not as a set of individuals. So, you collectively care about this draft.

Miłosz [1:04:13]: And you have to see why we are in that. Yeah, but this needs to be in place because you will need to wait two days for our draft PR review. It doesn’t make zero sense.

Robert [1:04:24]: Exactly. And I think it’s actually something pretty important to touch on. So, what are the tactics to accelerate review cycles? Because I think it’s a requirement for most of the things that we mentioned. So, if your review cycle is slow, it doesn’t make sense to split your PRs to smaller PRs, because if you are creating 10 smaller PRs and you are waiting for them for one week, it’s not a big difference between making one big PR… You’re just stuck PRs needlessly. Yeah, probably in this case it’s better to not split PRs and have big PRs that nobody will really review or create 200 comments. Probably it’s better than having 10 PRs like that. Unfortunately, so I think this accelerating review cycles is key here and keeping this cycle time more is also critical. So one of the most important things and mindset to learn is that making reviews should be.

Robert [1:05:33]: We should prioritize making review, basically. So it’s pretty compatible with the lean Kanban approaches.

Robert [1:05:42]: So basically the idea is that you should prioritize work to be done. So if you have something that is close to be done, PR, this is work that is almost done, let’s say, you should prioritize that and try to get it out of your board, let’s say, as soon as possible. And, It’s a simple idea, but, again, very, very important.

Miłosz [1:06:06]: So, I guess, higher priority than full-in-progress, because it’s closer to production.

Robert [1:06:11]: Exactly, exactly. So, obviously, it requires some context switching. So, if you’re working on some feature and you see that there is some PR to be reviewed, obviously, you probably shouldn’t, if you’re working on something, jump straight into that and review that. But maybe there is some person that finishes the job and can jump in this PR.

Miłosz [1:06:37]: Yes, contact switching can be a problem, probably for some people more than for others, but you probably don’t work eight hours looking at the code anyway. I mean, writing.

Robert [1:06:49]: You are not. We’ll need to talk about it after.

Miłosz [1:06:52]: Maybe you’re supposed to.

Robert [1:06:54]: We’ll talk after recording about that. But jokes aside, yeah. And I think it’s going back to the knowledge sharing. So we covered this knowledge sharing multiple times, and I know that some people are, why we need knowledge sharing? And this is actually a great example why it’s important, because if you don’t have only one person that is able to review your QR, but entire team can do that, you don’t need to wait for this one person. You can probably have one person that finished his work or her work and can look into this PR, and it’s making this acceleration working, basically. If you have only one person that can review your PR, obviously it’s making the cycles much longer, because only this person, multiple stars in the sky need to go into a special…

Miłosz [1:07:48]: Into a line.

Robert [1:07:50]: Yeah, yeah, yeah.

Miłosz [1:07:54]: Yeah, and the end result is this cool flow of PRs going smooth from coach to production.

Robert [1:08:02]: Yeah, so basically you can work on something in the morning and by the end of the day, and you’re not working for 18 hours, and it can be merged within this day. But again, it’s important mindset shift because I know it’s natural to focus on your job to be done. But again, try to focus on finishing work and work as a team, not set of individuals.

Miłosz [1:08:35]: That’s a culture thing. Not easy to change, but helpful to have in place. There’s also this kind of controversial topic of metrics. There are many tools that you connect to your GitHub and that you track things like average PR size, cycle time, timing review and so on. And they can be useful. I think there’s a risk that someone uses them for measuring performance. That’s probably not a good idea, because people will start gaming them and that’s not what you want. Especially if you try to compare teams using them or something like that. I’m not recommended, but you can use it inside the team for insight or maybe to find some outliers. If you have one or two huge PRs in one iteration, you can ask yourself why this happened. Maybe it was okay, maybe we could improve something.

Robert [1:09:45]: But I think it’s also important to set expectations. So we said that, okay, in this ideal work, you are starting in the morning, merging by the end of the day. But also, to set expectations. In our teams, it also wasn’t like that for every PR. So it was probably for 80%, sometimes 70% of PRs. But I think it’s enough.

Miłosz [1:10:07]: So the target is not perfection, right? Yeah. Just that most work goes like this. Sometimes there will be some crazy refactor that you need to do at once. Maybe it’s fine.

Robert [1:10:19]: Sometimes you probably should reflect that, okay, why this took longer, what we can do to improve that, and try to do some kind of continuous improvement. As we were already saying about fancy Japanese words, Aizen.

Miłosz [1:10:34]: So it can be a good starting point for retrospectives in discussion.

Robert [1:10:40]: Yeah, I remember that when we were really into optimizing that, we on the retrospectives were looking on these outliers and discussing, okay, why this PR took, for example, three days, for example, to be merged. And, okay, is this something that we can improve here? Okay, this PR was like that because, I don’t know, it was some unexpected complexity there and, okay, it happens. Probably couldn’t do much about that. It’s fine. Or maybe we can see sometimes, okay, we didn’t spend enough time on planning here. Maybe we can, for example, next time, plan more about this, because this, and just improve. And again, this is a skill. So if you work in such environment for a longer time, you’ll also learn what things are worth to do deeper planning and work when it’s just not productive. Oh, we have some comments. Hi guys, I came late, I have concern. How could you create small PRs if you are working on tickets? And maybe the ticket has complex tasks. How do you recommend doing small PRs in those cases?

Miłosz [1:12:04]: Complex task yeah if you can follow up what you mean by complex but two things we mentioned before so one is splitting the ticket into smaller tasks but by vertically by the product features

Robert [1:12:26]: Maybe it’s the situation when you have tasks from somebody up and you are basically implementing the tasks that you are receiving from some product owner somewhere that is planning your work.

Miłosz [1:12:40]: Oh, yeah, right. I didn’t consider this. Because it’s going to be like this.

Robert [1:12:48]: I think the root cause, if I understand it properly, the root cause is probably that some person is planning your work, as long as I get it properly. But I think it’s the root cause. I mean, it shouldn’t be a process like somebody’s giving you tasks that you should implement and deciding on how to state that. It should be probably the opposite. So you should discuss with this person, okay, what we have to do. So you should actually receive the problem that is to be solved, but not tasks that will be implemented, basically. And it should be some collective process to agree how to do that. Unfortunately, I know it’s not possible in all companies, and it’s sometimes impossible to change. And in this case, change companies.

Miłosz [1:13:36]: If you can split it, try more programming.

Robert [1:13:41]: Or maybe just split it internally, so you can have one task from somewhere else, do process yourself to split it to multiple smaller tasks, and just have smaller PR. So we already mentioned it a bit earlier, that you can merge code that is not functional yet, So it can work in the background, or maybe not. You may have some functions that are implemented but are not included in the production process, let’s say. In the last PRs, for example, you can have multiple PRs, and in the last PR you can integrate everything. In the meantime, if something is much more complicated, you can also do the…

Miłosz [1:14:38]: It’s kind of what you mentioned before,

Robert [1:14:41]: Right?

Miłosz [1:14:44]: Just because a task is complex doesn’t mean you can’t split it into small PRs. You can have the scaffolding first and then use feature flags to deplace on that code to production before you start using it. I’m not sure if you’ve listened the entire episode, but we mentioned this before.

Robert [1:15:06]: But yeah, the downside is that, again, it requires the entire team to kind of come into this approach. because if you have a long review cycle and you have many smaller PRs, it may be just blocked too long. You will not see the benefit of that. I also wanted to share that if you are splitting such tasks in more smaller tasks, if it’s more complex, you can also run shadow mode before the last merge. So you can run new code along the old code and compare if this code is creating the same result without storing it to the database or something like that. So sometimes you may be doing some bigger refactoring or something like that. So maybe you have some tests for that, that you see that, okay, it’s passing, but sometimes you would like to also compare on the production if it’s working as previously, but without breaking anything. So you can run two functions like this alongside within one service and just compare result at the end. Run it for a week, month for a complex one, and if you see that the results are consistent and it’s working nice, you can just swap that. But again, it’s for much more complex tasks.

Robert [1:16:23]: Ah, okay, so I was right. The case is that tasks are assigned to me, and the tasks have goals. In some cases, I need to make changes in several repositories, and maybe I need to touch several files at once. So yeah, in this case, I’ll say that this is probably the pattern that tasks are assigned to you. In my opinion, it should not work like this.

Miłosz [1:16:45]: So yeah, but what can you do in this situation?

Robert [1:16:49]: Yeah, yeah. So, as I said, unfortunately, in many companies, you cannot re-change that. So, the thing that you can do is you can split these tasks internally. And, again, it depends on the team. I know that sometimes it may be hard to change the entire team culture to smaller PRs. Because, okay, maybe you can split your tasks into smaller tasks and try to have smaller PRs, but if nobody will look in your TRs and it will be no teamwork, because, okay, I assume if tasks are assigned to you, it may be problematic, because you are not collectively working on that. It’s your responsibility and it’s harder to actually integrate with that. Sometimes, unfortunately, it’s a bit hard to change the company culture.

Miłosz [1:17:35]: Yeah, but we can still do just this on the technical side.

Robert [1:17:40]: And I would say that, okay, sometimes it’s maybe hard, but not impossible to change that. I mean, we’ve seen sometimes in our life that the company culture was super hard to change, but if you push really hard, you can also do some positive changes.

Miłosz [1:17:54]: But if you can, you can do it also on the technical side of things. You can focus on the logic first and then implementation details or the other way around. The reviewers don’t need to have the full context in their minds at the same time. They can do it in parts. It’s much easier. So there’s some impact you can make.

Robert [1:18:20]: We recommend checking what we’ve mentioned a bit earlier. So we have multiple strategies and hopefully it will help. And again, try to change maybe something in your team. Maybe it will be possible. Good luck! But yeah, I think also don’t be demotivated that it’s so bad. Because from our experience also in the teams, when you need to do these changes and you need to push hard to do that, actually you can learn a lot. Because it’s not like just, oh, let’s do it like this. And everybody’s happy. Yeah, it’s too easy. When you are in the team that you need to re-spend a lot of time to convince your product owner, the rest of the team for that. It will be hard, but if you succeed, it will be much easier in the other teams and it’s a useful skill.

Miłosz [1:19:11]: If you want to succeed, it’s a change of the job.

Robert [1:19:15]: Yep, it’s the last resort, but it often works. And if you succeed in this team, it will be also something nice to get a better job earlier. I mean, if I heard such stories like, yeah, I worked in the team when tasks were assigned to me and I convinced product owner to spend time together to split tasks. I convinced my team to split work into smaller. It was always like, okay, nice. It’s so you know what to do and it’s also helping to join nicer teams later. It’s also a nice opportunity. You should try to see it in this way. All right.

Robert [1:20:02]: Other alternative that I have in mind that you can, Solve problem of big PRs is you know what. What do you mean? I see big PR, I close my eyes and yeah, legit to me, that’s marriage death.

Miłosz [1:20:18]: That is good, yeah.

Robert [1:20:19]: I know that many teams are people who use this tactic and it can also work in some places. I mean, let’s imagine that we’re in a team, in some component that is fighting for survival and the long-term in this case of company is six months. And if they will fail, they will just fail and it will be closed. So obviously, you probably don’t need to care that much about long-term maintainability because long-term may not exist, basically. But if you are in a more mature company or you are not trying to survive, and you know that maybe you are building these features and it’s very likely that it’s not the final, phase of this feature and you will need to change them. It’s pretty likely if you are working in startup because very rarely the idea that you have at the beginning survives multiple iterations. So basically you need to be able to very quickly. In those cases, probably YOLO mode is not the best load.

Miłosz [1:21:33]: It’s a bit like we discussed in the first episode, when to write low-quality code. Sometimes it makes sense, but you need to consider if you are in this place or not.

Robert [1:21:45]: I think it’s also connected to using some basic episodes and using some good practices. Basically, to skip some good practices, you need to understand what this good practice is giving you and what’s skipping this good practice who gets all the gear.

Miłosz [1:22:03]: If it’s worth the short term to drop some… I mean, sorry, if it’s long in the long term, drop some good practice in the short term.

Robert [1:22:14]: Yeah. Like code reviews. Yeah, yeah. Because, okay, maybe just one person can work on some functionality for one month, and, okay, just rush that, and because there is some tight deadline or whatever, okay, fine, but it’s not for free. You will need to pay it back if you will need to extend this functionality, because the rest of the team will have no idea how it’s implemented, and if only one person, implemented that, probably it’s also not the best application in the world and it’s very similar in the case when you have YOLO code reviews. So you’re closing your eyes and yeah, legit to me and so again, it’s not like you may notice that the name of this podcast is No Silver Bullet so it’s not like you should always do code review.

Miłosz [1:23:02]: If you work on a own, you can’t. Unless you use AI I think that’s a good closing point consider what makes sense in this particular scenario also what you mentioned before try to be aware of the perfection trap don’t go too far into don’t take the metric too seriously and don’t say something like we don’t accept PRs above 500 lines ever it’s like don’t make it a hard limit or something like this

Robert [1:23:46]: But i think it’s also important that if it’s happening too often it’s also good to have some pushback like sorry mate but yeah this is, and maybe you can spend some effort on splitting that because often when you have big pr it could be split and it’s not that hard really so especially.

Miłosz [1:24:10]: If you have something like you know have a feature and then you are a good scout, so you can just refactor this a bit.

Robert [1:24:18]: Rename one function that is used in 2000 places in the project.

Miłosz [1:24:22]: So this is a perfect scenario where you can split it to a separate PR. You don’t mix the context.

Robert [1:24:28]: It’s probably five minutes to make a separate PR.

Miłosz [1:24:32]: It will help a lot for the reviewers because they don’t mix the context of refactor with actual changes.

Robert [1:24:39]: I think it’s actually what you said. It’s very important. If you’re doing refactoring, don’t mix it with implementing new functionality, because it’s very, very hard to actually distinguish that. Because if you’re doing refactoring and keeping the functionality working as earlier, it’s much easier to read, because you’re just focusing on nothing. And if you’re changing functionality and doing refactoring, it’s much, much harder to spot actually what is part of refactoring and what is part of new functionality.

Miłosz [1:25:08]: It probably helps if you learn a bit of Git, so you are comfortable branching out of a branch, which in this case is helpful. It’s not super complex, but I know many people are intimidated by Git. Stacking PRs is sometimes a great help. Instead of one huge PR with many mixed changes sometimes it’s easier to create three separate PRs branching from each other which is a bit of work to do huge amount, but for the reviewers it will be much easier to review.

Robert [1:25:50]: But also try to avoid that, because if you’re branching out of the branch, it means that you probably have problem with some basics, like you’re waiting for too long for the review.

Miłosz [1:26:03]: Yeah, but sometimes even if you wait like, you know, four hours for review, so it’s the same day, it makes sense to branch out so you can work on something next.

Robert [1:26:11]: It’s not that big, yeah, yeah, yeah.

Miłosz [1:26:13]: But it’s also… Probably not the default for everything, but I think it’s… If you’re not comfortable doing it, then you will be trapped. Because you will wait for a review and you will think, okay, I can’t work.

Robert [1:26:28]: But there is also one trap. If you try to start to work on the next functionality that is branched out of that, that you’ll receive with you, it probably may make the reverse cycle slower because you’ll need to contact switch back to that. Sometimes it’s maybe better to do and make a coffee, two or three, four hours. But again, as we said earlier… But again, as we said earlier, there are multiple things that you need to join to get this good, fast review cycle, and it’s making a much better effect at the end, when you, just have multiple good practices that we mentioned, and it really flows.

Miłosz [1:27:20]: Yeah, this is a great place to be in when the world just goes straight to the production.

Robert [1:27:26]: And again, if somebody is telling you that, you know, implementing functionality and merging it within one day is just in the books on the conferences, it’s not, really. It’s possible to do. It requires effort. It requires high confidence. Team code review culture, but it’s possible, and it’s very worth, and I really hope that everybody who is listening for that will be able to work in such a team. We did that, and it was just super cool to feel this work flowing and see how fast we’re able to implement things.

Miłosz [1:28:06]: Yeah, I think it’s one of the top experiences you can have in a team.

Robert [1:28:10]: Now we are actually two in our teams, so it’s a bit also easier because we can just…

Miłosz [1:28:17]: Still applies, though.

Robert [1:28:18]: Yeah, yeah, yeah. So obviously it’s a bit easier to do when we’re two.

Miłosz [1:28:24]: But it’s more tempting to build big PR, so we need to watch out.

Robert [1:28:31]: Yep, we also do it from time to time. So don’t be perfectionists. I would say 80% so try to aim for 80% of PRs to be merged within the same day. It’s possible to do. But also, don’t probably 100%, it will be hard. But try to learn from those PRs that are not merged within this timebox. Alright, so I think we are out of the topics so it will be time for Q&A so if you have any questions please leave them on the chat and we’ll be more than happy to ask for them. Also, one small announcement. So, if you are longer with us, and if you are in our newsletter that we highly recommend, we mentioned that we’ll be dropping the… Live from our podcast. So in other words, we’ll pre-record episodes because, it’s a bit hard sometimes to organize everything.

Miłosz [1:29:30]: As we can see today, we have our overheating camera.

Robert [1:29:33]: Yeah, yeah, yeah, exactly. And as also you may notice one week ago, when we were not able to be live because of some sick leaves, etc. And also, it’s not super easy to actually record it live because we need to think really quickly. It’s probably too quick for us, and it’s not that easy to keep this slow. And for our podcasting platform, we are doing edits, and it’s easier to listen for that. But in the YouTube, the version that is staying there is the live version, basically. So there are some pauses, so it’s a bit…

Miłosz [1:30:10]: But it was a fun experiment. We did 10 episodes.

Robert [1:30:14]: Definitely.

Miłosz [1:30:15]: I think we want to come back with live format, but probably something more interesting than this talking. Maybe some coding or something like that.

Robert [1:30:26]: If we have time. Yeah. So we cannot promise, but we’ll also run some AMA sessions from time to time, so the next one in the next week. We should put soon to the description or maybe I will do it now. So I will put to the a link to the form for AMA questions. So I will put it to this episode’s description now. We’ll also cover some questions that we have in the comments on YouTube. Yes. I will just put it to the description now because I may forget that. Can I edit it? What else?

Miłosz [1:31:25]: Yeah, that’s it. Thank you for joining the last live episode, for now at least. And thank you for the comments.

Robert [1:31:34]: Yeah, we’ll see each other next week in the AMA episode. And later we are doing some short summer break because it was actually pretty intensive now or a bit longer. And yeah, we should be back after summer with some other updated podcast. So we’ll have some more surprises, but we’ll see after vacations.

Miłosz [1:32:13]: Cool.

Robert [1:32:14]: All right, cool. So I think we are done for today. So remember to leave some comments if you have under the video, leave thumbs up so the Deadly Algorithm will like us more. Subscribe to our podcast on Spotify, Apple Podcasts, and every application that you are using. Yeah.

Miłosz [1:32:42]: Thank you, everyone.

Robert [1:32:43]: Thank you. And see you next time in a week. Bye.