Personal

Hypernormalization and distrust

I’m fortunate that I got a high school education in a US public school system built during a period of post-WW2 abundance — when we invested in the future.

I feel doubly fortunate that I attended NYU when a college education was seen as a universal good.

I remember that post-9/11 politics in the US was dark. If you think about it, 2001 was 9/11 and 2008-2009 was the Great Financial Crisis. With the Iraq War in between (and after). That was a dark period for the US.

And yet, when I look back at that time, I was at my most idealistic.

One way I could remain idealistic is that the US, for all its problems, maintained two great principles:

individual freedom — the right to make one’s own decisions
free speech — the right to speak freely, especially to dissent

Both of these are supercharged by education.

The way I see it, these rights are fundamental. Whether you’re a politician, a government agency head, a corporate executive, a wealthy bigwig, or just any old fellow citizen, if you try to suppress my individual freedom and my free speech, you are out of line.

And I feel strongly about the converse, as well. Which is that the best of our politicians, our government agency heads, our corporate executives, they try to encourage individual freedom and encourage free speech.

That means encouraging those around you to speak out their mind.

This does lead to one tension that has to be resolved. How to handle the people who use their individual freedom and free speech rights to try to suppress the individual freedom and free speech rights of others? The answer, here, is pretty clear, to me. That’s out of line, too.

Illustration by Glenn Harvey of The Guardian, as part of a series of illustrations in this article.

Hypernormalization is a term that refers to a strange feeling that every institution is failing, yet life goes on. This is how I felt after 9/11 and the Great Financial Crisis. It’s also how I feel now. Idealism was needed then. And it’s needed now.

Continue reading Hypernormalization and distrust

My tricks and accessories for working ergonomically on a laptop while on the go

In my last post, I discussed how I upgraded to a Lenovo X1 Carbon Gen 11 laptop (rtings.com review) as my primary Linux workstation. For years, I’ve worked from my Linux laptop (usually a Lenovo X1 carbon) on the go.

I’ve been spending more time recently working on the go, outside of my office, for various reasons. That made me realize: I never did a post about how I make sure I keep some good ergonomics even when working from cafes, hotels, libraries, outdoor parks, and so on. Well, this post will remedy that!

Making a laptop feel nice on the lap

It’s in the name! Laptops are meant to be used from your lap. At least, in theory. But, laps create all sorts of issues for laptops:

Heat. Even if your laptop stays cool, small amounts of heat from the machine will be lost to your upper thighs. It’s just uncomfortable.
Stability. A laptop is meant to be totally stable while you type, but your lap isn’t a totally even surface.
Ergonomics. The ideal height and distance of your arms/hands/wrists to the keyboard should be a little further away from you than your immediate lap. But the farther away your laptop is, the less stable it feels.

Luckily, all of these issues can be solved relatively easily, but in a counter-intuitive way. Here is the solution:

What is that? It’s a Moleskin Art Sketchbook, Hard Cover, Style: Book, Size: A4 (8.25″ x 11.75″), 96 Pages. (Amazon link) This is a lovely notepad — really, a sketchbook meant to be used by artists. But it has a hard cover which is the size of an A4 sheet of paper (slightly larger than letter size paper). It’s also pretty much exactly the size of a 14-15″ laptop. You rest your laptop on this, and it allows you to place your laptop on your lap and instantly fixes heat, stability, and ergonomics issues.

What you’ll also notice is that by raising the laptop a little and having a stable surface underneath it, you feel more comfortable balancing your laptop farther from your body (e.g. approaching your knees), which makes typing on your laptop even more ergonomic.

What’s more, it’s easy to slip this sketchbook in your backpack right next to your laptop to provide extra protection when traveling with it. And, you can still use it as a pen-and-paper notepad! I also love that its large-format sheets which are unlined, and thus are perfect for diagrams or interface sketches that you can then take a photo to scan digitally.

I’ve used this trick for so many years, but never see anyone else doing it, so I figured I’d share.

Continue reading My tricks and accessories for working ergonomically on a laptop while on the go

Linux is free and your mind is valuable

