Programming and storytelling


This morning, I was listening to my partner telling the story of my 5-year old daughter’s first bicycle ride to her mother… and this got me thinking about programming.

My partner was explaining that my daughter got really upset when she found that her mother had stopped holding on to the bike without letting her know. Obviously, my partner was telling the story to provide information to her mother (“your granddaughter can ride a bike!”), but she was also telling it with jokes that entertained both her mother and my daughter. Clearly, those two audiences required very different kinds of humour. But she managed to make it fun for both of them.

When my 2-year old son tells a story, he usually only sticks to the facts, as in: “I fell down on the floor”. This makes a decent story coming from a 2-year old. Not quite so from a grownup. An adult is expected to add some ornaments to the flow of words in order to make it interesting. But poorly chosen ornaments might make it incomprehensible for my son. From the thousands of possible ways to tell a story, the good story teller has to find the discourse and tone that intersect with her audiences’ requirements for a good story.

Some people are really good at that and are paid hundred of thousands of dollars to host family TV shows where they make parents and kids alike laugh their heads off. Similarly, the best family movies are the ones that have good jokes for all ages.

So it goes for programmers.

Novice programmers write for the computer and only for the computer. Experienced programmers take into account many more requirements, while still making the code work for the computer. As Kent Beck’s “Implementation Patterns” book probably explains pretty well (I have only listened to an interview where he talks about the book, but not actually read it yet), and as most experienced programmers have more or less consciously figured out by now, code is not only written for the computer, but also for your fellow programmers.

I remember writing my first program in Bill Gates’ BASIC (indeed!) language. I certainly had to fight so hard to make my intentions understood by the computer that, even if I wanted to, I didn’t have any energy left to make my intentions understood by any human being. Most beginner programmers will be like first-time victims of a theft at a police station in a foreign country. They will focus on providing the most specific facts about where their belongings were before they were stolen; they won’t care or be able to make the story a fun one to listen to.

Code is (or should aim to be) much more often read and modified than written for the first time. While the beginner programmer digs through more and more code, he may start to grasp that some modules are much easier to understand and modify than others. For example, he may realize that properly naming variables to reflect their roles, instead of just using “s” for a string or “i” for an integer, help a lot when understanding code, and make it both faster to modify and less error prone. (It might also help to be curious and to read experienced programmers’ advices and thoughts on the matter)

Experience grows with time and feedback and a senior programmer’s code will answer many more stakeholders’ requirements than just the computer’s. Code will have to be maintainable. It will have to be easy to test by automated tests and QA engineers. It will also have to provide good hints about causes of failures to support engineers by logging informations properly. It will also have to scale well and use resources cautiously to keep CxOs’ happy. And so on…

A senior programmer understands that code is not just bits for a CPU to process, it has a much wider and more humane audience. At the same time, it takes a lot of practice and/or talent to write code that’s music to the whole company’ ears!

Advertisements

About this entry