One Hard Thing No One Teaches About Programming

Mohit Mamoria
Mohit Mamoria is a hacker-turned-founder. He is an avid reader, occasional writer and tweets regularly about everything at @mohitmamoria.

Raise your hand if you think you know how to write software. Or let’s just say – if you’ve ever written any piece of code. Or better – if you’ve ever even tried to learn writing code. If you’ve got your hand raised, let’s talk about one thing that you should have learnt, but no one told you. (In case, you haven’t got your hand raised, see you, tata, bye bye.)

To set up a little context, I’ve been writing code for last 11 years and have also helped people do it in last few years. I’ve got my hands dirty in many languages, frameworks and have built things ranging from viruses to games to enterprise-level apps.

Throughout this journey, I’ve learnt a lot of things the hard way, but there’s one essential thing which is rarely talked about. It isn’t about the new fancy language or about the new framework or a new technique to get started to write code.

The One Hard Thing

I am talking about discipline. Discipline to write code that everyone can understand. Discipline to refactor code when it tends to become messy. Discipline to put efforts when naming things in your code. Discipline to think about how the written code might evolve in near future. Discipline to not stop refactoring when your code starts working. Discipline to understand that there’s always something to be learned. Discipline to write code every day to form a habit (because no matter how many books you find titled “Learn X langauge in 10 weeks”, you cannot learn to program in anything less than 7-8 years).

Discipline to Refine

Programmers are just taught how to make something work. This puts an impression in our minds that making something work is the end-goal. But every programmer will learn it over a period of time that making something work is just the starting of a long and tedious journey.

Make it work. Make it right. Make it fast. In that particular order.

First thing to do is to write the messiest code you can write to just make it work. But then, you cannot stop right there, commit the code and push it to the remote repository. You cannot. Once you’ve made it work, you’ve got to sit and just think. Think where exactly to put this piece of shit. Should you abstract away it as a service or as another package or as simply another class?

New feature/code is always added at the easiest place.

New feature/code is always added at the easiest place, but that’s not always the best place to put it. If you’re writing any non-trivial software, it will evolve over next few decades. With each new feature, you gotta think, how it might evolve in near future and then refine your code.

Even if it takes a full day just to think where to put new feature, do it. 6 months later, you will thank 6-months-ago-yourself.

Discipline to Refactor

That was the discipline required when writing new code for the first time. What happens to the code you’ve already written? You refactor. Regularly.

What you thought to be the best written code last month isn’t the best code anymore. It isn’t a good code now. It sucks now! Code once written should not become tabooed. A small method written couple months ago can now be abstracted away in a service today. A class written last week can now be divided into two classes now. The code which was dependent on MySQL until last month can now be made independent of underlying technology (hint: Factory Design Pattern).

Building something is easy and fun. Keeping it beautiful isn’t.

Planting bushes in your garden in easy, but trrimming and maintaining it takes effort.

It takes sincere discipline not to give up when reading your old code and curse your past self. Infact, if you find your old code ugly, congratulate yourself because you’ve outgrown yourself. Pat your back!

Discipline to Name

They say there are just two difficult things in computer science – invalidating cache and naming things.

If you’re just beginning, this might sound silly, but wait a few years and the only thing you will ever dread when writing software will be when you’d have to name things. You will have moments when you will be confused whether you should name your variable “defaults” or “defaultList”.

When you’ll be required to find all your users who signed up in last 12 hours, you’ll be tempted to create a method called “usersSignedUpInLast12Hours()”. What if tomorrow the business requirement changes to find users from last 24 hours? Everywhere this method was called has become meaningless now. If you’d have called it “latestUsersByHour(int hour)”, the name of method would’ve always stayed relevant.

Never hardcode things which have even a slight tendency to change.

Discipline to Fail

If feels so great when your code works, isn’t it? But what you need to find out is when it doesn’t work. And then fix it.

A very common beginner’s mistake is to stop as soon as your code works according to the way you want. It is easy to be in denial that your code will never fail, but it takes discipline to break your code and then fix it.

Try sending an ill-formed input – does your code handles it well? Try asking for data which doesn’t exist – does your code fails miserably or returns a proper error message? Become a hacker, break things yourself so that no one else from outside world breaks it.

The more you break your code inside, the less it will be broken outside.

Make something, break it, make it better. Repeat.

Discipline to Grow

The only way to thrive in any industry is to become irreplaceable (or atleast tough to be replaced). Just lean back in your chair and think to yourself, “Can I be replaced by someone else easily?”

If the answer was Yes, you WILL be replaced. Sooner or later, you will be. What to do? Outgrow yourself. Learn something new everyday. Every single day.

If it’s difficult, break it into easier chunks. If it’s huge, break it into smaller chunks. If you’re tired, learn something small.

The most fatal mistake anyone can make is to stay in denial. And how not to make this mistake is to grow a little but daily.

Knowledge works like a beard. It doesn’t show in a single day, but over a period of time, it does.

When growing, people around you might scold you, curse you or say you cannot do it. It’s good to have these people around yourself. When you’re doing something wrong and no one tells you, it means they have given up on you. Don’t let that happen.

You do not need to know 10 different languages to be a Programming Player. Just one trait – discipline. Trust me, once you have that, learning a new language/framework/design pattern is a matter of a few hours. Yes, just few hours! But for that you’ll need to invest years into disciplined practice.

In case you wanna share some more essential things which usually are not taught, please do it in the comments for everyone to read.

Note: Most of the things above are applicable to most of the industries/jobs, but having first-hand experience with programming, I find it easier to act like an authority. 🙂

Note: We at Inc42 take our ethics very seriously. More information about it can be found here.