Skip to content

Latest commit

 

History

History
23 lines (16 loc) · 2.51 KB

t1 Keep a personal work journal.md

File metadata and controls

23 lines (16 loc) · 2.51 KB

Technique #1: Keep a personal work journal

Keeping a work journal is a fundamental part of working in any team, but especially when the team is distributed across timezones. Noting your daily progress and tracking your challenges is a way to help yourself to have a record of the issues you come across and being able to share these with other team members. This way you can get the help you need or tell how you overcame the obstacles.

Types of entries

To be really effective, a journal must be much more than just a list of stuff you did. They are a way to get behind the scenes and share your insight and process with the rest of the team. Think about the things you did, or are currently doing. For each one, see if you can describe it in the following ways:

Activity, “Things I did”: A literal description of the thing you did.

In most cases "things you did" should relate to project requirements (e.g. a ticket or issue). If the requirements are not documented, write the docs - this becomes part of the activity.

Knowledge gained, “Things I Learned”: Something you learned during the activity.

Maybe it's not brand new knowledge, but you were reminded of something you learned in the past. Maybe you brushed up your knowledge with some googling / stackoverflowing. Maybe you were given some helpful advice from someone else. In any case, write about it here.

Blockers, impediments: things that might slow or stop future progress.

Whenever you talk about a blocker, also write about what you will do in the meantime. Unless you're completely 100% blocked, make sure you don't give that impression. Try to list potential blockers as well, like a "known unknown" or a grey-area which you're not certain about yet. Don't be shy to talk about blockers, even if you're still making gradual progress. If something is taking you significantly longer than you expected, this is a good place to bring it up. Try to identify the reasons why it's taking longer.

Reflection, retrospective: Notes arising from your experience of doing the work.

Think about future maintainers of the code, or other people doing similar activities in future. Are there things they'll need to keep in mind, or things that will make their job easier? If you were to implement this feature again in future, are there things you would do differently? Any known tradeoffs or pros/cons of the approach you took, especially if it has impact on other parts of the system.

go to exercise #1