Menu

Short review: Ascension by Nicholas Binge

I’m on a bit of a break right now (LinkedIn update here if you’re interested), and while I’m figuring out how to spend my time wisely I’ve been reading a lot of sci-fi. The latest book I finished—and really enjoyed—is Ascension by Nicholas Binge:

An enormous snow-covered mountain has appeared in the Pacific Ocean. No one knows when exactly it showed up, precisely how big it might be, or how to explain its existence. When Harold Tunmore is contacted by a shadowy organization to help investigate, he has no idea what he is getting into as he and his team set out for the mountain.

My best attempt at describing this would be it’s like Event Horizon on a mountain, with some really interesting existential philosophy thrown in. Some quotes I liked and highlighted:

There’s no such thing as starting fresh: new beginnings all contain the old ones bundled up inside of them. Starting fresh means not having a history anymore; it means not having an identity.

And…

“Do you know why Sisyphus keeps climbing,” Thomas asked, looking up at me, “even though he knows he’ll always end up back at the start?” John’s last words—echoing back at me across space and time. “Why?” He smiled and stood up. “Because that’s what life is. A constant climb. Eternal growth. The continual battle against entropy. It doesn’t matter what the destination is, or what’s at the top; all that matters is that you keep climbing. That’s what it means to be alive, Harold. That’s what it means to be human.” He turned away from me, walking off into the night.

If you’re in the mood for some smart spacey sci-fi horror, give this one a go!

Product quality as differentiator

I fully agree with Chris Coyier’s main point in Other People’s Busted Software is an Opportunity:

If you make software that does work reliably, you’ve got a leg up. Even if your customers don’t tell you “I like your software because it always works”, they’ll feel it and make choices around knowing it.

It feels like so many teams prioritize “innovation” over quality, so we end up getting stuck with products that have an overwhelming number of features but they all barely work—or the whole thing is slow and cumbersome. At some point we seem to have forgotten that product quality is not optional, and that it should be built in from the start.

Not only that, but in a “project” mindset teams just continue to move on to the next feature without taking the time to learn and improve what they shipped, as Marty Cagan points out in From Projects to Products:

Most efforts lose all hope of providing real value, and just try to get something shipped. Then as soon as they do finally ship, it’s not like they can iterate to improve the product. Instead, the people usually scatter off to their next assignments; nobody owning the outcome, and any important learnings from the effort likely lost.

This seems almost silly to point out, but a feature is not going to help your business if (1) it doesn’t add value and/or (2) it doesn’t work well. And yet somehow lots of teams put validation and quality on the backburner while they rush to get more features out. So Chris is right in his post: focusing on product quality is a huge differentiator in today’s software market.

Uncovering a new class of responsibilities with AI/LLM

Since I prefer reading over watching, I appreciate Dave Rupert’s summary of this video about AI/LLM responsibility in his post Uncovering a new class of responsibilities:

Three rules of technology outline their nearly hour long talk:

  1. When you invent a new technology, you uncover a new class of responsibilities
  2. If that tech confers power, it starts a race
  3. If you do not coordinate, the race ends in tragedy

It’s those last steps that are the concerning ones. If we fail to respond to #1, we end up with #3.

Incidents can't be prevented, but learned from

Here’s a good reminder that Incidents can’t be prevented, but learned from:

But approaching incidents with a mindset of learning makes it an exciting rather than painful situation. Because you’ll know you’ll never run out of sources for learning. And once you’ve realised what a good source for learning incidents are, it’s maybe even time to take a good look whether shallow incident data like “mean time to detection” and “mean time to resolution” (or the maybe worst offender of all “mean time between failure”) are actually helping your team approach incidents as a learning opportunity or maybe are incentivising an approach that foregoes learning for a better look of those metrics.

My Reading Philosophy in 17 Guidelines

I like Tracy Durnell’s Reading Philosophy in 17 Guidelines, especially this one:

Treat my To Be Read list as a stream to dip into, not a to-do list. I know I won’t get to all the books on my TBR.

It reminds me of an article from 2011 that I come back to often—The Sad, Beautiful Fact That We’re All Going To Miss Almost Everything:

