Intro
This one is mostly for my own benefit, to document how I use a notebook while working and programming. It describes how I organise the notebook and how it is used.
Layout
One task per page
I only ever include one task per page (but sometimes multiple pages per task). This is to ensure it is easy to quickly flick through the notebook and find the specific thing that I'm looking for, without needing to scan the entire page looking in case what I want starts part way down the page.
Page has title and ticket number
This is also to ensure it is easy to flick through and find a specific page, just need to read the title of each page not the entire body to know what it contains.
Each page has a date
To keep a record of the timeline of events. Dates are in the format YYYY-MM-DD obviously.
Pages numbered & indexed at back
Again to help find the pages relating to a spcific project. Index is grouped by project (not case or task). Also means a quick scan of the index can show what the notebook contains.
Contents
What I actually use the notebook to record.
Planning
Meeting notes
Before the meeting write notes on anything I need handy for the meeting (if anything). Then record the outcomes of the meeting & what needs to be done as a result, often this is done after the meeting has finished. Also include in the notes who was present in the meeting.
Planned designs and sketches
Plans for how I plan to implement a feature. Can include UI sketches, flow diagrams etr. or a wordy description (in reality, a mixture of both). Obviously once finished this will be documented elsewhere in the public docs or the internal wiki, the notes are for my use during development.
Programming
TODO lists
The most common use during programming is a TODO list, with a checkbox next to each item to mark when complete. Allows progress to be tracked and helps to stay productive by focusing on the tasks that are actually required. Often written before I start then added too as new tasks come to light. Each todo list is for one case only, remember one page per case.
Bug fixing
Description of a problem
Often simply describing the problem helps to identify the cause. Essentially a type of rubber duck debugging.
List of potential causes of a bug
If there are multiple possible options then often I'll write them out in a list with checkboxes. Each possibility can then be checked in turn, marking them with a cross if it's confirmed that isn't the cause.
Description of a bug fix
For particularly difficult or interesting bugs it's often helpful to write a description of the fix once solved. This helps analyse what went wrong and identify how it can be avoided in the future (eg. through better logging, more tests or a change in dev process). Also provides documentation so if another similar issue arises I can look back and check how it was solved in the past, as a hint on where to look for this problem.
Post-Its
This isn't related to the notebook itself but for some things that I don't want documented forever I often use a stack of post-it notes on my desk for a couple of uses.
Quick notes
Specifically notes that won't be of use in the future eg. IDs, values etr.
As a reminder for small tasks
If there is a small task that needs to be done tomorrow or next week (things that generally won't have a ticket raised) then a post-it note with the task on ensures it isn't forgotten. One note per task, that is thrown away once complete. This is for things like, "Make an ticket for issue X if still happening tomorrow", "Check Jim received email when they are back next week".