One of my favorite old Linux jokes is, “Linux is free… if your time is worthless.” This quote is possibly adapted from a jwz interview dating back to 1998. In it, he said:

I think Linux is a great thing, because Linux is an alternative to [major operating systems], and because, of all the operating systems that are at all relevant today, Unix is the best of a bad lot. […] As we all know, Linux is only free if your time has no value, and I find that my time is better spent doing things other than the endless moving-target-upgrade dance.

That said, I’ve run Linux dating back to my earliest days studying formal operating systems, when I did it mainly so that I’d have access to vim, shells, a solid gcc toolchain, and good x86 hardware emulation and virtualization tools. Somewhere along the way, though, I made it a point to make my day-to-day computing, if not completely imbued by the open source movement, at least “keyhole accessible” to its thriving core, which continues to be Linux. So, for me, as a point of pride, it has been Linux on the desktop, Linux on my smartphones (that is, Android Linux), and Linux on my smart TVs (that is, webOS). As well as Linux in the obvious places, like my cloud VMs, my Raspberry Pi, my physical server, etc.

I’m not a purist, though. I still use plenty of proprietary software in my life. And plenty of proprietary hardware, too. To stay connected to the world of Apple, I keep an iPad running iPadOS and a Mac Mini running macOS. To stay connected to the world of Microsoft, I keep a dual-boot’able partition for Windows 11 Pro. But I’d say 90% of my computing happens on some Linux variant, and that makes me feel good about having a more direct relationship with computing, where I can always peel back some layers of the onion as needed.

My latest was to shift from a very-very old laptop (my trusty Lenovo X1 Carbon Gen 8) to a not-quite-so-old laptop (a Lenovo X1 Carbon Gen 11). I’ve been sticking with Lenovo as my Linux laptop for awhile now, covered in past posts like “Speed & lightness” and “Lenovo and the new Linux desktop experience”.

Linux is free to run on your laptop

By doing a little research beforehand, I got a model off the Lenovo outlet store with a screen, webcam, and Intel architecture that is well-supported by Linux (summary: avoid MIPI webcam and avoid mobile WWAN). Specifically, it runs perfect with Ubuntu 24.04 LTS out-of-the-box. The only “tweak” I had to make was a workaround for thermald which was erroneously refusing to start on my CPU architecture — the fix was a rather easy systemd invocation and is described here.

In typical Linux “rabbit hole” style, learning a little bit about thermald (with the help of the source code reading and summarizing features of ChatGPT4 projects, incidentally) made me better understand how my laptop approaches battery and cooling performance.

Another change that is more from the world of security is learning about SecureBoot + TPM, two semi-controversial changes to the laptop hardware landscape that Linux didn’t support well until somewhat recently. More on this available in this Twitter/X thread. So, yet again, in fortuitous Linux rabbit hole style, I learned something about modern “security” hardware I wasn’t paying close attention to beforehand.

Continue reading Linux is free and your mind is valuable

My relationship with digital media in the last few years

I have a long relationship with digital media. I’ve been blogging for decades. I’ve been a news junkie forever. And I started a startup in the real-time and historical content analytics space (Parse.ly) that ended up shipping a widely-used product in the industry.

What’s more, Parse.ly’s network-wide data (billions of online news reading sessions every month) was used to understand the media industry, via various (aggregated and anonymized) data compilations and reports in partnership with organizations like Axios and Pew Research. This was one of my favorite studies we did a few years back, on the shape of different page visit lengths, using engaged time (PDF).

Summary of the “engaged time” spent on single news articles across 1.6 billion news reading sessions from the Jan. 2017 – Jun. 2017 period in the Parse.ly network.

Aspirationally, I’d like for my media habits to move toward that top 1% of engaged sessions on the regular — that is, 7 minutes or more of reading time per article, as shown on the right-hand side of the graph. Intentional, slow, deep reading. And I’d also like to avoid having a big portion of my day whittled away by the kinds of quick-hit information conveyances that put one on the left-hand side of that graph.

Continue reading My relationship with digital media in the last few years

The Partially Examined Life: a podcast, a new book, an antidote to doomscrolling

“The unexamined life is not worth living.”

