🔠#7: The Right Abstraction, why refactoring tickets must die, and how to set people up for success
Thoughts about right and wrong abstractions, why we must consider refactoring with every ticket, and how to use flow to set people up for success.
Hey,
In the last couple of weeks, I took a break from many things: Social Media, TV, and thinking too much about web development. But now I feel motivated again to think and write.
Recently, I thought about The Wrong Abstraction and how I feel that some people misinterpret Sandi Metz's superb article.
After more than a decade of being a developer, I finally realized that a maintainable codebase is a result of constantly working on making it so. The emphasis is on constantly–I wrote about my thoughts on why I think this means refactoring tickets must die.
Before my hiatus, I read an article by the genius Sarah Drasner about why flow matters more than passion.
Read on to learn more about all of these topics.
This is the 7th issue of my Recent Discoveries newsletter. If you don't want to miss the next issue, hit subscribe.
The Right Abstraction
There is an excellent article by Sandi Metz named "The Wrong Abstraction".
Prefer duplication over the wrong abstraction.
Although everything she writes in her article is 100% true, I think some people draw the wrong conclusions. E.g., that abstractions are generally unnecessary or even harmful. So here are a few thoughts about why I believe it is essential always to try and find the right abstraction when you identified a wrong one.
Ultimately we should strive for writing code that is easy to delete and enables change. Wrong abstractions work against this goal. Right abstractions help us to achieve it.
A classic example is an abstraction around our data persistence layer. If every part of our application relies on the fact that we're using a MySQL database, switching to a different database is borderline impossible. If we use the right abstraction, it could be a matter of hours or even minutes if there is a standardized driver.
Another one from my daily practice is browser automation for end-to-end testing. For example, if we create a custom wrapper around Nightwatch.js, we can switch to Playwright or Puppeteer in no time by simply adapting the wrapper but not hundreds of tests.
Abstractions can give us optionality. And optionality enables us to react to new challenges and changing requirements faster.
Refactoring tickets must die!
I think there is so much poor code out there because we somehow got convinced that things like refactoring and testing are extras. Things that we can do later. They are not! They are part of a professional coding workflow!
If we want to do exceptional work, we need to acknowledge that there is more to our job as simply writing code to implement some feature. Read more...
Set people up for success
Although I'm a big believer in utilizing flow state to achieve productivity, when I first read the title of Sarah Drasner's article "Why flow matters more than passion", I was skeptical. After all, I think my passion for web development is a huge factor in my career.
But she makes some compelling arguments. First, helping others to achieve a flow state can be a great multiplier for the productivity of a team or a company. Second, I believe that it's a lot harder to make people feel passionate about something than it is to help them achieve flow state.
Sponsors
Storyblok is a headless CMS with a Visual Editor. They’re currently working on their V2 release! You can join the beta crew if you want to be among the first to experience the new and improved editing experience.
Nuxt.js is a web framework for building modern apps & websites with Vue.