I didn’t realize it when I set out, but I think I’ve started to figure out what role I play on my teams. I enjoy removing the unnecessary. I feel a sense of satisfaction when the thing before me is in its minimalist form. Now before you bail thinking that I’m going to try selling you on removing things from your life or that I’m a fanatical minimalist here to preach , I’m not. Minimalism isn’t about reducing things till there’s nothing left, and despite Sol LeWitt being one of my favorite artists I don’t think everyone should be living in IKEA styled homes.
So if I don’t mean this stark white, barrenness when I say minimalist what do I mean? I’m talking about removing the things that, as Marie Kondo might say, don’t spark joy. Or being a software developer this to me means removing the features which don’t bring joy to my users, nor to my team. The software I build should bring joy to your life even if the task it’s used for is boring, or worse brings displeasure (like doing your taxes).
How to Bring Joy to Users?
No one wants to fill out forms, but as developers we can make that experience better. Just this past week at work we removed optional fields for many of our forms. These fields only distracted from what the user was trying to do. We de-cluttered the process so the user can get their job done and move on with what they truly care about.
We also made our forms consistent across all of our app because no one wants to have to re-learn how to fill out a form just because they went to a different page. The user isn’t using our app because they want more work, they’re using it to give themselves more time to focus on their business and the things that bring them joy.
We didn’t only remove though, we also added. We added new paths to for the user to get to their destination. We added color, a bit of flair, to brighten their day. We added clarity around names to make it easier to distinguish intent. We created just as much if not more than we removed.
How to Bring Joy to Software Creators?
This is where it all really comes together for me. Bringing joy to the customer is commonplace everywhere I’ve worked. Making the customer’s life easier means they want to come back, and if they want to come back then they’ll continue to pay you for your services. It’s how we accomplish this that often brings dissatisfaction for me and other developers.
Take a look across the landscape of developer tools and you’ll see an endless supply of tools that make it easier to add more code, more quickly. A million and one banners and quips about how Popular Framework makes it easy to add more, and do so faster than ever before! There’s always another blog post on how to add another service to your tech stack. How to add, add, add! It’s all written with a blind disregard for the developer who’s written their app, has their users, and now needs to change a feature. What about the developer who inherits 10k, 100k, 1M lines of code and needs to remove a feature? What about the developer who’s trying to pivot their startup from who they thought their customer was to who their customer actually is?
What about me?
Finding Joy
This was me until a couple years ago. Every project I came into had endless features for the user, and no easy way to remove them. It didn’t bring the user joy, and it brought me even less. We couldn’t remove fields because no one could figure out how they all worked together, so instead we’d hide it from the user (but not the developer) or worse yet rewrite it all. The company would spend millions of dollars throwing away the working product to create it brand new, but “better”. I knew there was a better way but it’s hard to convince teams who’ve become numb to this normalcy.
Last year I finally got a chance to be a part of not only a team but a company that embraces both refactoring and deleting code. Where refactoring 1/2M lines of code is normal instead of a complete rewrite. Since joining, I’ve both created and removed features. Giving the users the features they need and removing those that only got in their way. In the last 3 months alone I’ve been able to delete over 20k lines of code from our app. Removing code the user never sees, and only distracted my coworkers from accomplishing their goals.
Make Deleting Code Easy
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Antoine de Saint-Exupéry, Airman’s Odyssey
Cool, so I found a company that makes it easy, but what about everyone else? Well if you’re like me and you liking deleting code then lets make it easier for you. The simplest route may be to join me at Vendr, building an app that brings others joy by reducing the work they have to do managing vendors. But that’s not for everyone. Changing jobs can be challenging, and you might like your current employer.
The next route may be using our tech stack. The tools that have allowed me to delete so much code with ease is actually quite small, it’s just Elm and elm-review1, nothing more. While many languages attempt to remove unused code, Elm takes the opposite approach and only includes the code that is actually used. Live code inclusion. This means you’re never2 including unused code. While Elm doesn’t include the unused code in your build it still exists in your project, that’s where elm-review comes in. This is also the magic that allows me to delete so much code. With just 6 elm-review rules I can go about my day and let my linter remove all of the unused code from my project!
Again, this isn’t for everyone. Maybe your team or employer doesn’t want you using Elm. Maybe you don’t want to or even can’t write Elm! Then I suggest reaching out to your communities language and linter authors and ask for better code deletion support. Make it known that deleting code is just as important as writing it.
Can I Delete any more?
Yes. I’m still finding more to delete every week. We’re also trying to find ways to make it easier to delete on our backend, which is written in TypeScript and running on AWS Lambda, and that requires new ideas and new tools. I know at some point our deletions will also slow down when we remove the last of our deprecated code. Though the task of removing unused features will never end.
As our users needs evolve, we’ll also need to evolve. Adding features here and deleting feature there. But I know that we’ll be able to keep up as I’ve witnessed first hand how easy it is delete the unused code. I know that I will find lots of joy in the coming years bringing joy to our users, and to my coworkers.
- If you’re interested in linters or just elm-review, checkout Jeroen’s blog, or follow him on Twitter.
- While Elm does exclude unused functions and modules, it still includes unused record fields and values defined in
let .. inblocks. Some of this can be removed by elm-review. Additionally, by applying JavaScript minifiers we can typically remove even more from a production build.
Wolfgang's Musings 