Now, everything gets dropped into our laps, and there are really only two responses if you want to feel like you’re well-read, or well-versed in music, or whatever the case may be: culling and surrender.

Culling is the choosing you do for yourself. It’s the sorting of what’s worth your time and what’s not worth your time. It’s saying, “I deem Keeping Up With The Kardashians a poor use of my time, and therefore, I choose not to watch it.” It’s saying, “I read the last Jonathan Franzen book and fell asleep six times, so I’m not going to read this one.”

Surrender, on the other hand, is the realization that you do not have time for everything that would be worth the time you invested in it if you had the time, and that this fact doesn’t have to threaten your sense that you are well-read. Surrender is the moment when you say, “I bet every single one of those 1,000 books I’m supposed to read before I die is very, very good, but I cannot read them all, and they will have to go on the list of things I didn’t get to.”

The Product Culture Shift

Here’s a great post by Camille Fournier about The Product Culture Shift, and how every part of an engineering culture needs to change when product managers are added to traditional software infrastructure organizations.

To start, let’s be clear about one thing: as tempting as it might be, just hiring product managers won’t fix this problem. Even if you could find enough good product managers who want this type of job, which you can’t, product managers are only useful when they are paired with willing engineering teams. If the engineering teams don’t feel a sense of ownership for delivering a great product to their customers, product managers are unlikely to close that gap, and they will more likely turn into glorified backlog groomers than true product leaders.

Dear Alt-Twitter Designers: It's about the network!

Excellent post by danah boyd, reminding us that with social networks it all comes down to nurturing the network dynamics, not the technical features.

That’s the thing about social media. For people to devote their time and energy to helping enable vibrancy, they have to gain something from it. Something that makes them feel enriched and whole, something that gives them pleasure (even if at someone else’s pain). Social media doesn’t come to life through military tactics. It comes to life because people devote their energies into making it vibrant for those that are around them. And this ripples through networks.

Manage the What, Not the How

Molly Graham makes a key distinction about good management in the post Manage the What, Not the How:

The key to exceptional management is to get great at defining the “what”. As a leader, you need to know how to create alignment, how to clarify what you expect, and how to communicate all of it. 

She goes on to explain that a big mistake she sees some managers make is to focus too much on how work is done. And when you do have to get involved in the “how”, do it through coaching:

When you intervene, you intervene with coaching. You can say, “That email you sent seemed abrupt,” or “You missed these two points that were important.” You can share examples to learn from. You’re giving feedback and then letting them try it again, not jumping in to micromanage.

Reading Well

I love the point Simon Sarris makes here about the importance of reading fiction, and how it’s useful for work purposes as well:

I also tend to stress fiction because I think, especially among my professional peers in the industry of software, that there is too great a fondness for non-fiction. I think this arises from a belief that superior knowledge of the world comes from non-fiction. This thought is attractive to people who build systems, but over-systematizing and seeing systems in everything can be a failure mode. Careful descriptions and summaries miss too much of the world. Hard distinctions make bad philosophy. Reading fiction helps you become an unsystematic thinker, something that is equally valuable but more elided by some engineers. It is easy to maintain an intellectual rigidity. It takes more care to maintain a loose poeticism of thought.

Why the remote-work debate stays so heated

Allie Conti frames the remote work debate really well in this post. In short, how someone feels about remote work and “return to office” is extremely personal:

I’ve given you this narration of my personal experience because, for all the talk of productivity and metrics and company culture, the topic of returning to the office is intensely personal. My needs and desires, for a variety of reasons relating to my age, finances, circumstances, health situation, and lifestyle, might be very different from those of workers who fall elsewhere on any of those axes. Some working parents have said they might value flexibility at school-pickup time. Some workers of color have raised the benefit of being free from in-office microaggressions. Recent college graduates may want to go into the office to make friends. And of course, not all workers are able to work remotely. The physical space in which one works, or hopes to work, intersects with one’s most personal choices. It collides with and reveals what people value most.

It feels like we should find ways to cater for both types of preferences. Hybrid work environments are far from an ideal solution, but it is one way to meet in the middle.