Dumb Code Beats Smart Code - Don’t make the mistakes I made

and how do you practically achieve that..

Have you ever dealt with code where complexities seem to be on purpose? As if it was written to prove how knowledgeable the coder was?

I have been coding professionally for more than a decade. You can add a couple of years more if you count the time when I used to code for fun. My thought process has evolved multi-fold during this span of time.

In today’s blog, I will tell exactly why you should never write smart code (almost always).

Smart code- I mean the code which has latest frameworks, the new cool shiny hack or any other complex technology etc.

Dumb Code- I mean a code without fancy frameworks, algorithms or any complicated technology but functionally works as per the expectation.

Meet my junior self

Imagine me - fresh out of the college gates, with every coding concept on top of my head. I felt I was ready to conquer the tech world, armed with OOPS, design patterns, abstractions, and what not.

I imagined my professional debut as a scene straight out of a movie, where my complex creations earned me applause from the tech veterans. I used all my knowledge of cool concepts in my first project and submitted the PR.

I waited for a well deserved applause. Except that never happened.

Instead I got one million review comments. All the code reviewers were confused and overwhelmed at the same time.

My teammates, trying to build on what I thought was a masterpiece, were stuck trying to find their way through a jungle of complexity I had proudly constructed.

But I learnt my lessons eventually.

Fast-forward to today

After going through the journeys of learning and failures, I can tell you confidently that dumb code wins hands down every time. Why?

1. Writing code is not the end goal.

   Software is the price we pay to solve a business problem. It costs a lot of time and money. It might look like every piece of code is a timeless piece but softwares are deprecated all the time, they are re-written all the time if the underlying business situation changes.

2. Writing and maintaining a software is huge time-sink.

   Someone needs to read your code in the future to fix bugs or add new features. Every line of code written once, needs to be understood by at least 100 times. A complex code is harder to write, harder to understand and harder to test.

3. Complex code is more likely to introduce bugs. Now and in the future.

Writing an unnecessary complex but smart looking code is counter-productive.

Dumb code is efficient.

Dumb code is easy to test.

Dumb code is easy to maintain over a longer period of time.

---

Example from the real world

Peiter Levels is a serial entrepreneur (built the famous levels.fyi, nomadlist etc.). He builds simple apps without using fancy frameworks but knows his customers well. One of his website RemoteOk is just one PHP page but generates a $60k per month.

I get it. While working in a company you can’t be as scrappy as this guy. But you get the point. I challenge you to rethink your approach next time -

1. Understand the problem statement deeply. Talk to people or customers. Don’t assume stuff. And for sure, don't build for future imaginary use-cases.

2. Ask yourself, do you absolutely need to write a software for the problem? There are so many tools like excel or SQL which can do a lot these days. Ask if the solution needs to be extended or does it need to be used in different regions of the world, or does it need to auto-scale etc.

3. If you do write a software, implement it in the languages and frameworks which your team is comfortable in.

4. Just write the dumb code. For example, don’t go overboard with DRY(Don’t Repeat Yourself) principle and it’s okay to same logic at two places if the simplicity demands it, write a simple for loop instead of that cool recursion, don’t optimize for the performance too much etc.

But introduce complexity when needed

I am not telling you to never write a complex code ever. Practice writing simple and dumb code by default. Add complexity if it is really needed.

Imagine writing the core implementation for an finance exchange - optimize the hell out of it(complexity is more than okay) because that’s your business edge.

Use the cool and shiny technologies when it simplifies your business use-case.

---

This week’s must reads :

1. 3+1 strategies to track your achievements by

   Fran Soto

   Tried and tested strategies to apply them in your day to day developer life and grow better.

2. Planning is overrated, doing is underrated by

   John Crickett

   Underrated but effective advice about not just doing the mental gymnastics, but to take actions.

3. Stay Positive and “it is what it is” or The Power of Positive Thinking by

   Petar Ivanov

   This post is going to inspire you. Petar tells you a personal life changing story about how to tackle adversities in life.