I watch a lot of tech talks. These are my favorite that I’ve watched recently, with what I love about them and keep returning to for inspiration or clarity.
Teamwork & Leadership
Being Glue - Tanya Reilly Confession/boast: the nicest feedback I ever got from another developer was that I’m “like slime”. By that this person clarified they meant I’m good at filling the gaps of a project to move things forward. So I relate to a lot of this talk personally.
While I’ve been fortunate to have roles where I write a lot of code and have shipped new products and features, I had to fight for that. When I decided to go back to school to be a software engineer, a couple of trusted mentors told me to “let the geeks do the coding” and stick to my strengths. Part of getting where I am now has been being careful not to be too good visibly at other things (i.e. communication) early in my career. Her metaphor of being a manager as similar to riding a rollercoaster - “you must be this socially competent” - “okay, I am, but it’s still not for me” - is one I love.
Rockstars, Builders, and Janitors: You’re doing it wrong - Alice Goldfuss I love all of Alice’s talks. She taught me what the hell containers are (The Container Operator’s Manual) and gave me my favorite evocative term for tech debt “centralia infrastructure” (Martyr’s on Film: learning to hate the #oncallselfie) in other talks.
This one is meaningful to me because I’ve seen it play out at multiple companies now. My instincts definitely lean toward the Builder archetype, but I genuinely believe good engineers can do all three as Alice suggests. I think this offers a good model for an organization that believes in fostering a growth mindset.
Debugging
Debugging Under Fire: Keep your head when systems are losing their mind - Bryan Cantrill The gnarliest bugs I’ve ever found and fixed have always had 2 or more mild root cause issues interacting in bizarre and difficult to trace ways. In this talk, Bryan paints a picture for how trends in modern software create conditions for bigger and more catastrophic outages in services. He also talks about debugging as an art and science - “debugging is the act of asking questions and answering them, not guessing” and “you want to form questions, not hypotheses”.
Architecture
Polly Want a Message - Sandi Metz Working with legacy systems, whatever that means, this is the talk that has most inspired me. It describes common problems for scaling an application, especially with Object Orientation, and how to make it better and use it’s affordances to make your code easier to reason about and change. She illustrates each step in her talk with code examples that are both simple to comprehend and in my experience a realistic roadmap of how applications grow . This presentation makes me feel empowered to tackle the parts of a codebase that are causing pain.
The Many Meanings of Event-Driven Architecture - Martin Fowler At my last job, I worked under a lead who was really excited about event-driven architectures. We had several meetings where he spoke rapturously of changing the monolith we were working on to be more event-driven. In trying to understand, I was confused. I had previously worked on an application with an event queue and logging. Was that what this described? Well, kind of. It seemed the more I asked and read, the more the phrase seemed to take on different nuances. I couldn’t get to a point where I felt confident I grasped the implications of the discussions.
Some time later I watched this talk by Martin Fowler, where he breaks down “Event-Driven Architecture” into 4 distinct but related patterns. This was for me the key to unlocking what those articles implied and where certain approaches might be most appropriate, and it gave me more exact terms to use in debating potential designs.
Data
To SQL or NoSQL: That is the question - David Ostrovsky I studied big data management and NoSQL in school, but until recently hadn’t worked on an application where I got to use it in production. Now that I have, one trend I’ve noticed is a desire to put things in NoSQL because of a naive belief that it will be “easier” than working with a relational database. To me, using NoSQL is more of a tradeoff. I’ve used this talk when other engineers are like “yeah lets make everything a JSON document”, to help illustrate the different factors and costs.
Design
Practical API Design - Ronnie Mitra I love working on integrations in platforms, and started my career working on consuming APIs (especially RESTful-ish web APIs), where I’ve had to do some weird things to do what I needed with the model exposed by a partner. Now that I’m on the side of designing APIs for others to consume, I want to be sure what I’m creating is reasonable and intuitive. This talk gives some great practical approaches to that.