You will always have more Problems than Engineers
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
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
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.
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
Jimmy Koppel brings a great article with a few guidelines on good API design, especially with regard to continuity:
- 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..
- 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.
- 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.
- Retention - Whether the library maintains internal state that mirrors your own app's state.
When Demand Exceeds Capacity
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
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
... 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.