Every few days I post some links to things I enjoyed that don’t neatly fit into the topics I usually cover on this blog. Use it to fill your reading queue with interesting stuff!

• The Astronomy Photographer of the Year 2022 Winners are out.
• Did the Music Business Just Kill the Vinyl Revival? “On an aggregate level, consumers are simply not buying music. They prefer to stream it for pennies rather than purchase it for dollars.”
• How Do Big Tech Giants Make Their Billions? I know infographics are so 2000s, but this comparison data is super interesting.
• This week’s useful app → Readow provides book recommendations powered by AI.
• This week’s WTF Link → The lights have been on at a Massachusetts school for over a year because no one can turn them off. “The lighting system was installed at Minnechaug Regional High School when it was built over a decade ago and was intended to save money and energy. But ever since the software that runs it failed on Aug. 24, 2021, the lights in the Springfield suburbs school have been on continuously, costing taxpayers a small fortune.”
• This week’s Gen X link → Remembering horse_ebooks in the age of GPT3. “it’s this fear of the uncanny which i think drove the negative response to the discovery that horse_ebooks was actually no longer a bot at all. more than the disgust at feeling like you’d been played in service of a viral marketing campaign, the deeper sense that a future is coming where it won’t be possible to reliably tell the difference between bot activity and human activity lay underneath that negative reaction. and ten years later - that future is here.”

This is an interesting interview with Richard Culatta, author of Digital for Good: Raising Kids to Thrive in an Online World. They discuss how to help kids bridge the gap between physical and digital spaces, how to model good technology behavior, and more. This is such a good point:

By focusing on screen time we miss the far more important concept that we should be teaching our kids; screen value. Some digital activities are just not a good use of a kid’s time (eg. playing a repetitive, luck-based game) while others provide much greater value (eg. editing a movie, creative writing, FaceTiming with a grandparent, etc.) And context is important to consider too. Digital activities that are appropriate on a long car-ride will likely be different than those on a beautiful spring day when friends are around, or the day before a large school project is due.

I’m going to go out on a limb here and say that is something that not only kids need to learn. We can all benefit from this lesson:

The most important lesson we can teach young kids is to recognize that some digital activities provide more value at some times than others. This means evaluating each digital activity on its own merit based on the circumstances.

We should probably also remember that controlling children’s behavior with screen time leads to more screen time:

Researchers investigated the impact of parenting practices on the amount of time young children spend in front of screens. They found a majority of parents use screen time to control behavior, especially on weekends. This results in children spending an average of 20 minutes more a day on weekends in front of a screen. Researchers say this is likely because using it as a reward or punishment heightens a child’s attraction to the activity.

In Getting to the Heart of Digital Accessibility Carie Fisher makes a compelling argument for making accessibility a priority in tech companies. Her conclusion really resonated with me:

Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

She mainly mentions developers in this article, but I’d argue that it is very much also the responsibility of product managers to make sure accessibility is always in the discussion on projects. We need to make sure that if extra time is needed for accessibility, we build that into the planning.

Further reading

For some practical advice on how to make emails more accessible, see Accessibility vs. Inclusion: What it Takes to Create More Inclusive Email Marketing Experiences and Email Accessibility: Looks aren’t everything.

For an example of how not to approach this topic, see Should websites be accessible to everyone? Domino’s says no.

Karolina Szczur makes some excellent points about using “technical debt” as an excuse for subpar products in The Technical Debt Myth:

Technical debt becomes a convenient blanket statement entailing frustrations, rushed decision-making, lack of process or architecture, and tedious maintenance tasks — the get-out-of-jail-free card for delivering a subpar experience.

It’s crucial to understand that as software and design grows older, that doesn’t necessarily mean we’re dealing with debt. We must look deeper under the surface to find the root cause of bottlenecks we’re facing. Only when we carefully assess the symptoms can we find solutions to building products that last.

