As I have been onboarding to a new role at a new company, I've found myself excitedly sending out links to my all-time-favorite blog posts, conference talks, and books to my new colleagues in just about every one-on-one. So, I decided it was about time that I listed all of them out in one place.

I did my best to add rough categories to the list, but so many of the most mind-blowing, paradigm-shifting articles/talks/books that have stuck with me over the years defy categorization because they explore the connections between people, process, culture, strategy, and writing code.

Part 2 of this two part series focuses on culture and how work gets done - topics like organizational design and how to approach the discipline of engineering.

Part 1 focuses on the more personal, human side of working in tech - navigating your career, particularly as an underrepresented minority (URM) in tech, and being an effective senior/staff+ engineer.

Organizational design and how work gets done #

Infrastructure Gravity & Domain Engineering, by Jack Danger (my favorite excerpt from his book Executive Engineering) #

This is yet another article where Jack described a phenomenon and the impact of that phenomenon so perfectly that my situation clicked into place. I shared this article with anyone and everyone who would listen to me - including my CTO at the time! It's hard for me to continue to explain it without quoting the whole dang article at you, but I will share one of my all-time favorite metaphors for the cost of unchecked feature development:

"Creating features one after another without consolidating them is like making a linked list. Useful, to be sure, but the cost of traversing it is O(n). If we were to structure these features in a better architecture then it’s like storing elements in a binary tree. Which, under ideal conditions, can yield a far more efficient O(log(n)) performance."

The Tyranny of Structurelessness, by Jo Freeman #

In this article from 1970, Jo Freeman describes the failure states and toxic patterns that emerge in "structureless" groups - in her case, feminist activists for women's equality in the 1960s and 70s. She argues that in groups without a defined structure & hierarchy, shadow structures will arise that have unacknowledged, secret power over decision-making. On the surface, this might seem like it's not particularly applicable to software engineering, but there are three situations that commonly happen in our world which, in my experience, exhibit the patterns and failure states she describes:

  1. So-called "flat" org structures
  2. Working groups
  3. Teams without strongly defined roles and responsibilities.

Read this article with an open mind and I'm sure it will resonate with you as it does with me!

Work Is Work, by Coda Hale #

If you haven't figured out yet, I get really excited about applying computer science principles to the act of writing software, so I LOVE how Coda uses queuing theory to help reason about how work gets done in organizations of teams of people. Warning that it is a very dense read (I admit to moments of feeling out of my depth while reading it and had to read it again to really get it), but do not let that stop you! This is probably my second or third most-shared article of all time because it is so full of insights.

Team Topologies, by Manuel Pais and Matthew Skelton #

I think a lot of software engineers look at topics like org design and think "Oh, that's for managers to worry about", but as you get more senior, you realize that org design and team structure/purpose/function has a HUGE impact on your day-to-day work. Team Topologies is one of the best books out there that tackles the topics of org design and team structure in a way that is approachable to anyone. I listened to the audiobook, then bought a phsyical copy in order to go back in and highlight stuff, so you know this is a good one.

Conway's Law, by Martin Fowler #

This one is a bit of a bonus article, because you can't have any kind of a cogent discussion about org design or software architecture without understanding the impact of Conway's Law. Martin's article on the topic stands out for the introduction of the "Reverse Conway Maneuver" concept.

Approaching the practice of software engineering #

The Wrong Abstraction, by Sandi Metz #

Out of all of the blog posts and talks I've read about the art of writing code, this one sticks in the forefront of my brain year after year. It starts with the banger quote, "[D]uplication is far cheaper than the wrong abstraction", and then goes on to be a fantastic takedown of the cult of DRY (do not repeat yourself) in software. Ditto to everything Sandi says.

So You Want to Be a Wizard, by Julia Evans #

All of Julia's zines are so good (especially Oh Shit, Git!?! :wink: :wink:), it was hard to pick just one. But, I think this one that started it all is my favorite. Chock full of great and easily digestible advice on a broad range of topics like debugging and reading source code which aren't discussed nearly enough in the industry. Best part is that it's free!

Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans #

It's hard to understate what an impact reading about DDD for the first time had on the way that I approach architecture and code design. The terminology can get a bit heavy-handed, but the concepts really helped me to forge a path out of the spaghetti code era of the mid-2000s. I recently re-read the book, and the DDD approach to software still resonates super strongly with me and is still extremely relevant 20+ years later!

Kill It With Fire, by Marianne Belotti #

... Speaking of spaghetti code from the mid-2000s, Marianne's book is a) easily the best book title ever, and b) the best discussion of how to realistically approach building on and around the dreaded LEGACY CODE that we all have to deal with. As a bonus, my former colleague Allie Jones sat down with Marianne for an Etsy Code as Craft fireside chat about modernizing legacy codebases, which was a fantastic discussion.

Bonus: Etsy's greatest hits #

I was incredibly privileged to work at Etsy for 8 years, where I got to learn from the best and most amazing group of brilliant and kind humans I have ever had the pleasure of working with. I cannot say enough good things about what a truly magical place Etsy was in the 2010's, and how much I grew as an engineer thanks to the revolutionary ways that we approached the practice of engineering and building a strong culture.

Choose Boring Technology, by Dan McKinley #

If you only read one article from the Etsy greatest hits here, this is the article to read. In this industry that loves to chase the shiny new thing, boring is often equated with bad, but Dan does a great job explaining why boring is good! He then walks through how to think systematically about when and why to adopt new technology because, as he says, "Adding the technology is easy, living with it is hard."

Blameless Postmortems and a Just Culture, by John Allspaw #

At various points in my career I worked places where mistakes, outages, and incidents were seen as personal failures. So I learned very early in my career that when you are so afraid of making a mistake that you fixate on avoiding failure, you actually end up making more mistakes. It was a revelation when I first learned about the concept of blameless postmortems that are opportunities to learn from mistakes "without fear of punishment or retribution".

Thanks for reading, be sure to check out Part 1! If you have any great articles, talks, or books that changed how you think about software engineering, I'd love to hear from you on Bluesky or Mastodon! I am considering a future series that gets more into frontend, performance, etc. LMK if that sounds interesting to you.