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:
- The minimalists made a really cool documentary on Netflix called Minimalism: A Documentary About the Important Things
- Matt D'Avella talks about minimalism and self-improvement in his amazing YouTube channel.
- I also heard a podcast episode by Paul Jarvis recently that I strongly recommend: Enough already (checkout all the episodes if you're interested in entrepreneurship).
Top comments (47)
It's a beautiful piece. You're very correct. Commented code looks ugly and makes the code difficult for others to read and understand.
You mentioned the dependency clutter. But then you also encourage code reusability. Can you please clarify on this.
Thank you Ken!
When I was talking about reusability I was referring mostly to reusing your own code. Like, for example, don't write the same function twice with a different name.
But I'm also in favor of reusing code through dependencies, as long as the cost of integrating that dependency is worth taking.
Like with any form of minimalism, there's no "one size fits all", it's about being aware of the cost vs value ratio in your particular case.
🤗🤗🤗 then I couldn't agree with you more
Disagree about commented code; but there's a time and a place for it. If you have the capability to minify your code, then comments have no place. However, in the overall readability/understandability of a large system, and to assist with debugging, comments are invaluable.
Great article though.
I may have explained myself poorly on that point. I meant that commented-out code has no value. I'm in favor of comments that explain the purpose of code, as long as they add additional value.
Ah, my mis-understanding Paula. Totally agree with you then.
Commented-out code may sometimes - very rarely - have value, but usually as a warning not to do something. Like in a function document string, something saying "this used to be done like so, but there's a gotcha, so don't refactor it back".
Here are some additional resources about minimalism that I found useful:
I forgot to include Get rid of it 🤦♀😂, the app that we build and was on the US news!!
I love the 3-rd point. A while ago we had to deliver to a client a minimal part of the product, which was rewritten from 0. The first thing, that our architect told us, was "Don't try to guess what will be the next requirement. Just cover the current ones". Working in a software company can be a dynamic job and no one knows what will be the next big thing, that the client would have interest in.
Thanks for stopping by, Shymi!
Completely agree. It's hard enough to complete the required work on time, it'll be even harder if we keep adding requirements ourselves! 😅
Sometimes we think that the extra-work will be appreciated by the client, but it usually leads to incomplete features that give the impression of instability.
Excellent tips! I follow these myself.
My only addition...
I'd apply that only to comments describing what the code is and how it does it. Commenting intent ("why") has proven to be a massive time-saver for both myself and anyone else reading or working on my code. More about that here.
With that said, what you described with commenting is otherwise spot-on.
Couldn't agree more. Comments explaining the purpose of the code are totally ok, as long as they provide value (which I believe they do). I even wrote an article about writing comments to document your JS code using JSDoc.
Thanks for your comment, Jason! 🙏
Some really great tips here! I plead guilty of leaving commented code just in case. Also, I have never expected to find Matt d'Avella here 😂
Did you mean Mustache Matt? :D
That's ok, just promise me you won't do it again 😂
And yeah, Matt is awesome!
"Don't do stuff just because "we have always done it this way""
I would add this:
"Don't do stuff just because "we have always done it this way", or because "everyone else does""
Although an idea's popularity can be a useful indicator of its relevance, it is never a proof that it is ideal (or worse, ideal in your specific case).
This is a mistake that some people do, probably to avoid thinking, and it sometimes causes them to make terrible decisions.
That's right, mindfulness all the way!
Great article, agree with it all.
One comment through; your title for #2 made me think you were arguing to not comment code rather than what I realized were you arguing after reading closely; i.e. not leaving commented-OUT code in your commits.
Maybe consider changing the title to (I reworded to keep it short?):
You're absolutely right. Your suggestion is clearer and sounds better too, I'll change it. Thank you, Mike!
Commented code is a thing from the time before version control solutions.
I stopped doing it when i started using subversion.
But there are codebases I inherit from other developers. Most of the time I just remove it when I start working with the code in one commit.
There are rare occasions where commented code is a convenience. In those cases I add the comment tag KEEP_CODE followed by the date. I do a periodical check for this tag and get a report for code that is older than a month. That is my expiry date for commented code.
That's a nice tip. Last week I was looking for an ESLint rule to detect commented code and I run into a Github issue where they discussed that there're some cases where commented out code may be useful, like code usage examples. I have to agree that it's not a black or white thing.
The case that comes to mind at the moment is when the client is a/b testing features and they are not sure if they want to keep it of remove it after the testing. When my report comes in I mail them about it, and most of the time they will have a definite decision.
The only time I would put code usage examples in commented code, is when the project has a comments to documentation parser like JSDoc
Hi. I came here after watching Less Is Now on Netflix.
A well-constructed article indeed. I agree with your points there. I'm only in my first year as a software dev so I consider myself lucky discovering this quite early during my career.
Can't wait to read your next pieces!
Thank you Paula to share us how we integrate minimalist lifestyle in software development
Thank you, Emmanuel!