Curated Content July 2022

A few pieces of content I thought were worthwhile in the month of July.


You will always have more Problems than Engineers

You will always have more Problems than Engineers.
How to deal with a sad reality.

Filtering and prioritizing work is more important than anything else, because no matter how large your team is, you will always have more work than you can do. A great reminder from Matt Schellhas.

Work is Work

Work Is Work
In which returns diminish.

An older article from Coda Hale, showcasing what we can learn from queuing theory about the business of organization design that want to solve problems. A must read for tech leaders, or folks who want to understand why things seem to be going so poorly in their organization, as this is likely at the root of many problems.

State of emergency! The four ways your state might be wrong

State of emergency! The four ways your state might be wrong
Alert! Your state might already be infected! learn how and what todo about it in this article.

A better take on the somewhat naive "Make illegal states unrepresentable". I've found while not bad advice, it isn't always immediate obvious to everyone about how to make it actionable. This one also comes with some excellent concrete examples of how to extract state well in an application.

Systemizing kick-off

15. Systemizing kick-off
Recently I tried a new exercise to systemize the way we kick off projects. Kick-off is that moment when the person who shaped the work hands it off to the development team. It’s an important moment in Shape Up because the dev team takes full responsibility for interpreting the pitch, defining tasks,…

Help more junior engineers have a jumping off point from which they can iterate on to understand the scope of a problem and how to handle it. Ostensibly a project management skill, but actually really valuable for all software engineers as well.

Integration Continuity: Bringing Down Giants

Some APIs are giants. You can slay them

Jimmy Koppel brings a great article with a few guidelines on good API design, especially with regard to continuity:

  1. Granularity - High-level functions should be composed of smaller operations, working continuously down to handle each level until you hit the atomic level of abstraction for your use case..
  2. Redundancy - If something can be represented in multiple standard formats, a good API should accept any of them. A file API should take in files as both paths and files, and output both bytes and strings.
  3. Coupling - Avoid functions which do multiple things combined, such as reading and parsing a file, without more granular options. Also avoid functions that share some hidden state and must be called in a certain order and interact with all other calls.
  4. Retention - Whether the library maintains internal state that mirrors your own app's state.

When Demand Exceeds Capacity

When Demand Exceeds Capacity
We are getting solar panels on our roof. Someday. We signed a contract last November and the original estimate for installation was May. S...

Another great article on flow and queuing theory in order to help ensure optimal business outcomes. Limit demand to meet capacity, and then scale up capacity to better meet demand.


Atlas of the Heart - Brene Brown

A fantastic book on being able to label, understand, and process different emotions. This is often under-explored territory for men generally, and has been helpful for me as I've been reading it both personally, and as a father.


This month I discovered a new podcast that ought to have been on my radar for a long time, but somehow wasn't. The Developing Leadership Podcast by Eiso Kant and Jason Warner. If it isn't in your subscribed show list an a technology leader you're doing yourself a real disservice.

Untangling & Optimizing Your Software Engineering Cycles, with Charity Majors

Episode 22 | Untangling & Optimizing Your Software Engineering Cycles, with Charity Majors | Developing Leadership | The Podcast for Engineering Leaders
Charity Majors, co-founder, and CTO of, joins us to talk about everything that’s wrong with engineering cycles, how throwing money at the problem by hiring more people is making it worse, and what we can do about it.

Charity Majors is one of the best in software engineering in my book, and this is a great conversation with her that links back up to the topic discussed in the article When Demand Exceeds Capacity referenced above.

We operate in these incredibly complex socio-technical systems, and when part of it is on fire when part of it's slow when part of it's understaffed and the people are working overtime and they have too many commitments, they have too many contracts, they have too many expectations, they're spread too thin… Throwing more people into that corner is very unlikely to help and it's very likely to make things worse.

This is just one of the highlights, but this is one I won't do any justice summarizing, so just go get it directly from Charity.

The Art of Building Software & Running Organizations with Wade Arnold from Moov

Episode 18 | The Art of Building Software & Running Organizations with Wade Arnold from Moov | Developing Leadership | The Podcast for Engineering Leaders
Co-Founder and CEO of Moov Financial, Wade Arnold, has had a hell of a journey as a software engineering leader. He joins us on the podcast to chat about building companies, attracting great software engineering talent, and increasing velocity as you scale.
... from engineering, culture Pull Request to Prod is probably the only metric you need to understand the health of the organization.”

Wade walks through how he was able to build a high performing engineering culture consistently, and what he believes you need to know to measure the health of an engineering organization.

The other highlight for me was how DevOps shouldn't stop in Engineering. He advocates taking it although the way through to go to market implementation as well, which really resonated with me.


While not perfect, I thought this was a good set of heuristics for how to avoid a meeting where it isn't needed, and how to know when it's needed.