How I learnt to Code

I did not like computers. This was the mid '80s and I was in middle school. I had only a vague idea about what computers were, and what they could do, and I certainly did not understand how they did it. I liked Physics and Chemistry, and I harbored the heady belief that I would one day become a professor of Physics…or Chemistry.

It was during these heady times that Mr. B visited us. Mr. B was a family friend who had a job interview in the city. Mr. B was also an M. Tech in Computer Hardware (or some such inscrutable field to me) from one of the Indian Institutes of Technology. In those times, an M. Tech from IIT conferred a god-like status upon you in India. Me, I had no idea what hardware or software was all about, so I asked him.

“What is hardware and software?”

“Hardware is like nuts and bolts, and software is the steps you follow to build something”.

Later that year, I was killing time in my mother’s school library, waiting for her to finish her day before we headed home. My mother is a teacher, and I had somehow gained compete access to her school’s extensive library. Call me lucky! So anyway, while rummaging through one of the book cupboards, I stumbled upon a slim little book called “Inside the Chip”, from Usborne Computer Books. This book explained the workings of the microprocessor using tiny robot caricatures. Each little robot represented a bit. A byte was a gang of 8 robots and a robot changed its color depending on whether it carried a 1 or a 0. “Inside the Chip” was the 1980s version of Larry Gonick’s Cartoon Guides Series. “Inside the Chip” also showed how a program is actually executed by the microprocessor as a series of low level assembly language instructions which flip gates on and off, and move data in and out of the processor’s memory. This book not only got me interested in computer hardware, but it also showed me how programs actually ran on the hardware.

It was a bit like learning how to build a house by first learning about how cement molecules bond with the sand, brick and stone, and then working your way up to knowing how the house is built!

In effect, I was getting to know programming from the bottom-up, instead of following the top-down manner that is prescribed by educators and schools today.

Mind you I have nothing against the top-down approach towards introducing programming literacy, but when your child asks you the following question, like my own asked me recently while using the drag-and-drop programming interface provided by his Lego Mindstorms set,

“This visual, drag-and-drop programming thing is fun and easy to use, but how does our computer actually run my program?”

You need to be able to answer this question in a convincing manner, or risk leaving a gaping hole in your child’s understanding of how software works – a hole that their new found interest in programming can slowly slip into and disappear forever. Starting as I had from the bottom up, I am proud to say that I had an answer for his question that convinced him.

So anyway, getting back to my journey of discovery, by the time I was in 8th grade I was feeling quite exuberant about my knowledge of computer hardware and software and how it all worked together. And in this state of exuberance, I decided to dial it up a notch. I joined a private tuition class where a lady taught BASIC to a group of us on a PC AT 486 desktop computer.

I was soon spending most of the practice time allocated to me in typing out verbatim, scores of programs from “Programming with Basic” by Byron Gotfried, and experiencing the joy of seeing them run exactly the same way that Mr. Gotfried said they would.

I gradually grew comfortable with the syntax of the language and started making my own changes to the programs.  Soon, multi-colored balls started bouncing on the screen from left to right instead of bottom to top as Mr. Gotfried had intended, my programs began asking me questions that were not there in the book, and the colors on the screen changed the way I wanted them to change. I was experiencing the sort of thrill that you experience while learning to swim, when one day you are treading water and you notice that your coach’s hand isn’t holding you up anymore!

On the point of getting comfortable with BASIC’s syntax, I have heard people say how programming is really all about logic and structured thought. According to them, the syntax is secondary.

“You can master any programming language quickly once you master the underlying data structures and algorithms”, they would tell you.

To that I would say the following: if you cannot get to a point in your learning where you are comfortable with the syntax of the language, the language has pretty much lost you as a potential user. A programming language’s syntax is like its user interface. Which is one reason, and at the risk of starting a flame war, LISP has so much tinnier a following than Java.

By the time I was in high school I was confident about my programming ability to the extent that I once boasted about it to a friend who did not know how to program. He listened to me quietly, then asked me a simple question:

“Do you know how to write a program that will sum up all the prime numbers between 1 and N?”

Even as the tail end of that question was hitting my ears, I felt my confidence sag. I put on a brave face and managed to stammer out something like,

“Yes, of course, er…that would be, (gulp), easy…of course”.

But inside me, I was crushed. How was it that on one hand, I was doing so much BASIC programming with such apparent ease, and on the other hand a simple problem such as this one had flummoxed me? I had no answer to this question at the time.

Knowledge and experience gained in subsequent years allowed me to shed some light on this seeming paradox. You see I had gotten very good at programming problems that involved reasoning about geometrical objects on the screen, bouncing balls, figures that could be dragged using key-presses and such. In effect I could tackle problems that involved visualizing the problem and its solution in geometric space. But I had developed almost no skill in simple procedural programming, which is what was required to solve the problem that my friend posed me.

An important conclusion emerged out of this realization.

Knowing how to code isn’t a 1 or 0 binary proposition, i.e. it is not that you either knew how to program or you didn’t. It is not like that at all.

And why should it be like that? After all most skills – cooking, driving, painting, masonry, carpentry – aren’t 1/0 kinds of skills. Of course one might argue that an accomplished coder would be able to able to code any sort of problem with confidence. But that is like saying an accomplished driver would be able to confidently drive both a unicycle and an 18-wheeler, and possibly everything in between.

Anyway, I must have soon forgotten about this ego-crushing experience involving the prime number puzzler. For I remember that in my 11th grade, I enthusiastically entered myself in an inter-school programming contest.

Each participant was given only one problem to code. I read the first two lines of my problem, and it dawned on me that the likelihood of my coding it successfully was, well, zero.

As with the prime number ego-crusher, I was to understand the reason for my failure in the programming contest only much later. In fact I did not realize why I failed until I took a course in undergraduate school which introduced me to a technique called Dynamic Programming. You see unknown to me at the time, the programming contest problem I was asked to solve had required knowledge of Dynamic Programming and the ‘memoization technique’. It would have been child’s play to code it if I knew about these algorithmic concepts at the time. But otherwise the problem was (and still is) quite nearly impossible to solve.

What I learnt was that as with any other discipline, coding is so much about slotting the problem into the right kind of category, and then pulling out the appropriate set of tools and techniques from one’s mental library to bring to bear upon the puzzler. In fact it’s a pretty remarkable thing if one can manage to become good at coding by simply taking a few coding classes through ones school and college years. Or signing up for an online coding course for that matter. In that respect coding is no different than other disciplines, be it plumbing or the practice of medicine. It’s a skill that one learns, hones and eventually becomes an expert at through years of knowledge and experience.

And so I have continued exploring the lush fields of programming. After I was done with BASIC, I tried my hand at Dennis Ritchie’s C, then Stroustrup’s C++, followed by Gosling’s Java, then C#, Objective-C and recently Apex. Along the way have been (most abortive) forays into LISP, Python, Jython and few other whazzits. Each time I leaned upon a language I knew, in order to understand a new language I wanted to learn.

I can’t help but wonder if the creators of all these languages did the same thing while sculpting their creations!