Such an insightful essay …

Paul Graham has impressed me time and again with his stunning insight. Whenever I read his writings, it’s as if he plucked his ideas out from my own head and then put pen to paper. His latest, Holding a Program in One’s Head, contains several gems that I personally have experienced several times at work.

The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

This is spot-on, and I notice this a lot during my lunch break. Sometimes I can’t get a program or problem out of my head and occasionally I even come up with a solution not 10 minutes into my lunch break and then I can’t wait to get back and finish it. Other times however, especially if I have lunch with my colleagues the whole ‘problem space’ I’ve built up in my head simply vanishes. Due to the amount of work it usually takes (maybe a half-hour to an hour) to re-load my brain with the problem I was working on, a lot of post-lunch time is wasted and sometimes I can never recreate the problem fully again because I tend to be sharper in the mornings than in the lazy afternoons.

Since there’s a fixed cost each time you start working on a program, it’s more efficient to work in a few long sessions than many short ones.

I have often wanted to do this, but it’s almost impossible to do. There is always lunch, some other interruption, going home, eating dinner or something similar. On the weekends, however, I sometimes manage to stay up late and can work uninterrupted for quite a while.

Rewriting a program often yields a cleaner design.

True sometimes, but I agree with him that even the process of rewriting a program can lead to significant insights; even if the rewritten program is not a huge improvement.

Instead of summarizing the whole essay here, I highly recommend that all programmers and their managers go read it. Even non-IT staff, such mathematicians, whose work involves long-stretches of thinking, and constructing problem spaces in their heads will benefit from the advice in this essay.

I haven’t been paying attention to my RSS feeds recently and I forgot just how good some people are at writing and expressing their insights Paul Graham and Joel On Software are two blogs (journals?) that I really enjoy reading.

Technorati Tags: coding programming software

Some writing tips

I’ve spent the past 2 weeks on and off reading ‘Bugs in Writing’ and have definitely learned about some mistakes to avoid in writing. In order to fix these mistakes, it is best to do a lot of your own writing so you can find them and eliminate them. I will try to write a brief note about some common mistakes here. I haven’t asked the author for permission, so I will try to do it here in a very general and concise manner.

#1. Avoid using passive voice. Passive voice just means that when you say something about the world or some event that happened, make sure you identify ‘who or what’ was involved. The ‘who or what’ is commonly referred to as an agent.

For example,

Wrong:
The tea was made.
The program was written.
The computer was dropped.

Correct:
Mark made the tea.
Jane wrote this computer program.
Christopher dropped the computer.

#2. Speak directly to your reader. Never address your audience as the reader or refer to yourself as the author. You should speak directly to your reader. You should refer to her as you. If you are the sole author of a book, use I and if you have co-authors, use we. In addition, avoid using one, as in One should realize … or One has written.

#3. So, So that and Such that. Just remember the following:

So means therefore
So that means in order that
Such that means in such a way that

#4. Two or more. Use the terms between, each other, either, and a couple to refer to precisely two entities; and you should use among, one another, any one of, and several to refer to more than two entities.

I will add some more tips later on, but probably not many. The problem is that I haven’t gotten permission from the author and several of the tips have examples that are best quoted verbatim from the book.

Been too long …

I know I haven’t updated this blog for a while … in fact I frequently abandon it for a few months while I carry on with life’s struggles. Keeping up with my job, finding time to spend with my beautiful wife, all the while attempting to keep current with the fast pace of technology growth.

Starting today, I will try and change that. You see, in order to motivate myself to keep this blog updated I have decided to set myself a goal and complete it. I will keep updating this blog not only with my progress, but will also write about what I have learned as I go along.

So my first goal will be ‘to improve my writing skills’. I have enjoyed writing stuff for a long time now and friends have occasionally told me that ‘you could be a really good writer’. Well I’ve finally decided I should give it a shot.

To be honest, I’ve never been good at grammar, and people find that hard to believe. I’ve simply developed a good ear for what ’sounds right’ based on my perusal of several newspapers, magazines, novels and books over the years. Learning a lot of vocabulary while preparing for my SATs and reading ‘lots’ has really helped.

The first book I’m going to try and read and understand is going to be Bugs in Writing, which I bought several years ago, but never got around to reading. It is written mainly for people who come from a scientific or technical background and hence is perfectly suited for someone like me. Each chapter aims to analyse and fix a single ‘problem’ and you can read each chapter in whatever order you like.

With that, I bid you farewell. I believe my next post is going to be about ‘passive/active voice’. Exciting times indeed