Posts categorized as: atomic-essay
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.
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.
There are many things most people don’t know about working in Software Engineering. For example, did you know… We reinvent the foundational dogma of our entire industry every 7-10 years. I’ve seen three cycles! The equivalent of a graduate-level education with multiple software engineering specializations is freely accessible on the Internet, and most engineers don’t look at it. We have overwhelming volumes of data that tell us specific software engineering models work, and we do the opposite most of the time.
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.
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. 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.
In 2001, Lamont Adams of TechRepublic chiseled what would become ten commandments of Gerald M. Weinberg’s timeless wisdom: Egoless Programming. Today we’re going to learn its third commandment: No matter how much “karate” you know, someone else will always know more. First of all, this is a good thing. My friend Neal Ford has said that as soon as you are the smartest person in the room, it’s time to look for another room.
In 2001, Lamont Adams of TechRepublic chiseled what would become ten commandments of Gerald M. Weinberg’s timeless wisdom: Egoless Programming. Today we’re going to learn its second commandment: You are not your code. This is without a doubt one of the hardest lessons for any early-career engineer to learn. As humans, we take pride in our creations. Unfortunately, software is soft because it’s meant to be changed, rewritten, and very often discarded completely.