Life gets crazy, and things slip our minds. A great discovery, a bug, or a general direction we were taking our code can get lost between development sessions.
In my personal projects, where time between development sessions can be days or weeks, I have been keeping a development journal. As much as it takes an additional couple minutes, it allows me to express intent and task my future self with necessary work.
How does a Development Journal work?
You can tackle this in many ways, but the formula I follow is this:
- Title
- Date and time (started, ended or both)
- 1 – 2 paragraph overview
- What was I doing?
- Where was I planning on going next?
- Wins or trouble areas in the work today?
- Duration spent working – Because you can get distracted!
- Mood – How was I feeling the whole way through?
- Pitfalls – Did anything slow me down or cause unexpected problems?
- Windfalls – What went exceptionally well? Did something get done faster or better than anticipated?
- Tasks – What needs to be finished? What is going to be started next?
What does a journal entry look like?
Generally speaking this would be used for ongoing projects, but here is an example of one for this blog post:
Dev Journal Blog Post
Thursday October 2, 2014 – 8:02AM to 9:16AM EST
I chose to do the dev journal blog post because I love self-improvement and enjoy sharing my self-improvement tips. Although my pattern is a bit different, the idea of development journals is nothing new; I thought that more light on the topic would help others see how beneficial it can be.
- Duration: 1 Hour – did some project work in the middle.
- Mood: Tired but excited to share.
- Pitfalls: Still improving my pattern, so I spent time contemplating certain areas of the work.
- Windfalls: Much of my pattern is straight forward and fun to do! Working on the sample was awesome.
- Tasks: Sync with Tabitha and Lisa to improve the post as a whole.
Usually this process takes me about 10 minutes or less to do, so it add little overhead to any project. Using it more often and improving upon the metrics you track could help give insight into your projects that succeed, fail, and end up anywhere in between. The metrics I track help me look back later at the code and the git logs to see if there were any pain points or keep notes on articles and insights that helped me solve problems. Even though this seems odd at first, and potentially pointless, it will allow for you to keep track of time spent and upcoming tasks!
If you have any tips for tracking time or stats in a better method, one that would allow for more data manipulation, let me know in the comments below.