Curated Content February 2024

A few pieces of content I thought were worthwhile in February 2024.

Curated Content February 2024
Photo by Theo Eilertsen Photography / Unsplash

Articles

It's time for the 'Sell painkillers, not vitamins' metaphor to die

It’s time for the ‘Sell painkillers, not vitamins’ metaphor to die
There’s a ubiquitous piece of startup advice: “Sell painkillers, not vitamins.” With painkillers, the story goes, you fix something that’s b...

This phrase is ubiquitous in sales, but one that I found was a bit hollow, like the author of this post did. They also find funny data to back up both the fact that it's not actually correct, but that for any stable organization much like an otherwise healthy human, "vitamins" are going to get a much larger share of the individual's or organization's resource than painkillers.

It's only organizations that are on the brink of death that shed vitamins and only buy painkillers.

The fallacy of sacrificing quality to build stakeholder trust

The fallacy of sacrificing quality to build stakeholder trust
Have you ever experienced high pressure on your team?

A great article talking through why you can't actually sacrifice quality in order to build trust in your organization.

The Cost of Being Convinced

The Cost of Being Convinced
The Cost of Being Convinced écrit par Ploum, Lionel Dricot, ingénieur, écrivain de science-fiction, développeur de logiciels libres.

I think the article is worth reading, though using atheism/religion as the example is certain to ruffle some feathers. My key takeaway is the following:

Before any argument, any debate, ask everyone to answer sincerely to the question what will happen if I’m convinced? What will I do? What will change in my life?
More often than not, changing opinion is simply not an option. Which settle any debate before the start.

Why you need a "WTF Notebook"

Why you need a “WTF Notebook”
There’s a very specific reputation I want to have on a team: “Nat helps me solve my problems. Nat get things I care about done.”

This month I really ought to cut to the chase and recommend Nat Bennett's writing. They have several great blog posts I highlight below, along with an incredible popup newsletter on working at Pivotal that you all have now missed.

This first one is the idea that for any new role you ought to keep a notebook of things that make you say what the fuck when you join any new organization. You don't have to share any or all of it immediately, but your fresh perspective can be immensely valuable, when you have gathered enough context to see the bigger picture.

Pairing is for peacocks

Pairing is for peacocks
Pairing gives engineers a way to show off to each other without shipping really complicated stuff.

The first of four other posts from Nat I'm highlighting on pair programming.

This one highlights how you can use pair programming to meet the needs of members of your team to show off, but rather than that taking the form of some ill considered rewrite, or niche technology with no real upside, it instead gets channeled into practical application.

Six key skills for pair programming

Six key skills for pair programming
This article describes the key skills required to be a good pair, a pair who is productive and rewarding to pair with for most people.

A quick list of skills you might not have considered when you thought about giving pair programming a shot.

Tips for pair programming from Air Force Colonel John Boyd & also from Ms. Frizzle

Tips for pair programming from Air Force Colonel John Boyd & also from Ms. Frizzle
This is great if you’re dealing with someone who’s trying to kill you. You can use it to overcome some major disadvantages in raw power with enough speed. It’s a lot less great if the mental model that you’re invalidating is your pair’s mental model of the codebase you’re both working on.

If you only read one of Nat's articles on pairing, I'd actually make it this one. This one explains the most painful and most frequent failure mode of pairing that I've experienced, and seen teams repeatedly experience, which is out of sync OODA loops. But when you understand the issue, it suddenly becomes much easier to work through it and reach a solution.

The Mortifying Ordeal of Pair Programming All Day

The Mortifying Ordeal of Pair Programming All Day
I had to confront a lot of my fears about myself, sometimes every day. I had to learn to show someone else all the things I didn’t know, my limitations as a human and a software engineer.

Pairing isn't all sunshine and rainbows. It can be a lot. Too much sometimes. And so like Nat, I highlight this one as well because I want to present the whole picture and not just the positive.

That said, I believe it's still worth it, and in conversations with Nat, they feel the same.

Books

No book recommendations this month.

Conf Talks

No conf talks this month.

Podcasts

No podcasts this month.

Microposts

Put another way: "The most important output of senior engineers is more senior engineers." I've worked at one place where people actually acted that way, but most don't.
https://cosocial.ca/@timbray/111868457940976080

The highlight from the middle of an interesting thread on attempting to stay up to speed on changes in the industry and growing talent.

If you're responsible for growing an organization long term, I think this is likely the most important and worthwhile output of senior engineers.