This famous quote comes from the history of philosophy, supposedly said by Socrates, as recounted by Plato, in his “Apology.”

Over the years, however, this quote has also become a kind of aphorism, suggesting that philosophy — that is, discussions around the ideas of historical and modern philosophers — is not just for university academics and their students, but even for we mere mortals, living down here in the common plane of everyday existence.

This quote also serves as the title of episode 1 of The Partially Examined Life Podcast, where the three founding hosts — Mark, Seth, and Wes — discuss Plato’s Apology and the trial of Socrates at length, in their wonderfully informal and inaugural podcast discussion. And a well-edited partial transcript of this first episode also serves as the first chapter of their forthcoming book, “The Partially Examined Life: 15 Years with Your Favorite Philosophy Podcasters.”

The book is planned for publication by the end of April 2024, and I was able to get my hands on an advance copy. Read on for my thoughts.
Continue reading The Partially Examined Life: a podcast, a new book, an antidote to doomscrolling

The smartphone app audit

I recently upgraded from a Google Pixel 7 to a Pixel 8 phone. Nothing earth shattering about this upgrade. Incremental. “Performance smartphones,” as the DOJ recently called iPhones and high end Androids, have leveled off in core functionality.

The Pixel 8 is slightly smaller than the Pixel 7, which makes me happy, as I treat my phone as a utility device, not a content or gaming device. It has small upgrades in battery life, screen, and connectivity. The most interesting upgrade is a USB-C desktop display mode for external monitors, which I’m excited to try out for Google Photos, for reviewing hi-res photos on a bigger screen.

When I am working at a laptop-docked ergonomic desktop computer setup during the day, I like the idea of my phone being like a second desktop (with an actual monitor, keyboard, and mouse!) rather than this buzzing distraction in my pocket. This is all a part of my long desire to resurrect the read-write creative abilities on what were, for many years, read-only passive consumption devices.

The biggest change for me during this smartphone upgrade, though, was that I decided to do a smartphone app audit at the same time.

That is, I wanted to figure out, what apps do I have installed, and why?

And, in particular, can I remove the apps from my life that are time wasters and pure distractions?

Continue reading The smartphone app audit

The Blog Chill

The film The Big Chill came out a bit before I was born, over 40 years ago, in 1983. The plot focuses on a group of middle-aged friends, perhaps in their late 30s and early 40s, who had attended the University of Michigan – Ann Arbor together. They reunite after 15 years, brought together by the tragedy and the funeral of their friend, Alex, who, we learn in the film’s opening, died by suicide.

The “big chill” of the title can be interpreted a few different ways. The numbing loss of the innocence of youth. The cold realization of the quotidian nature of adulthood. Or, the wintry blast of mortality, which comes as a shock to this group of old college friends, who had become used to a sort of humdrum comfortable existence, pursuing families and careers, and then being suddenly shaken out of it by the sad news of their old friend Alex’s passing.

There is a historical and generational aspect to the film, too. The college years, for this group, were the 1960s. A time of great idealism in the US. The counter-culture was the culture. They weren’t supposed to end up like their parents. But then they found themselves in the 1980s, yuppies of exactly the sort they feared they’d become.

One of the interesting aspects of watching this film today is that, being set in the 1980s, it lacks altogether the technopoly we see in our current lives in the 2020s. There are no smartphones nor social media, to be sure, but, what’s more, there is no computing or internet either.

Continue reading The Blog Chill

Dependency rejection

Sam Altman once said: “Minimize your own cognitive load from distracting things that don’t really matter. It’s hard to overstate how important this is, and how bad most are at it. Get rid of distractions in your life. Develop very strong ways to avoid letting crap pile up.”

In programming, there is a technique called “dependency injection.” It’s a way of worrying, up front, about how to split the modules in your program from other code. You aim to give yourself the future benefit of being able to swap out a module dependency later.

In some communities, this little technique led to a temporary fad of constructing programs within a baroque superstructure via “dependency injection frameworks,” sometimes called “inversion of control frameworks.” With these, programmers fretted about a future that usually never arrived, and their worries expressed themselves as defensive code, all in the name of future-proofing. This meant in addition to spending time adopting a dependency, they also had a meta-distraction: working that dependency into their “management framework,” alongside the others. This sort of thing took some programmers very far away from the core “essential complexity” at the heart of their code.¹

