It was years before I started keeping notes. Even in my college days I rarely took notes, relying on handouts and memory instead. In my first few professional jobs I just did my day-to-day thing. I had the one project, and I always knew what state it was in. I felt no need of notes. I was foot-loose, fancy free, and unencumbered.
I read an article in 1994 espousing the wonders of keeping a work jotter. I tried it for a week or two, but like diary keeping after new years day, it was a good idea that just wouldn't take hold.
Then I started working with a compulsive work diarist. He'd trained as a scientist, and consequently knew more about the ear canal of the common cricket then your average software engineer. Thankfully he also knew more about software engineering then your average software engineer too. He had an array of A4 books on his shelf, neatly labelled and dated. Every meeting, decision, conversation, thought, was written up, in the style of the scientific method, with a green tortoise shell fountain pen. Consequentially his knowledge of our product, its history, and who said what, where, and when was encyclopaedic.
Spurred by this inspiration I resolved to start an engineering notebook at the start of my very next major project. Two years later I bought myself the thickest A4 notebook available and set out to document my journey through a major piece of software development. I approvingly noticed that my VP of engineering carried a notebook to keep track of the many intertwined projects within our division. But, her notebook was A10. Size matters. My notebook was too big. It couldn't be with me always. My entries petered out.
Three years later, at the inception of my next project, I went for a midsize, thin, A5 college notebook. Success! I have now been a compulsive note taker for two years. And, I'm not going back to my unenlightened self.
I find it serves multiple purposes for me, over different time frames. In the short-term, day-to-day and week-to-week, I mostly maintain to-do lists, and project status information. Interspersed with this is some commentary, and description of problems that arise, the possible directions to take, and the currently preferred solution.
In the mid-term, month-to-month, I scan back through the pages seeking threads of thought that went un-concluded. Or, for a reminder of the problems that were hastily swept under the carpet in the interests of unhindered forward progress. [The code written in the rush of pub lunch confidence.]
In the long-term, year-to-year, I get some historical perspective over how the project progressed, both of the team and of myself. Writing my end of year appraisal is no longer the soul-searching agony of: 'what the hell have I been doing all year, all that time and only a few thousand lines of code to show for it.' I now have a day-by-day, blow-by-blow record of what I was doing.
Reading your own forgotten words a year later can be quite enlightening. From how incredibly insightful you can be about the final form of the project, to how incredibly naïve and deluded you were on how much effort it would actually take.
Professional advancement comes from considering feedback about your performance, from your management, from your peers, and from your own introspection. There's none as devout as the redeemed, so I fervently recommend the maintenance of an engineering notebook. Start yours today.
Apologies to Björn Karlsson for two mistakes made in the development and presentation of his Boost article published in Overload 47. Firstly, a draft of the article was published in place of a more polished final revision, and more noticeably the header and byline of the article were omitted. Graciously Björn has accepted our apologies and has offered to write a follow up article covering one of the boost libraries in more detail. I hope that other boost library authors will follow suit in discussing their fine work within the covers of Overload.
http://www.meadweb.com - My brand of notebook. I suggest green for work, and blue for your Overload articles ;-)