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

Programming Lesson: You Are The Bug...

There are a few things that inspire you, that make you think, that give you a new outlook. Somethings that help you introspect. And programming for me has always been the combination of all of the above things. Programming is what you could call, my way of praying or praising God.

This post is not completely technical, but I'm somehow compelled to share it with all my colleagues, friends, students and all those who read my blog. And I add some analysis for my project teams, so they start believing that software is equally philosophical as much its technical.

Programming Lesson 1: You are the bug. You are the solution

There was once a monk who would carry a mirror where ever he went. A priest noticed this one day and thought to himself "This monk must be so preoccupied with the way he looks that he has to carry that mirror all the time. He should not worry about the way he looks on the outside, it's what's inside that counts." So the priest went up to the monk and asked "Why do you always carry that mirror?" thinking for sure this would prove his guilt. The monk pulled the mirror from his bag and pointed it at the priest. Then he said, "I use it in times of trouble. I look into it and it shows me the source of my problems as well as the solution to my problems."

A lot of developers are great at writing code. They are really good at getting the results. A lot of people whom I've taught programming think that getting the desired output is the goal of writing programs. Thinking objectively is great when you want to finish the project, but when the bugs start calling, thinking philosophically is the best thing to do. And the first step is taught by this story!!

Realizing that the bugs appeared in the program, due to some thought process during the time of writing the program is the first step to improve as a programmer. I always ask everyone to have a bookmark of what's coming to mind when problem solving. The bookmark can be either on a piece of paper or in your mind. Later, whenever you find bugs, try to correct the thought process first and then the code. Understand that you have written the bug yourself, and "Unlearn the Learning". Forget all that you know about the program and start over again on the module with a different thought process!!

My reflective mirror on programming is the JavaVM/OS (with garbage collection) which I had written for my BS project. It ran Java programs on a microcontroller with 8KB memory and I implemented a robot on it. It was my masterpiece of art but it's a mirror that tells me I have to build things that are useful/understandable not just to me, but others.

You can have your own reflective mirror that tells you what you do wrong. Use it positively and learn from the good things and not so good things that "you thought"*, you created!!

Update: This was initially supposed to be a single post with 7 stories, but I realized that its going to be longer than comfortable to read all the posts. So I'll continue with a new post for each story

Part 2 - Lesson 2: Switch Off-Switch On

* - thats a different philosophy all together