No, I don't do any meta stuff in the notebook, that would be silly. It's not a progress report, development plan or a Gantt chart. You don't show it to your peers or supervisors, you don't need to decieve anyone with it. The main purpose is self-accountability and keeping (loose) track of the things you need to approach. Micro-managing myself, so to say.
If I need to add a feature, I just come up with first obvious things that have to be done, and expand it as the problem works out or new circumstances arise. E.g. I had to add a protocol support (Modbus TCP & UDP) to the product, the list ended up like this (editorializing a bit):
- get green light from the manager
- read the spec for minimal conforming implementation
- implement conforming request parsing
- implement register read command
- add application-specific bit X to a register
- add application-specific bit Y to a register
- implement UDP recv/send loop
- test UDP part
- implement TCP listener
- test TCP part
- fix zombie issue with TCP handler
- test TCP part
- build of product with the new feature
- test the build
- test the build vs real PLC
Perhaps everyone has at least some ideas what you should do when you begin on chunk of work X, so you just write them down, no matter how trivial.
If I need to add a feature, I just come up with first obvious things that have to be done, and expand it as the problem works out or new circumstances arise. E.g. I had to add a protocol support (Modbus TCP & UDP) to the product, the list ended up like this (editorializing a bit):
Perhaps everyone has at least some ideas what you should do when you begin on chunk of work X, so you just write them down, no matter how trivial.