Sandi Metz Workshop, Procore 2016

Sandi Metz is at Procore running a Practical Object Oriented Design workshop. Today was day 2 of 3 and I'm enchanted, inspired, and humbled.

10,000ft view

We actually started with an overview of the agenda and a quick coding session. Sandi did her homework on learning a while back and found that interaction is (part of) how people learn. But this my recap and I'll bow to my biases and start with the big picture.

Deciding when to refactor and how much is hard. Possibly harder than refactoring. Is the cost worth the value? We touched on some values and costs in the scope of: does this benefit your company. Complexity and churn can be used to eyeball how much time developers spend parsing code, which can be extrapolated to current developer cost in dollars. Sales numbers can be used to figure out what the known opportunity cost of delaying a feature is.

Sometimes higher complexity can lead to more easily communicated understanding of the domain. Do we need that understanding now? If we have it now, will we need it later? How fast do we need to deliver value today? Next year, or three years from now? What is the cost of leaving unexemplary code in our codebase today? We want to plan on having some sort of a future while understanding that we don't know what the future is and when we try to know, we almost always guess wrong. So much and more goes into a cost benefit analysis.

Axiomatic values

I think we can agree that these properties of code are desirable: code that is easy to understand, modify, and extend. They make it easier and faster to deliver value through code.

So... how do we do that? The rules of refactoring are simple and finite. Or at least close enough for me to reference Legally Blonde. There are many practices and procedures that one can follow to achieve those properties. Or at least get closer; I'm not convinced there is a holy grail.

Some practices we covered are

• TDD: red green refactor
• Shameless green: achieve green in the most stupid (least clever) way possible
• Flocking: a set of simple rules that produce complex results

Flocking deserves it's own callout in text.

Flocking

1. Find the things that are most alike (have the fewest differences)
2. Find the smallest difference between the two
3. Make the smallest change that will eliminate the difference
4. Repeat

To make the smallest change:

1. Parse the code: what's the smallest change that gets you a step towards similarity
1. Change only one line at a time (exceptions for ternaries, def/end, etc.)
2. Address only one abstraction at a time
2. Execute new code without using the result: check the syntax
3. Execute new code and use the result
4. Delete unused code

And at every step (substep) tests should still be green. If they are not, UNDO back to green and try again. You should only ever be one undo from passing tests.

Harder lessons

As difficult as being a great coder is, being a great human being is harder. Some things that I love about Sandi are (in reverse order) her ability to teach, her use of precise language, and the respect that she displays when she interacts with others. Teaching skills were easier for me to pick up on and Sandi explained some of them. Such as having the learner supply the idea or words is effective, from socratic method down to fill in the blanks. Skills such as empathy, curiosity, and humility are more difficult for me to pick up on. Perhaps it is innate behavior but I am hoping they can be, to some degree, learned.

My dogs are great at taking up space