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.1

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.2

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

Best remote work equipment in 2020

If you’re working on a fully distributed team, partially remote team, or even just working from home occasionally, this is a selection of low-cost equipment you can use to get your home office setup to a “professional” level.

All of this equipment has been tested extensively to work on:

  • Google Hangouts
  • Google Meet
  • Zoom Video Conferencing
  • Microsoft Teams
  • Skype
  • Slack
  • FaceTime (on OSX)
  • Alternative video tools, like WhereBy, Loom, or Jitsi Meet

And, all of this equipment has further been tested on every operating system:

  • Mac OS X (including Catalina)
  • Linux (including Ubuntu 18.04 and beyond)
  • Windows 10

All of the recommendations here also work without special drivers or software.

The main reason for the compatibility is the use of standard USB 2.0 interfaces, which are really the best way to go for the equipment to work well.

The best remote work webcam: Logitech C925e

You should always prefer an external webcam & mic combo to your built-in webcam and mic on your laptop or desktop machine.

The Logitech C920+ models are extremely good and reliable on every operating system.

I recommend the Logitech C925e. This model has a great built-in stereo mic and 720p / 1080p video. It also supports hardware acceleration (aka h.264 encoding) on many platforms and with many video conference tools, which reduces the load on your computer’s CPU (and keeps your computer running cooler and using less battery). This particular model also features a simple built-in privacy shutter, excellent monitor mount, and a long USB cable.

logitech-c925e

If you can’t find the C925e, your best alternative is the Logitech C920. This is the consumer version of the same hardware — the webcam looks a little different but is also a 720p / 1080p HD cam with built-in mics. It doesn’t have the privacy shutter, however.

Continue reading Best remote work equipment in 2020

Chat with me for 30 minutes about distributed team management

Have you been trying to figure out this new world order with regard to work-from-home (WFH), remote work, distributed teams, and the like? I’ve opened up my calendar for 30-minute chats. You can schedule them with me here:

https://calendly.com/amontalenti/distributedUpdate: after over a year, I’ve now shut down this link on May 27, 2021

If you want to read up on distributed teams, here are some past posts from my blog and the Parse.ly blog on the subject. Open up these links and skim to get a sense of my past writings.

Continue reading Chat with me for 30 minutes about distributed team management

Work is a Queue of Queues

Do you ever get that feeling like no matter how hard you work, you just can’t keep up?

This isn’t a problem uniquely faced by modern knowledge workers. It’s also a characteristic of certain software systems. This state — of being perpetually behind on intended work-in-progress — can fall naturally out of the data structures used to design a software system. Perhaps by learning something about these data structures, we can learn something about the nature of work itself.

Let’s start with the basics. In computer science, one of the most essential data structures is the stack. Here’s the definition from Wikipedia:

… a stack is a data type that serves as a collection of elements, with two principal operations: (1) “push”, which adds an element to the collection; and (2) “pop”, which removes the most recently added element that was not yet removed. The order in which elements come off [is known as] LIFO, [or last in, first out]. Additionally, a “peek” operation may give access to the top without modifying the stack.

From here on out, we’ll use the computer science (mathematical) function call notation, f(), whenever we reference one of the operations supported by a given data structure. So, for example, to refer to the “push” operation described above, we’ll notate it as push().

I remember learning the definition of a stack in college and being a little surprised at “LIFO” behavior. That is, if you push() three items onto a stack — 1, 2, and 3 — when you pop() the stack, you’ll get the last item you added — in this case, 3. This means the last item, 3, is the first one pop()‘ed off the stack. Put another way, the first item you put on the stack, 1, only gets processed once you pop() all the other items — 3, 2 — off the stack, and then pop() once more to (finally) remove item 1.

Practically speaking, this seems like a “frenetic” or “unfair” way to do work — you’re basically saying that the last item always gets first service, and so, if items are push()’ed onto the stack faster than they are pop()’ed, some items will never be serviced (like poor item 1, above).

Continue reading Work is a Queue of Queues

Office extinction for knowledge workers and the rise of fully distributed teams

Esko Kilpi wrote:

For most of the developed world, firms, as much as markets, make up the dominant economic pattern. The Internet is nothing less than an extinction-level event for the traditional firm. The Internet, together with technological intelligence, makes it possible to create totally new forms of economic entities… Also very small firms can do things that in the past required very large organizations.

This is true. But for certain small firms that are run as fully distributed teams (as mine, Parse.ly, is) the Internet is an extinction-level event for the physical manifestation of the firm — the office.

Already, companies such as GitHub and Automattic have minimized the importance of co-location in work collaboration. Successful massive creative projects are delivered not just by distributed teams, but also by volunteer teams. For example: the Linux kernel and Wikipedia. I wrote about this in my essay, “Fully Distributed Teams: Are They Viable?”

Continue reading Office extinction for knowledge workers and the rise of fully distributed teams

Going mobile in 1998

My first mobile device was a Palm V. I understood the power of mobile really early. I was 15 in 1999, when the Palm V was released. I first came across the Palm devices in 1998, when the Palm III came onto the scene. I never owned one, but played with the one my Dad owned, but barely used.

This device was comically under-powered in retrospect. It had 2 megabytes of RAM, which had to be used as not only the working memory of the device, but also the storage. It had a 16 Hz processor, a 4-greyscale screen, and a stylus-driven interface.

The Palm V was an amazing device. In lieu of the plastic of the Palm III, it had a finished anodized aluminum finish, very similar to the kinds of sleek devices we would only begin to regularly see in the last couple of years. It was nearly half the weight of its predecessor, and as thin as the stylus you used to control it. It had a surprisingly well-designed docking station (imagine this: since USB hadn’t yet been developed, it had to sync over the low-bandwidth Serial Port available on PCs at the time).

Continue reading Going mobile in 1998

Questioning the Canon

I was in the best of settings when I realized that Shakespeare was indeed great. My freshman year in high school, I had English class with an esteemed teacher, Mr. Broza—hailed as the Paul D. Schreiber High School Shakespeare aficionado, founder of Schreiber’s Annual Shakespeare Day, and, perhaps most heart-warming of all, a self-proclaimed Shakespeare lover whose posters of The Bard could be found as wallpaper in his small office. How lucky I thought I was. Indeed, if I wanted to appreciate Hamlet, I was in the right hands.

But how misled I actually was—at least, in Walker Percy’s eyes. In his essay, “The Loss of the Creature,” Percy recalls a scene from The Heart Is a Lonely Hunter:

…the girl hides in the bushes to hear the Capehart in the big house play Beethoven. Perhaps she was the lucky one after all. Think of the unhappy souls inside, who see the record, worry about the scratches, and most of all worry about whether they are getting it, whether they are bona fide music lovers. What is the best way to hear Beethoven: sitting in a proper silence around the Capehart or eavesdropping from an azalea bush?

Percy here contrasts two different approaches to viewing art—the girl who informally and spontaneously encounters the work of art, out of context, as opposed to the “unhappy souls inside” who formally prepare themselves for a kind of pre-packaged listening experience. Percy wonders which is better—a question meant for the reader’s pondering. But his essay offers his answer: we can only truly see or hear a piece of art by “the decay of those facilities which were designed to help the sightseer”. Perhaps Percy is right—it might have been better if my experience with Hamlet had been an accidental discovery rather than a guided tour, an “eavesdropping from an azalea bush” rather than “proper silence around the Capehart.” Perhaps I should have encountered the text unaware of its origin but intrigued by its mystery. After sitting by a tree and reading the text front-to-back, perhaps then I would be able to “see” Shakespeare in Percy’s sense of the word.

Continue reading Questioning the Canon