I started my software career working for ESystems, an aviation contractor now part of Raytheon. There, I had a mentor who taught me how the software business worked. Sure I could sling some code. That was my hobby through high school and my major in college. But he taught me how software was done in the real world.
One of the skills he taught me was keeping an engineering notebook. I've adapted his system over the years, but the spirit of his system is still present.
I start with a composition notebook. Some people choose to use graph paper, while others like the elegance of Moleskine, but a simple composition notebook works for me. Do not use loose leaf paper, a legal pad, or a spiral notebook, as you should never be tempted to remove pages.
Keep a separate notebook for each project. You can have just one for your employer, if you like, but definitely separate that from your personal projects. I even go so far as to keep my personal projects separate from each other, even though that means I have a few books on my shelf with only the first three pages filled in.
Record the date
I start each morning by entering the date. By its very nature the engineering notebook is chronological, so embrace it.
I also record the first date on the cover of the notebook. When I run out of pages, I'll record the end date as well. Unfortunately, chronological organization means that I always have to look things up by date, but this information is usually available.
Under each date, the notebook is a list of trees. At the root of each tree is a task. A task might be a feature, a bug, a research item, or anything else that is small enough for me to finish within an hour or two. Below that, I'll use indentation and lines to break down the task into individual units of work. Lines are especially useful for carrying the hierarchy from one page to the next.
Next to each entry, I'll use symbols to indicate progress. A check mark means done. An open box means that the unit of work is done but needs to be tested. It gets a check mark after the test passes. I put a star by information that I'll probably need in the future. An arrow means that it'll get done later. An arrow pointing to someone's initials means that I've delegated the work to them. An arrow pointing to a vertical line means it'll probably never get done. My system of symbols has evolved over time, but it pretty much covers all of the situations I need.
If I get interrupted, I'll start a new task tree for the new task, leaving the old one hanging. When I get back to the original task, I start a new tree below the interruption. This is the only practical solution in a paper-based system. And it is also a good way to measure the frequency and cost of interruptions.
I use reference numbers to cross-reference items outside of the notebook. Whenever I check in some code, I write down the revision number in parentheses. Whenever I work on a bug, I write down its ID with a pound sign. And when I prepare a change for deployment, I write the ticket number underlined. I can't count the number of times that I've been able to glance at my notebook during a meeting and find exactly the information I need because of this system.
Pull it forward
Once a week I go back through the notebook to find tasks that have not been checked. If they have been finished, I'll check them off. If they can be delegated or ignored, I'll do so and make the appropriate notation. If they still need to be finished, I'll write them under the current date. I'll then draw a box around all of the tasks that I've carried forward. This gives me a backlog that I can refer to quickly to ensure that tasks don't slip through the cracks.
We deal with far too much on a daily bases to keep everything in our heads. I've found that this system helps me to act more like a professional by maintaining a history of important facts and tasks in a portable and accessible package.
What is your system?