Menu

Link roundup for March 1, 2023

Open Circuits is “a photographic exploration of the beautiful design inside everyday electronics. Its stunning cross-section photography unlocks a hidden world full of elegance, subtle complexity, and wonder.”

Good conversations have lots of doorknobs. This is a fascinating essay about the elements of good conversation and the difference between “takers” who keep things going, “givers” who tend to ask a lot of questions, and how the wrong match-up can cause a conversation to stall. Includes good advice backed up by tons of academic research. This is one to save and revisit often.

Why do modern pop songs have so many credited writers? Some of the examples are wild. “When these cases are settled in favor of the plaintiff, more songwriting credits are added after a song’s release. This is why the number of songwriters listed on Mark Ronson’s “Uptown Funk” has increased over the years. To avoid a Mark-Ronson-style-courtroom-induced headache, artists will sometimes preemptively credit writers of older songs even if the similarity between the older song and their composition is purely coincidental.”

A “Last of Us” Episode 7 musical mystery (light spoilers). I just want to say don’t worry The Last of Us fans, I’m thinking about the important things over here.

The choice is easy. Robin Sloan with a good reminder: “Anyone who adds one of those email newsletter pop-ups to a website demeans them selves and makes the world worse for everyone else.” Reminder that if you are an author using Substack you can turn off “Subscribe prompts on post pages” in Settings.

Quick Review Summary. Ok this seems like an actually good use of OpenAI. Instead of poring over hundreds of reviews of a hotel, copy the Tripadvisor URL of the hotel into this website and it will generate a summary of the general sentiment of the hotel.

Neurodiversity Design System. Great resource. “The NDS is a coherent set of standards and principles that combine neurodiversity and user experience design for Learning Management Systems. Design accessible learning interfaces supporting success and achievement for everyone.”

SoundPrint is an app to “discover quiet places and share them with others.” This looks really useful, especially if you’re a fellow tinnitus sufferer.

The 90s, having time, and always rushing to the next thing

I’m sure every generation writes lots of articles like Freddie deBoer’s It’s So Sad When Old People Romanticize Their Heydays, Also the 90s Were Objectively the Best Time to Be Alive. But hear me out. This is the impassioned, forceful, yet balanced Gen X take I wish I had the skill and wherewithal to write. It is a balm to the nostalgic soul in a way that somehow doesn’t feel like cringey old-person fanfic.

Here he is on the experience of visiting a record store:

When you were there you were Doing Music. Now we’re never doing anything—we’re always getting through something to get to something else to get through, using various time-saving techniques that maximize the amount of time we have to get through things while keeping our attention divided into a thousand things we then get through. When you went to a record store you were intent on music, and sometimes, you’d care enough about a particular artist that you paid for their album, real money, so that the artist got a cut that was more than the .002 cents they get per stream now.

This reminds me of the question Alan Jacobs asks: What exactly are we’re rushing towards with all our 2x listening and cliff notes skim-reading?

My question about all this is: And then? You rush through the writing, the researching, the watching, the listening, you’re done with it, you get it behind you—and what is in front of you? Well, death, for one thing. For the main thing. 

But in the more immediate future: you’re zipping through all these experiences in order to do what, exactly? Listen to another song at double-speed? Produce a bullet-point outline of another post that AI can finish for you?

Maybe the 90s have a thing or two to teach us yet.

Don’t give up on the value of product management because of bad past experiences

Maybe 10 years ago I would’ve gotten upset about an article like Spencer Fry’s No PM, no problem: how we ship great products fast, in which he explains why they don’t have product managers at Podia and how great that is. Luckily I’m now too old to stay up late just because I think someone’s wrong on the internet. Instead, I approach articles like these—ones I viscerally disagree with right off the bat—with a bit more curiosity. What is the source of the author’s assumptions? What is the data that led them to this particular set of conclusions? What is the problem they’re trying to solve, and what led them to this viewpoint as the solution?

As it turns out, we get the answers to those questions pretty early on in Fry’s post:

Why shouldn’t the developers—or designers—be tasked to work through the problems, instead of being handed a set of solutions?

Every single project, a developer is assigned what we call a Champion role and it’s that person’s responsibility to act as the PM in addition to their work as an individual contributor. This approach, as opposed to handing off a spec to stitch together with code, makes for much more engaged developers who feel more ownership of the work.

Ah, see, this makes sense! I can see why Fry concluded that PMs are unnecessary if his experience is that they (1) “hand off a spec to stitch together with code”, and (2) don’t give developers ownership over their work. The problem is likely that he has never worked with a PM that understands their role and does it well, so of course the data would lead to the conclusion “no PM, no problem”.

So let’s talk about those two assumptions for a minute.

(more…)

The Myth of Velocity

Randy Silver in The Myth of Velocity:

When we measure how quickly teams ship stories & code, we’re measuring speed—how quickly they move. It’s only when we measure the effect it has on the target metric—the value that we’re after—that we’re actually looking at velocity.

It doesn’t matter how much you ship if the end result doesn’t deliver value to your customers and your company. If you’re measuring story points, you’ve fallen into the trap of measuring outputs, not outcomes. When we talk about slowing down to speed up, this is the point: the only thing that matters in this equation is how quickly we can deliver actual value. Everything else is theater.

