�ݺ�ߣshows by User: kobac

�ݺ�ߣshows by User: kobac / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: kobac / Sun, 30 May 2021 20:13:25 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: kobac Async Code Reviews Are Killing Your Company’s Throughput - Dragan Stepanović /slideshow/async-code-reviews-are-killing-your-companys-throughput-248758692/248758692 2bcsndbjtqcvcgxuthok-signature-93ae154ce0b7bd6a9166bfab14036accb1ce6c7ac4795701616d656350af89d9-poli-210530201325
Note: You can find a higher resolution slide deck here https://drive.google.com/file/d/1Umv5nfMMU_wJeGPekdBfMVbqp-BsM7ko/view?usp=sharing Abstract: "Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have your cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. Bio: Dragan is currently a principal engineer at HelloFresh, one of the unicorns of Berlin's thriving start-up scene. Before HelloFresh he helped Careem/Uber build the largest loyalty program in the MENA region, drive architecture, technical strategy, and shape engineering culture. Typically on the search for better ways of working, exploring ends of the spectrums, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but end up as completely opposite of that. It's been a long time since he fell in love with eXtreme Programming, Domain-Driven Design, and software as a craft (founder of Software Crafting Serbia community). Last couple of years he enjoys endless discussions connecting the Theory of Constraints, Systems Thinking, Lean and socio-technical topics.]]>
Note: You can find a higher resolution slide deck here https://drive.google.com/file/d/1Umv5nfMMU_wJeGPekdBfMVbqp-BsM7ko/view?usp=sharing Abstract: "Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have your cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. Bio: Dragan is currently a principal engineer at HelloFresh, one of the unicorns of Berlin's thriving start-up scene. Before HelloFresh he helped Careem/Uber build the largest loyalty program in the MENA region, drive architecture, technical strategy, and shape engineering culture. Typically on the search for better ways of working, exploring ends of the spectrums, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but end up as completely opposite of that. It's been a long time since he fell in love with eXtreme Programming, Domain-Driven Design, and software as a craft (founder of Software Crafting Serbia community). Last couple of years he enjoys endless discussions connecting the Theory of Constraints, Systems Thinking, Lean and socio-technical topics.]]> Sun, 30 May 2021 20:13:25 GMT /slideshow/async-code-reviews-are-killing-your-companys-throughput-248758692/248758692 kobac@slideshare.net(kobac) Async Code Reviews Are Killing Your Company’s Throughput - Dragan Stepanović kobac Note: You can find a higher resolution slide deck here https://drive.google.com/file/d/1Umv5nfMMU_wJeGPekdBfMVbqp-BsM7ko/view?usp=sharing Abstract: "Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have your cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. Bio: Dragan is currently a principal engineer at HelloFresh, one of the unicorns of Berlin's thriving start-up scene. Before HelloFresh he helped Careem/Uber build the largest loyalty program in the MENA region, drive architecture, technical strategy, and shape engineering culture. Typically on the search for better ways of working, exploring ends of the spectrums, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but end up as completely opposite of that. It's been a long time since he fell in love with eXtreme Programming, Domain-Driven Design, and software as a craft (founder of Software Crafting Serbia community). Last couple of years he enjoys endless discussions connecting the Theory of Constraints, Systems Thinking, Lean and socio-technical topics. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/2bcsndbjtqcvcgxuthok-signature-93ae154ce0b7bd6a9166bfab14036accb1ce6c7ac4795701616d656350af89d9-poli-210530201325-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Note: You can find a higher resolution slide deck here https://drive.google.com/file/d/1Umv5nfMMU_wJeGPekdBfMVbqp-BsM7ko/view?usp=sharing Abstract: "Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have your cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. Bio: Dragan is currently a principal engineer at HelloFresh, one of the unicorns of Berlin's thriving start-up scene. Before HelloFresh he helped Careem/Uber build the largest loyalty program in the MENA region, drive architecture, technical strategy, and shape engineering culture. Typically on the search for better ways of working, exploring ends of the spectrums, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but end up as completely opposite of that. It's been a long time since he fell in love with eXtreme Programming, Domain-Driven Design, and software as a craft (founder of Software Crafting Serbia community). Last couple of years he enjoys endless discussions connecting the Theory of Constraints, Systems Thinking, Lean and socio-technical topics.

