136: Addressing Technical Friction
June 26th, 2019 · 55 mins 5 secs
About this Episode
The Twitter thread:
All I can say here is that I try to lead by example. If there’s a clear path to “make the change easy, then make the easy change,” make sure the commit history shows that explicitly, then ask for a code review even if your process doesn’t require it. 1/ https://t.co/VDxDbEQUf3
— Sam Livingston-Gray (@geeksam) June 9, 2019
Sam Livingston-Gray - F̶l̶u̶e̶n̶t̶ Refactoring Talk: Sam talks about refactoring a gnarly Rails controller method. This is a lightly edited version of a talk Sam gave in 2013.
Resources:
github.com/geeksam/fluent-refactoring
Introduction to the Technical Debt Concept
21:47 - Refactoring Resistance: Who are you trying to convince?
- Product Owner (Goal Donor)
- Funder (Gold Owner)
- Crusty Teammate
- Newbie Teammate
28:57 - The Risks of Refactoring
Idealized Design:
- Technically Viable
- Organizationally Viable
- A System Capable of Improvement Over Time
3 Different Kinds of Technical Debt:
- Intentional Debt
- Evolutionary Debt
- Bit Rot
35:08 - Documentation and Decision Records
36:59 - Code Value Judgement
42:00 - Convincing Coworkers Re: Refactoring a Codebase
Reflections:
Coraline: Adaptive Capacity.
Rein: Viability.
Sam: It’s about dealing with people and effectively working with and for them.
This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode
To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.
Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks!
Support Greater Than Code