Kyle Shevlin

This book is easily the most impactful book I have ever read and dramatically changed how I approach writing code, making changes, making commits, PRs, testing, etc. In truth, this book deserves an entire blog post of its own, but I'll share just a bit here.

Most people use the word "refactoring" incorrectly. There is a very small and specific definition of "refactor" we ought to use. A "refactor" is when we change the organization of the code without changing the functionality of the code. I think of it a lot like solving math problems. We can modify the equation, so long as it remains equivalent, such as adding a number to both sides. This implies that in order to refactor anything we must first have the code under tests. How else can we be certain that the code is functionally the same?

Once we have tests, then our objective in a refactor is to go from "green to green". We rearrange and reorganize the code so that we're able to achieve our future goals while doing nothing to change the current behavior. That means you don't commit anything extra. No little fixes here. No tweaks there. Just the refactor.

What's amazing about being this strict about refactoring is that you gain some super powers. The latter half of the book is a collection of refactor recipes. Step by step instructions on how to transform this to that and back again. It's just like the math formulas I was talking about. How to shift from here to there without breaking anything.

You need to grab this book. I own the first edition, which is in Java. I've never even written Java and it's that helpful. There's a second edition now that's rewritten in JavaScript that will probably be a lot more accessible to most of you.

This book goes hand in hand with "Refactoring". Most of the work we do is on brownfield code and having a strategy to safely update it is vital.

The reason it goes with "Refactoring" so well is Feathers' definition of "legacy code". "Legacy code" is any code that isn't under test.

"Woah, Kyle, that's a little drastic. I just wrote this code yesterday, it couldn't possibly be 'legacy code'," you say. To which I would say, without tests, you can't prove that the code does what you expect, and you certainly can't prove that it's stayed the same over time. The tests are what make it safe to touch and change.

I highly recommend reading this book. As someone who's had to "swap an engine out while flying the plane" several times in my career, this book was essentially for being able to do that confidently and safely.

This book was my gateway into functional programming, and learning even the smallest amount of it drastically changed the way I approach problems. It has informed not only how I write functions, but how I compose UIs, build up complexity in systems, even how I test my code.

This book is what inspired my functional programming course and all my blog posts on the topic. It's a really accessible intro to the topic and it's written in JavaScript, so most of you should be able to follow along easily. I just reread it for a third time this past winter and I still learned a few things.

You have to understand two things: I have hardly written any Ruby in my career, and I have never worked on a codebase that was truly object-oriented. This book is so good it makes me think I could enjoy doing both.

POODR (as the books is commonly referred to) is such a solid introduction to the concepts of object-oriented programming that anyone can read it, regardless of their knowledge of Ruby. It helped me realize that object-oriented programming, when done well, is remarkably similar to functional programming. Insert the "They're the same picture" meme here.

I think if you read this book, you'll come away with better ideas of how to abstract complex problems into simple and reasonable solutions.

I have rewatched this talk probably half a dozen times at least. It is that good. It transformed the way I think about writing functions, components and abstractions in general. This talk is the reason I prefer to dependency inject anything that could create a side-effect into my components, such as Math.random() as a randomizer parameter, or a now or today parameter, instead of calling new Date() in a function.

In this talk, Sandi Metz talks to us about cyclomatic complexity and how to refactor complex code. She demonstrates and encourages us to not be afraid of temporarily increasing complexity to ultimately get to a simpler system. She works through the "Gilded Rose Kata" as part of the talk and was a real eye opener to me.