If we were to treat programming like a professional sport, what would practice look like?
John Wooden, is considered one of the greatest coaches of all time. A basketball coach, he was known for short, intense practices that focused on the fundamentals. One of his key ideas was that if you're practicing at 80% intensity, you'll develop habits that only work at 80% intensity. When game time comes around, when the other team is giving it everything they have, you'll slip up because you're 80% habits, don't work at 100% intensity.
In the software world, we don't really practice. Not like athletes do. Furthermore, when we do practice, I believe it's only at 80% intensity.
The speed of quality execution is everything in software. The lower the cost it becomes to try something, the more at bats you have, the higher likelihood of ultimate success. When execution is slow, the cost of doing something becomes high and one of two things happen:
Engineers often try to solve this with abstraction. That is their training after all. Perhaps we can create a new library or a new framework that takes care of a lot of this standard issues for you? Sounds amazing, doesn't it?
Problem is, abstraction has two costs that people don't often account for. First, it's a new set of concepts that you have to teach your entire team. Second, no abstraction is perfect and the cost of being wrong is high - especially in the face of the rapidly changing environment during product development. They often give you the illusion of speed personally, but slow down the team as a whole.
Are new abstractions rooted in our laziness of only ever going at 80% intensity? Maybe the key to shipping faster is in drills, not abstraction. If so, what are our fundamentals, what does it look like to practice them at 100% intensity?
May 27, 2022