One SIMPLE Way To Be A BETTER Programmer

The “one simple way” is nothing but “overcoming” the “delusion of creating future-ready code” which inevitably kills every developer sooner or later. Overcoming this delusion not only makes your code clearer and simpler but also helps you to grow in stature as a great developer.

Let me explain.

Back in my programming heydays, one fact was dogmatically taught to me at every occasion.

“Never write the same code twice”.

“You need to refactor your code and make it reusable for the “greater good”. Make the code akin to a black box which can be used by every other developer under the sun. Great developers leave greater code as their ever-lasting legacy.

So far so good.

Except that my code creations gradually evolved into ugly lumps of monstrous nothingness that became almost impossible to understand and interpret. My code hygiene went for a toss and I began to waste days and months “correcting” and “resurrecting” the demons which I had created.

Programming is hard. When you write a program, there can be anywhere from one to a gazillion lines of code, and you are going to make mistakes. Sometimes they’re big, sometimes they’re small, but no matter the size, they all take time to find and troubleshoot. Sometimes, you need help to come out of the “dangerous” vortex of “helplessness” that sucks you in rapidly.

And Sometimes, you just need…a rubber duck.

The concept of the rubber duck was first mentioned by Deane Parker in his excellent post “How to Give a Good Conference Talk”, where he described practicing a presentation out loud, in order to make it better. The idea of using a duck as a sounding board is not new but where it scores points is in its simplicity of use and the effectiveness.

The greatest advantage of using a rubber duck as a sounding board is that it is patient, it does not judge you and above all, it does not take somebody else’s time. There is something magical about explaining your problems out loud, even to something as inanimate as a rubber duck, that can help you see the solution to your issues.

As you go through your code, explaining it line by line to the rubber duck, you stop yourself and begin to think of the situation from the outside. You force yourself to assess yourself and gain an objective understanding of all that you had written in the “heat” of the moment.

And then sooner or later you get your “AH-HA” moment. The answer just comes to you.

And that’s how it feels almost every time: “Duh! I knew that!”

Here are some of the things the rubber duck sessions taught me about writing better code.

Writing a Reusable component is not required EVERY TIME.

Some will argue that you should always try to make your components as reusable as possible, because it requires you to work through all of those quality issues no matter what, and will produce better software. This would be great if your sole goal was to create the best software in the world, but nobody is paying you to do that.

No, you are being paid to write software of sufficient quality within the time and budget allotted. If you spend unnecessary time gold-plating your code, it may make you feel cool, but it is outright wasteful. You need to draw a line in the sand of exactly how good this product really needs to be and stick to that, otherwise, you’ll never finish.

You Aren’t Gonna Need It

YouArentGonnaNeedIt (often abbreviated YAGNI) is an Extreme Programming practice which states:

“Always implement things when you actually need them, never when you just foresee that you need them.”

Even if you’re totally, totally, totally sure that you’ll need a feature later on, don’t implement it now.

There are two main reasons to practice YagNi:

• You save time because you avoid writing code that is not required
• Your code is better because you avoid polluting it with ‘guesses’ that turn out to be more or less wrong but stick around anyway.

Make the Simplest Thing that could possibly work.

Extreme programming mentions two golden rules to write simple code.

· First, implement a new capability in the simplest way you can think of that “could possibly work”. Don’t build a lot of amazing superstructures, don’t do anything fancy, just put it in to make it work. Make the code pass the Unit Tests for the new feature (and all features, as always).

· Second, and this is critical to the rule, refactor the system to be the simplest possible code including all the features it now has. Follow the rule of OnceAndOnlyOnce and the other code quality rules to make the system as clean as it can possibly be.

Always remember, We’re not looking for the quickest way; we’re looking for the simplest result. So, we first break the existing method into pieces. That leaves the existing test cases running. Then we modify (simply, now) one of the little methods to handle the next test case and so on.

Next time you’re stuck, try the duck

Sorting through bugs, problems, and general conundrums is a fundamental part of programming. So developing techniques to swat your way through the bugs and find your way out of the binds is as crucial as learning all of the syntaxes.

And when you are stuck and nothing seems to be working, try the rubber duck.

So go out and find your own rubber duck, be it the classic yellow bath toy, or one dressed up like a pirate — pick one that you’re comfortable with and fits your personality.

Go ahead; Talk to him, ask questions, explain your problems aloud, clear your cobwebs and deliver great value in your code.

As Chris Pine has rightly said.

“Programming isn’t about what you know; it’s about what you can figure out.”

About the author-:

Ravi Rajan is a global IT program manager based out of Mumbai, India. He is also an avid blogger, Haiku poetry writer, archaeology enthusiast and history maniac. Connect with Ravi on LinkedIn, Medium and Twitter.

One SIMPLE Way To Be A BETTER Programmer was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.