Keeping a Dev Log 101

Today, I’m going to teach you a practice that will make you a better engineer: keeping a dev log.

Do you want to internalize your learnings forever? Do you want to discover unconscious patterns that you’d like to eliminate? Hell, do you want to have an easier time writing your self review every year?

Unfortunately, most people who start a daily dev log practice fizzle out after a few weeks at most.

Because it’s not about what you write. It’s about what you do with it.

By writing down your thoughts, you clarify your thinking.

By summarizing your writings, you build longer-term awareness.

By analyzing your summaries, you discover your unconscious patterns.

Does this sound like a heavy lift? Honestly, the hardest parts are getting started and continuing to show up. The rest of it is actually rather mechanical.

Here’s how, step by step:

Step 1: Find a comfortable editor that supports Markdown.

Let’s be clear: If you’re opinionated about your editor, do not change. You should use the sword you’ve trained with. But if you don’t have an opinion, choose a tool that’s both available on your work computer, and that at least handles Markdown syntax.

I’m currently using Dendron because it plugs directly into VSCode, which happens to be available. It facilitates a dev log practice very effectively. In addition, it provides more sophisticated PKM practices like:

WikiLinks

Backlinks

Graph Visualizations

Hierarchical Organization

Step 2: Keep a Daily Log of your engineering activities.

What should you write down? Whatever you instincts tell you might be useful later.

I keep track of PRs that I’ve submitted and PRs that I’ve approved. It helps me reconstruct a story of what I’ve done throughout the week.

When I journal an interaction with a person, I link to that person’s note. Over time I can see exactly who I’ve collaborated with, and what we worked on together.

Step 3: Summarize and distill your learnings for later access.

Every week, create a 2-3 paragraph summary of your daily notes. I make note of patterns I notice, incidents that occurred, and discoveries that were made. For example, one colleague appears to be a jack of all trades from the diversity of contexts we’ve collaborated in.

When I am tackling a new process (or one for which my memory has faded), I summarize the daily notes that I’ve taken into a topic note. Later, when I have to do this again, I can refer to this topic note. For example, building out a new application infrastructure in EKS.