Introduction

In this article I’ll share how you can apply minimalism concepts in code to make it clean and be more productive.

If you already know what minimalism is and want to go straight to the point click here and you’ll be redirected to the first of six examples in this article of how I apply minimalism in code.

Around three years ago I was working on a software development company. I’d been working there for 5 years, and it was slowly becoming less and less fulfilling for many reasons (unrelated to this article). I wanted to resign and try freelancing, but didn’t know where to begin.

I started asking for help online and someone recommended me to watch Minimalism: A Documentary About the Important Things.

But, what is minimalism

Well, in the words of the minimalists themselves:

Minimalism is a lifestyle that helps people question what things add value to their lives. By clearing the clutter from life’s path, we can all make room for the most important aspects of life: health, relationships, passion, growth, and contribution.

After embracing minimalism I found it to be more than just a way to save money by living with less. It teaches us how to live intentionally, focusing on what we really care. It helps us look past other’s opinions and the pressure of “what’s expected” of us. But, most importantly, it encourages you to consider the value of things before incorporating them into your life.

I believe minimalism has also helped me be more productive and a better dev: Writing and committing only valuable code makes the code cleaner, easier to read and maintain and helps me make a better use of my time.

Here are some examples of how I apply minimalism in code:

1. Avoid dependency clutter

Or as I like to call it: Think before you npm install

There’re some great libraries/modules/packages out there that solve a lot of issues and save us time. There’s nothing wrong with relaying on them, but should we include a library if we’re only going to use it once or twice in the whole project?

Every new dependency we add to our projects has the following effects:

  • Increases the size of the project
  • You (and your team) have to learn how to properly use the new dependency
  • Regular updates may be required (to solve a security issue, for example). This also means you’ll have to thoroughly test the project with every update, and even do some refactoring.

Also, you should spend some time researching the package to make sure is reliable, secure, up to date, etc.

I’m not saying you should avoid using external libraries at all costs, but you should definitely think before doing so.

2. Commented-out code rarely has value

(thanks @mikeschinkel for the title suggestion)

You’re changing how a particular block of code works, so you start commenting some old lines and writing new ones. You test it, works ok, so you commit… no!

This is something I see a lot, and I believe it comes from the fear of not being able to “go back”. You shouldn’t feel insecure about code you’re committing & pushing. If you reached that point it means you already tested the changes enough, so why keep the old code? And even if you really need to go back, you could just look at your git history to find it.

Commented code is just noise: It’s not useful to the software, it’s distracting to the people reading your code, and it’s just not pretty. Get rid of it!

3. Less is more: Don’t write code “just in case”

Sometimes we make the mistake of getting ahead of ourselves and start writing code that, we think, may be useful in the future. As with commented code, we’re just adding noise in exchange of the possibility of it to eventually become valuable.

Let’s say that, for example, you’re working on the login feature for your website. So you write a class called UserService that contains a method called Login.

And then you say to yourself “As long as I’m working on this class, I may as well add a method that searches users by name. It’ll probably be useful for the next Sprint”. What’s the problem here? Well:

  • Maybe the “search users” feature never comes up, so you’re just losing time.
  • You’re adding unrelated code to your commit/branch/PR. This makes it harder to understand for code reviewers and/or PR reviewers.
  • This code requires testing. Would you spend even more time adding and executing the required tests or just leave the code untested? Both options sound bad.

So if you wait for the feature to be required instead of adding the code “just in case” you’d probably be making a better use of your time (and your team’s).

4. Challenge your ideas

Minimalism is about questioning things. Don’t do stuff just because “we have always done it this way”. Challenging ideas will help you get a better understanding of them and probably find better solutions or even issues with previous approaches.

Of course, there’re times to question things and there’re times to let things go to be able to move forward fast. Don’t get caught in analysis paralysis trying to question every little thing.

5. Take advantage of what you already have

Or what we call reusability. In software development is desirable for code to be reusable: it saves time, makes the code cleaner and easier to maintain, etc.

Sometimes is tempting to start a feature from scratch… play with new code, even try to improve what’s already done. It may be ok to do that in some cases, but be aware of the advantages of reusability and the costs of writing new code: possible bugs, more time spent building, documenting and testing the feature, you may have to introduce the team to the new solution, etc.

6. Avoid “shiny object” syndrome

There are features that are more fun to build, but we need to focus on what’s important: what do our users need the most?

The priority should be our users’ needs, regardless of how fun or interesting a feature might be. Be aware of your own bias and try not to be influenced by it.

Some resources

If you’re interested in getting into minimalism here are a few resources that may help you get started:

This post is also available on DEV.