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.

I have been in the “enterprise software engineering” industry for 22 years.

During that time, I have briefly but technically become a cloud startup millionaire. I published the first book with “cloud-native” in the title (and yes, the goddamn hyphen is correct, I said what I said). In fact, I have invested so many hours into mastering my craft that I literally have to turn down invitations to speak at conferences on the regular, even in this post-COVID era.

But did you notice something?

None of those have anything to do with enterprise software engineering.

There are many things most people don’t know about working in Software Engineering. But the one thing most people don’t know?

Writing Code is the thing we do the least.

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.

Unfortunately, most people keep working until they’ve exhausted their energy supply and have no momentum left.

All I want to do right now is go to bed.

I’ve worked my ass off on some intense software architecture initiatives over the last two days. My teenagers had their first football games of the season on Friday night and Saturday morning, and at least one of them now has the flu. My sleep is off. And now I think I might be getting sick also.

I committed to publishing Monday through Friday this cohort, and I’ve already missed two days in a row.

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.

What are the key elements of the ideal developer experience?

I’ll start: 🧵👇🏼

I’m getting more interested in Stoicism.

I’ve started working through “The Tao of Seneca,” an e-book I apparently got for free from @tferriss, forgot about, and recently rediscovered.

Both are accomplished one bite at a time.

Today I’ll share my process for taking a big writing project and breaking it down into manageable chunks.

I gained THIRTY pounds eating and drinking my feelings during the 2020 COVID-19 lockdowns and the long hangover.

And I’ve had enough. Today I’m going to share how I’m retaking control of my health. And it’s something you can do too.

Today we’re going to solve Project Euler Problem 2 in Kotlin. If you’re missing background on Project Euler and why I’m working through its problem set, take a look at Project Euler #1.

Today I’d like to introduce you to one of my favorite sources of programming problems: Project Euler.

Project Euler is composed of a large set of problems (779 as of this writing) that will challenge both your mathematical and programming skills.

Today we’re going to look at how Kotlin allows you to easily filter and aggregate a data set using higher-order functions like map, filter, and reduce.

While Kotlin does have a reduce function, we’ll go ahead and use Kotlin’s average function since we’re taking an average in this example.)

Shipping 30 atomic essays in 30 days was so hard I’d do it again.

If you’ve followed my writing journey since January 8, 2022, you’ll remember that my primary goal for the last 30 days has been:

Can I actually complete the 30-day streak?

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.

Today I’ll share four framework options you have for organizing all of the topic notes that you’re creating in your dev log.

By now, you’ve started keeping dedicated topic notes on your projects and collaborators. Depending on the tool you’re using, these may be piling up in a single folder with no structure. The folder may have grown so large that you need a way to bring order to the chaos.

Today I’ll explain how to organize all of the topic notes that you’re creating in your dev log.

By now, you’ve started keeping dedicated topic notes on your projects and collaborators. Depending on the tool you’re using, these may be piling up in a single folder with no structure. Eventually, this lack of a system will make finding things or knowing how actionable something is difficult.

You should keep a digital note in your dev log for any person you interact with significantly.

I record every personal interaction I have in my daily notes. I also keep a dedicated digital note for each person, and I link to that note from my daily note.