Programming: The finest steel has to go through the hottest fire

As the college season is in full flow, I'm back to my philosophical self and I've something for my students... Last week, I was conducting the regular Assembly Programming practicals, where I'm supposed to teach students 8085/8086/8051 ASM programming. Now, as much as I love programming and finding solutions to problem, I also love another thing: Creating problems for others to solve... and even if I know the answers, I would never give away the answer... come what may!!

So we started with all the instructions, available registers and memory allocation. Somewhere down the line, we started with a program to multiply 2 numbers. Now, as simple as I thought it was, my students didn't seem to think the same way. I told them that repeated addition was actually multiplication and they affirmatively nodded their heads, but the program wouldn't just come out from them. After close to an hour and me giving them numerous hints, we were still stuck at the loop!! They demonstrated it easily in a single line of C or C++ or Java, but ASM wasn't just clicking. That's when I affirmed, "Don't worry, programming doesn't come naturally to anyone... We all learn it our own way!!" And the class was stunned, similar to what I've seen at my office's training sessions... and the next question most of the times is, "Then how does it come naturally to you ??"...

"The finest steel has to go through the hottest fire!"... I read it somewhere, but then that's what is true about your individual talents. A singer's voice, a painter's hand, a composer's notes, a poet's verse... all may be claimed to have come from God or by birth, but its the desire to overcome obstacles and practice is what makes them achieve perfection.

Programming is very much an acquired skill, just like most things in life. Even logic for that matter doesn't come by birth. As we observe others follow a pattern of doing things, we follow that same pattern. The more we do the same thing in a way that is acceptable to our intellect, the more it becomes part of our existence and more natural the action becomes. When we first learn to speak, we probably think its harder than anything we have done before. Now as we know to speak, its easier than easy. Same is with programming. The more code that we observe, the more code we write, programming becomes more natural. Whoever says that logic to solve problems came easy, is either boasting his own ego or hasn't thought logically about it.

I was at the vegetable vendor the other day, who was talking of a way to solve the Bihar floods which made some 20million people homeless. His solution sounded really promising and as I know him for some years now, I knew he was intelligent. Huh... I wondered if programming would come naturally to him. He had never seen or used a computer ever but had passed high school. So if he could find a solution, it would mean that programming (read: finding solutions) came naturally to him. So, while he was selling vegetables, I sat beside him and blabbered the same things, I had told to my students at that lecture, but this time it was in Hindi and avoiding most tech-words. While I was speaking, I didn't even know if he was listening... He was busy selling vegetables, with his ~10yr old son and the aunties that came by kept smiling while looking at me. After a while, I asked him if he could multiple 2 numbers, given the instructions I explained... He thought for a while, picked up a few ladies finger (those long green vegetables), which he represented as instructions and explained me a perfect program to multiply numbers, not just 8-bit or 16-bit that would fit in a register-pair, but a multiplication program that would store larger numbers in ordered memory locations... Wow... that was superb!!... Unbelievable and brilliant, I said to myself!! I told him real instructions like ADD r1 r2, MOV r M,  ... and I told him to use those instructions and make a program to calculate modulus of a number. Hmmm... he thought for a while, but this time couldn't find a solution. He asked me many questions though, which he thought would give him an answer... But alas, no solution was found!!

I went back home and realized that may be it is the mumbo-jumbo words that divert our conscious efforts to find a solution. It may very well be the emotion of success that stops us from continuing to find the next problem and its solution. My students had passed earlier classes with 90% and more marks and were among the best students academically in the city.  Did that success get to them ??... Whatever it was, I realized persistence to find an answer to a problem gave us much better understanding of ourselves... May be programming teaches us to understand ourselves better than the problem at hand!!

Programming Lesson 2: Switch On Switch Off

Thanks a lot for the emails that I received as replies to the previous story!! In the previous lesson (You are the bug. You are the solution), we talked about how thought process creates bugs and how it can be reduced. This is second-part of the seven stories that I'm going to use to improve programming skills

Programming Lesson 2: Switch On Switch Off

Two monks were traveling together, an older monk and a younger monk. They noticed a young woman at the edge of a stream, afraid to cross. The older monk picked her up, carried her across the stream and put her down safely on the other side. The younger monk was astonished, but he didn't say anything until their journey was over. "Why did you carry that woman across the stream? Monks aren't supposed to touch any member of the opposite sex." said the younger monk. The older monk replied "I left her at the edge of the river, are you still carrying her?"

The story is a great lesson that teaches us how to switch between different projects. The old monk breaks the rules of his religion, but then he doesn't carry that event of his life through him.

When we are working on a project, we need to think only about that project and what it requires. Objectivity is the keyword here and extremely important to understand what goals we wish to achieve. We can bring all the nice features of our previous project and add them to our current project, but we need to understand what we wish to achieve with our new project. Just bloating every project with every innovation that we have done till date doesn't make much sense!!

But the lesson in the story is not to forget the past. Past success & mistakes teach us lessons, but the idea is not to be affected by those success or failures of the past. Also, we all play different roles in projects. Sometimes as a developer, sometimes database designer, sometimes tester on the same project. We need to objectively play each role and behave in a non-attached manner on all these roles.

For eg. My 2 current projects on MobileATM and Distributed Video Encoding, both require network optimization and peer management. But the requirements and devices on the projects are completely different. If I were to be attached to one technique that I discovered for intelligent load management and use the same in both the projects, I know either of the project would fail miserably in performance and scalability.

So the lesson to be learnt from this story is of detachment and to be unaffected by past success and failure. We need to learn to Switch On-Switch Off between different roles that we play. And this does not just apply to programming, but to life itself, where at times we are parents, friends, colleagues, students, kids...


* Here unaffected means "remembering & feeling" but not lingering and doing actions based on those feelings