Dependencies seem to be all around us, both in the real world, and in programming. And they are perniciously distracting in just this way. Have you ever noticed how rare it is for you to just do something?

If so, you might have been worrying, up front, about dependencies.²

In the back of your mind, you wonder: has this been solved? The world is full of solutions in search of problems, and the internet is always nearby. You convince yourself to research if some of these happen to apply to your problem.

Even if you don’t find something off-the-shelf, you still might think to yourself: I could just do this, but is this a good use of my time? Lacking a ready-made solution, you then turn to delegation: whom shall I ask to solve this? After all, the market usually obliges with eager participants willing to sell their labor for a price.

But whether your proposed solution is an object or a person (and whether it is free or paid), there’s one thing it always is: a dependency.

Continue reading Dependency rejection

Turning n/2 + 1

When I turned 27, I wrote the following in my birthday post:

I don’t need stuff. I just need time. Of course, that’s the bittersweet part of one’s birthday. That even as you come to realize the importance of time, the day acts as a reminder of how our time on this earth is limited. 1 day passes, and only n-1 left to make a difference.

The average life expectancy for a US male born in 1984 is 75. I just turned 38 today. Therefore, it’s fair to say, I just turned n/2 + 1.

That is perhaps a bit too fatalistic and reductive. The number n is not guaranteed to be 75. “Don’t be so morbid!” someone might exclaim to me. “After all, many people live to 80, 90, even 100. And medicine improves all the time.”

Well, yes, this is true. But, it’s also likely — and increasingly so — that I might die any minute. Freak accidents, a late-discovered birth defect. Or, just losing the medical lottery in middle age. So, I return to the wisdom of my youth: “I don’t need stuff. I just need time.”

But, toward what end? That has been the interesting riddle of approaching n/2 with the following undeniable privileges:

good health
professional satisfaction
financial security
confidence in my irreversible life choices

Many approach this same milestone with none of the above, and many would love for any one of them to be squared away.

The honest truth is, I find myself heavy with the weight of these privileges. History is, as Harold Bloom once put it when describing literature, “a conflict between past genius and present aspiration, in which the prize is […] survival.” Here, he was referring to well-crafted stories. “Survival” meant their perpetuation through the ages via timeless literary relevance, something he referred to as “canonical inclusion”.

But what of my field, software?

Continue reading Turning n/2 + 1

Managing software teams: the definitive reading list

Frederick Brooks once wrote:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination.

In his classic essay, “No Silver Bullet”, he also wrote about software’s “essential” complexity:

The complexity of software is an essential property […] Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties by experiment. This paradigm worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence.

It’s therefore no surprise that once a team develops expertise in a technical domain and starts to evolve a product from that foundation, there is still a huge heap of complexity left over.

This is made worse on bigger problems where more people are involved, thanks to Brooks’s Law. In addition to the software’s essential complexity, you also need to navigate the built-in complexity of human communication, and the associated combinatorial explosion of information pathways on growing teams.

Modern software management practices have thus evolved two distinct skillsets for navigating the problems of team coordination around complex software delivery. These two areas are product management and software engineering management.

Product management centers around areas like market positioning, product strategy, and customer-focused iterative development. The product manager, working closely with the engineers, determines the “what”, aligns the team around the “why”, and acts as a liaison to users and the wider market.

Software engineering management focuses on the practice of coordinating teams of programmers in the delivery of high-quality shipped software, often leveraging programming languages, tools, frameworks, cloud services, and lots of open source technology. Pithily, this is “the how”, as well as the art of making informed engineering tradeoffs, e.g. as relates to time-to-market, performance, quality, and cost.

This post will cover some of my favorite reading materials spanning product management and software engineering management, as disciplines. A preview of some of the titles is here:

I have curated these resources carefully, and I have recommended them at various times to my own product managers and my own software engineering managers over the years. I hope you find this a useful starting point for your own study.

Continue reading Managing software teams: the definitive reading list