The Refactored podcast is a casual, ongoing conversation between two technology leaders trying to suck a little less each day. Frank Koehl and Chris Tonkinson meet weekly to discuss technology, leadership, and the underserved middle ground between the two. They stay pragmatic while spanning the strategic and tactical, but they never take themselves too seriously.
They take each other even less seriously.
The topics on any given show vary widely, but you’ll probably find something worthwhile every week if you are:
TL;DR - If you’re a dev, work with devs, and/or manage a herd of devs, we think (and hope) you’ll like what we’re offering.
Software engineering works like Legos: one concept builds on another, culminating in something that is (hopefully) pragmatic and useful. We constantly learn new things In the act of designing and building programs, and often these lessons take the shape of “I wish I had known that beforehand” moments. Change is the natural state of our industry: new technologies appear constantly, while the needs of businesses and users presents an ever-shifting landscape.
For these reasons, it is common and desirable to revisit code we wrote “yesterday,” and apply new lessons learned. We knock old logic down to the studs (or further in some cases) in order to replace it en masse and effectively apply our expanded knowledge. This “build-break-build” cycle is called Refactoring, and is the cornerstone of evolution for every noteworthy piece of software you use in your daily life.
Over the years, we realized this concept extended past software and into how we as individuals and teams grow and improve ourselves. Assuming each day is a good faith effort at being our best self, then naturally our behavior can and should change in the face of new information. Humans are naturally averse to change, so improvement works best over time, in small doses.
Once we realized that self-improvement was another form of refactoring, it was a small leap to apply the process to the teams we worked with day in and out. Iterative improvement is infectious, and can benefit any team dynamic (i.e. you don’t have to be a team lead to use it). However when applied as a management technique, it has the added bonus of implicitly declaring, “it’s okay to make mistakes, to be wrong.” As long as we learn and improve from each attempt, every “mistake” becomes just another stone on the path forward.
Iterative improvement to our code, our teams, and ourselves. The title wrote itself, really.
If you wanna dig into more of the sources for our philosophy, here’s a few starting points:
The term refers back to the shows' namesake. Refactoring is iterative improvement, which implies there’s a deficiency that can be corrected.
Humans not only resist change, but also naturally incline toward negative outcomes, e.g. “The glass is half empty.” Setting lofty goals, while admirable, can promote a negative feedback loop: “It’s too high, too far, I’ll never get there…”
To counteract this, we define improvement in negative terms. People are especially good at identifying their flaws – “I know I suck,” or “I know this thing I built sucks” – which creates a natural focal point. The act of “sucking less” establishes those imperfections as the starting point on a path forward.
Rather than an ultimate goal way out on front, the term eschews an implied destination. We as humans are inherently flawed, and so the road to learning and improvement never ends. There is no ultimate goal. Any “goals” we set for ourselves are better identified as milestones along the eternal path, but again humans just don’t work that way.
Small steps are within reach, and lead to taking another small step. Take yourself – your relationship, your team, your business, your code, anything really – as you are today. Pick an imperfection (the smaller the better), and remediate it. You’ll still be imperfect tomorrow, but you’ll suck a little bit less.
© 2024 Forgecrafted, LLC