While we’re on the topic, the most useful article I’ve read on technical debt is Henrik Kniberg’s Good and Bad Technical Debt (and how TDD helps) from way back in 2013. He discusses good debt, bad debt, and the importance of having a “debt ceiling”. Highly recommended post, and still very relevant.

The transcription of Cennydd Bowles’s talk on ethics in technology at SustainableUX 2019 is absolute gold and a must-read:

It’s a mistake to separate technical capabilities from human capabilities. These things act together. They become interwoven, hybridized actors. Things change what people can do and how they do it. It is true to an extent that old sage that guns don’t kill people; people do. But a gunman, the hybrid actor of a human and a technology coming together, sure as hell can.

So we have to abandon this belief that the things we build are just neutral tools. We have to recognize therefore that we can’t wash our hands of the social, ethical and political consequences of our work. This can be a tough sell to some. Technology and algorithms and then the bedrock of it all, data, are often seen as clean, objective, neutral things.

He gives lots of practical advice on how to make ethical thinking part of our work — including viewing ethics as just another design constraint, like any other. And for a more… uh… “incendiary” approach to this topic, also see Mike Monteiro’s We Built A Broken Internet. Now We Need To Burn It To The Ground.

Jeremy Keith writes about the developer community’s need to always talk about new things in Dev perception. I think the same can be said for every other profession, including product management:

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The point he makes in his post is a very good one — that we should always evaluate any technology (or, in our case, methodology or framework) based on appropriateness, not newness. It reminds me of Kellan Elliott-McCrea’s excellent list of questions a team should answer before they decide to adopt a new technology in their software development process.

Herb Caudill’s Lessons from 6 software rewrite stories is an extensive analysis of the rewrite projects of companies like Basecamp and Trello, why they succeeded or failed, and what we can learn from them:

Once you’ve learned enough that there’s a certain distance between the current version of your product and the best version of that product you can imagine, then the right approach is not to replace your software with a new version, but to build something new next to it — without throwing away what you have.

Eventually all product managers face a decision like this, so I found these case studies invaluable.

Kellan Elliott-McCrea has an excellent list of questions a team should answer before they decide to adopt a new technology in their software development process. For example:

If this new tech is a replacement for something we currently do, are we committed to moving everything to this new technology in the future? Or are we proliferating multiple solutions to the same problem? (aka “Will this solution kill and eat the solution that it replaces?”)

As he mentions in the post, these questions are not subtle… but I think they’re absolutely essential. It reminds me a little bit of Marty Cagan’s Product Opportunity Assessment questions.

This essay about the building blocks of the web by Rachel Andrew is really important. From HTML, CSS and our vanishing industry entry points:

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

A lot of words are being written about AI and machine learning these days, so it’s sometimes hard to know what to pay attention to. M.C. Elish and danah boyd’s Don’t Believe Every AI You See is one of those essays that I would consider essential reading on the topic. On the ethics of artificial intelligence:

When we consider the ethical dimensions of AI deployments, in nearly every instance the imagined capacity of a technology does not match up with current reality. As a result, public conversations about ethics and AI often focus on hypothetical extremes, like whether or not an AI system might kill someone, rather than current ethical dilemmas that need to be faced here and now. The real questions of AI ethics sit in the mundane rather than the spectacular. They emerge at the intersections between a technology and the social context of everyday life, including how small decisions in the design and implementation of AI can create ripple effects with unintended consequences.

And on the supposed “neutrality” of machines:

[There is] a prevailing rhetoric around AI and machine learning, which presents artificial intelligence as the apex of efficiency, insight, and disinterested analysis. And yet, AI is not, and will not be, perfect. To think of it as such obscures the fact that AI technologies are the products of particular decisions made by people within complex organizations. AI technologies are never neutral and always encode specific social values.

As Kevin Kelly also pointed out years ago in his book What Technology Wants, technology is never neutral. It possesses the collective values of its creators. And that’s where things so often go wrong. A great resource on this topic is Sara Wachter-Boettcher’s book Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech.