In early July of 1984 Jim Morris, my manager, stopped by my office and suggested I start writing up my project. I thought it odd to start writing so soon; I had not completed my revisions to the computer program. My project focused on my converting the Grade of Service parameter from a constant value to a matrix value. This change would impact an implementation of a Dynamic Non-Hierarchical Routing (DNHR) algorithm applied to a telephone long distance network. While perplexed as to “why” I took Jim’s request to heart and learned another lesson on technical documentation.
My summer job at Bell Labs in 1984 provided me a wonderful opportunity to work with engineers developing a new method to route long distance telephone traffic. In late May I began my job and I had until nearly the end of August to complete my project. My task—modify existing FORTRAN code for a DNHR algorithm to support having variable Grade of Service (GOS) values instead of the same value for all routes. To make such a change in the code I took a constant—GOS and converted it to a matrix—GOS[x,y]; in which the matrix comprehended some assignment of GOS values according to route location. Besides learning about the algorithm (see previous post), I needed to understand code that someone else wrote. Then I determined the code changes to properly implement the algorithm with this change to a key parameter. While I honestly can’t recall the extent of comments in the code (a very good documentation process), I added my own comments to indicate choices made and the intention of the code. Documentation done! However, Jim wisely thought that comments alone would not be sufficient to help the next engineer.
This lesson of “starting the middle” has stayed with me for 30+ years. I have used it for my own work and my joint work with colleagues. Just like Jim in July I have walked into my summer intern’s cube and instructed them to start writing up their work. Writing equals thinking and engineers are paid to think. Writing sooner means thinking sooner and almost always, in my experience, has resulted in a better end product.
Have a productive day,
Dear Reader, What memory or question does this piece spark in you? Do you wait til the last minute to write? Do you document early? Please share your comments or stories below. You too can write for the Engineers’ Daughter- See Contribute for more Information.