Today, there is an app, website, or software platform for almost anything (including an app that does absolutely nothing).
But when it comes to being a polymath who’s learning, thinking, and creating all day, there is one app I can’t live without:
Logseq And here’s why:
I never have to leave my Daily Journal Logseq opens to a new journal page daily, and it always structures this page as an outline.
Today I’m going to tell you how to use a creative strategy called the Hemingway Bridge.
I learned this strategy from reading Tiago Forte’s book Building a Second Brain, and I immediately started applying it to my daily work as a software engineer and architect. It has been life-changing! If you learn and use it, you’ll start every day with a burst of momentum because you sent it to your future self as a gift.
I wouldn’t call myself an expert in Personal Knowledge Management (PKM).
However, I have honestly spent countless hours reading and learning about PKM. And I have been practicing various forms of PKM in my life for the better of 15 years.
So many things have changed during those 15 years:
The things we choose to label as PKM The techniques we use to practice PKM The technologies we use to implement PKM But one thing hasn’t changed, and I learned it early in my journey.
I love learning about Personal Knowledge Management (PKM)!
I first got interested in this topic at least 15 years ago (it wasn’t known as PKM then). It was overwhelming trying to figure out where to start at the time, and it’s only gotten worse.
Last year, I discovered Tiago Forte’s online cohort-based course, Building a Second Brain. Rarely will I reach for the word “life-changing,” but the value of having so much curated knowledge experienced within a community has earned that label over the past year.
Laboratory science has much in common with software engineering:
We take a new language or technology and experiment with it to see what it can do and how it performs. When we practice Test-Driven Development, every failing test that we write encodes a hypothesis: that the test actually will fail! We gather and study data obtained from our system and its surrounding environment as we troubleshoot incidents. We hypothesize causes, and we try to reproduce results.
Today we’ll walk through the next summarization level we need in our dev logs: monthly reviews.
We’re slowly climbing a mountain:
Daily logs tell us the quantum details of what we did on a specific day. Weekly reviews roll those details up into atomic accomplishments for the week. Monthly reviews compose those accomplishments into molecular deliveries. Pardon the poor quantum physics analogy, but I think it’s apropos. We are building what Tiago Forte calls “intermediate packets.
Today I’m going to teach you how to begin your journey to harvesting insights from your dev log.
You should expect a healthy ROI from the time you spend capturing your daily activities. Simply writing down everything you do each day isn’t enough. Reviewing and summarizing the week is like conducting a mini-retrospective with yourself.
Unfortunately, most people never conduct a single weekly review.
Because they don’t know how. Not only that, but:
To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily.
I’ve been engineering software for 21 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily.
Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page!