Member-only story
Adopting a no-code mindset
Writing code has never been easier. Yet, effective teams do the opposite: they focus on shipping less code. Learn why and how you adopt a no-code mindset.
Building and maintaining software is hard. As the team grows, so does the code base. New features are added, and existing features are tweaked so that they somehow integrate with the latest changes.
Eventually, our simple app turns incredibly complex. A few boilerplate files morphed into thousands of lines of intertwined code. And with each new line, there is a potential place for bugs to hide.
Now, we could pretend to be Jeff Bezos and tell ourselves “every day is day one” as we wake up and look into the mirror. But, unfortunately, this does not work in software land. There is only one “initial commit”. And you can’t escape the growing complexity of a codebase that easily.
This scenario does not sound new to most developers. Every codebase eventually starts to have pain points. People make bad decisions all the time. Repercussions, however, often only show up months after.
So, how do we combat this vicious battle? If all we do is write code, yet code seems to work against us over time, is there a way to win this fight at all?
Actually, there is a very simple approach to maneuvering this conflict.
“The best code is node code at all”
This was the title of a recent article I read. Though the article was published in 2007, the idea still holds today. And I could not agree more.
It most likely sounds demotivating at first though. We all love writing code. Otherwise, we hadn’t become developers. And yet we need to be intentional with what we ship. The less code, the better.
Less code has fewer moving pieces that have to be maintained and that could potentially break. Less code lets new coworkers onboard even faster. Overall, a leaner codebase enables your team to work on a codebase more reliably and confidently.
To be precise, less code does not mean you should sacrifice readability or code quality. There is no argument about prioritizing an easy-to-understand function over a fancy-looking one-liner.