You can’t stand under my umbrella

In You can’t stand under my umbrella the Raw Signal team makes the case for when it’s not appropriate for managers to be “sh*t umbrellas” for their teams:

When things are steady, and people know the right things to work on, teams are constrained by velocity. We know the course we’re racing, the question is just how fast we can go. In that context, it makes sense for a manager to clear every obstacle out of our way. But during times of significant change, teams are constrained by agility. It’s not that velocity doesn’t matter, it still does. But when everything has changed about the race, we need the ability to steer. A manager who tries to preserve velocity at all costs risks running us into a wall.

They go on to talk about how to Accept, Adapt, and Act in such moments of significant change.

Technical debt, product debt, and how to prioritize addressing it

Mike Fisher argues that we should rebrand technical debt as “product debt”, and I think it’s a good argument! That said, I’d like to add some considerations to two of his points. First:

We usually think of refactoring as “cleaning up” code, where we change the code to be more easily understood, perform better (faster or more efficiently), or follow current conventions/standards. The goal of refactoring is to change the code without changing its functionality; it should continue to pass all unit and functional tests. 

I take a slightly different approach to refactoring, and how to prioritize the work. I believe it’s important for teams to have a stated and agreed-upon value of “leave the code better than I found it.” This means that refactoring shouldn’t be a separate activity, for its own sake, that needs to be scheduled. It should be a natural part of feature development.

If you’re creating a mechanism for add-ons on the product, spend a few extra days to refactor the billing code you’re already working on. If you are adding metrics to the dashboard in your UI, take the time needed to refactor the front-end code to make it more performant. Whatever code you’re touching while you’re working on a project, leave it better than you found it. It is way more efficient to extend a project by a week to refactor code you’re already working on than it is to create a separate project that needs to be planned, prioritized, and worked into the roadmap.

Second point:

So, how do we ensure we are paying down technical debt when there is so much pressure to ignore it until things really break? I think one part of the answer is to use a different term. Instead of tech debt, which implies it is the responsibility of the tech team, let’s call it product debt.

I think this is a good first step to getting more teams to care about technical debt—but it’s not enough. One of the issues with getting technical/product debt prioritized is that often “the business” doesn’t see the value in statements like “we’re going to clean up the code so that it doesn’t break a few months from now”. Instead, we need to frame the work in terms of the benefits to customers and/or the business.

For instance, we could make the case that refactoring this piece of code would significantly increase our deployment speed, which would mean faster time to market. Or we could argue that fixing our slow staging environments would result in happier, more productive engineering teams.

With technical debt—as with most things in software development—the thing you do is never the main thing. The main thing is what the thing you do enables. What value it brings to customers and the business. That’s the framing we need for working on technical debt.

The Cynical PM Framework, a business-first approach to product

Frank Tisellano in The Cynical PM Framework, a business-first approach to product:

Every product, every feature even, serves a function in your business. It has one of three jobs:

  • Acquire new users or customers
  • Retain those users or customers
  • Expand engagement or revenue per user or customer

Link roundup for February 19, 2023

Underwater Photographer of the Year—2023 Winners. These are so great.

Impostered. Great post from Mandy Brown about the need to reframe how we think about imposter syndrome. “I’ve started to think less about imposter syndrome (a description of a person’s experience with it) and more about being impostered (a framing that draws attention to the systems and structures that lead people to believe they are imposters). While the former framing remains useful in many contexts, the latter creates space to consider not only the symptoms but the root cause of the phenomena.” [everythingchanges.us]

What’s So Funny? Very good essay about the current state of stand-up comedy, and what makes something funny. “The audience whooping and applauding Roseanne’s ‘anti-woke’ comedy is not reacting with laughter at a previously un-acknowledged truth, but instead expressing approval for the point of view that they already knew they agreed with. This is not the same thing as laughter in response to a joke.” [biblioracle.substack.com]

Why Are You Seeing So Many Bad Digital Ads Now? “Social media advertising, once a niche art practiced by specialist agencies, is now easily available to anyone. Many of them are eschewing targeted ads — placements intended to reach specific audiences, usually at a higher cost — in favor of a cheaper spray-and-pray approach online, hoping to catch the attention of gullible or bored shoppers.” [NYT gift link]

Traffic Lights Need a Fourth Color, Study Says: Here’s Why. Yeah what could possibly go wrong. “For the dawning age of the self-driving car, transportation engineers from North Carolina State University are proposing the addition of a fourth ‘white light’ whose function would be to alert humans to simply ‘follow the car in front of them.’” [popularmechanics.com]

The people who live inside airplanes. Ok I kind of like this idea. “By the end, she had a fully functional home, with over 1,500 square feet of living space, three bedrooms, two bathrooms and even a hot tub — where the cockpit used to be. All for less than $30,000, or about $60,000 in today’s money.” [cnn.com]

More

  1. 1
  2. ...
  3. 27
  4. 28
  5. 29
  6. 30
  7. 31
  8. ...
  9. 202