Async Code Reviews Are Killing Your Company’s Throughput - Dragan Stepanović from Dragan Stepanović

]]> 5838 0 https://cdn.slidesharecdn.com/ss_thumbnails/2bcsndbjtqcvcgxuthok-signature-93ae154ce0b7bd6a9166bfab14036accb1ce6c7ac4795701616d656350af89d9-poli-210530201325-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Async Code Reviews Are Killing Your Company’s Throughput - [Old] /slideshow/async-code-reviews-are-killing-your-companys-throughput-246120731/246120731 tn4niprhoseqgtw3kdqd-signature-8318f67f202230b66e6c353861cde49fff90ba1ccf0152120f9f020ff09d7893-poli-210412211929
"Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have a cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. ]]>
"Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have a cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. ]]> Mon, 12 Apr 2021 21:19:29 GMT /slideshow/async-code-reviews-are-killing-your-companys-throughput-246120731/246120731 kobac@slideshare.net(kobac) Async Code Reviews Are Killing Your Company’s Throughput - [Old] kobac "Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have a cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/tn4niprhoseqgtw3kdqd-signature-8318f67f202230b66e6c353861cde49fff90ba1ccf0152120f9f020ff09d7893-poli-210412211929-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> "Never had a PR over 300 LoC that didn't look good to me". We've all been there. The PR is so big you don't even bother commenting. It's already too late to build the quality in. You make a sad face, comment "LGTM", and click approve. That's still the case in lots of teams but feels like after a long time the industry, on average, learned the value of the Small Batches idea from Lean applied to PRs. And that's a good thing; it's a step in the right direction. We do a bit of coding, raise a PR and then ask for feedback. People are more likely to engage on smaller PRs. It takes them less time to review it, and they have a feeling that they can still course-correct if something goes astray. PRs go sooner out of the door, and we feel productive as a team. But, here's the surprise. What if I told you that teams doing small PRs (with async code reviews) actually have way lower throughput than teams doing big PRs. "Wait, what?!" Yes. I got this surprising systemic insight from analyzing PRs across a bunch of very active repositories and I'll present you with the results of the study. On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality. But! There's a parallel universe of ways of working where you get to have a cake and eat it too. Where you can have both throughput and quality. That universe is called co-creation patterns (Pair and Mob programming). Join me on a journey where I'll show you data invalidating the assumption that two or more people sitting at the same computer will hurt our throughput and why the opposite is actually the case.

Async Code Reviews Are Killing Your Company’s Throughput - [Old] from Dragan Stepanović

]]> 5229 2 https://cdn.slidesharecdn.com/ss_thumbnails/tn4niprhoseqgtw3kdqd-signature-8318f67f202230b66e6c353861cde49fff90ba1ccf0152120f9f020ff09d7893-poli-210412211929-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-kobac-48x48.jpg?cb=1642325755 Twitter: @d_stepanovic LinkedIn: dstepanovic draganstepanovic.com https://cdn.slidesharecdn.com/ss_thumbnails/2bcsndbjtqcvcgxuthok-signature-93ae154ce0b7bd6a9166bfab14036accb1ce6c7ac4795701616d656350af89d9-poli-210530201325-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/async-code-reviews-are-killing-your-companys-throughput-248758692/248758692 Async Code Reviews Are... https://cdn.slidesharecdn.com/ss_thumbnails/tn4niprhoseqgtw3kdqd-signature-8318f67f202230b66e6c353861cde49fff90ba1ccf0152120f9f020ff09d7893-poli-210412211929-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/async-code-reviews-are-killing-your-companys-throughput-246120731/246120731 Async Code Reviews Are...