Learn Fast and Read Things: why (and how) we started a technical reading group

At Affinity, we strive to make time not only for those things that are urgent — fixing bugs, shipping features, supporting our customers — but also for those things that are important but never urgent.

Learning is one of those key priorities: there’s rarely an urgent, short-term reason to spend time learning, but in the long run, it’s the most important thing we can do to increase our effectiveness.

As software engineers, we’re lucky to have tons of great and widely accessible ways to learn: we can attend meet-ups and conferences, allocate time to experiment with new tools and techniques, take online classes, and more. On the Affinity engineering team, one of our favorite tools to accelerate our learning is our technical reading group, which we kicked off a few months ago. We hope this blog post convinces you to do the same and gives you some ideas for how to start.

Here’s how our technical reading group works:

• We meet once a week for 45 minutes.
• We alternate between reading a book for a few weeks, and then reading shorter articles for a few weeks.
• We rotate which engineer is responsible for facilitating the discussion.
• Facilitators aim to create discussions where everyone participates. Often, this means doing smaller, focused brainstorms or conversations in pairs or small groups before we regroup for a larger discussion.
• For any given week, doing the reading and attending the group is completely optional, so engineers choose which sessions to join based on interest.

We’ve chosen a few different kinds of topics. Sometimes we read about specific, technical topics that are particularly relevant or timely given our tech stack and roadmap. For instance, we spent a week reading about Kubernetes (which we use in production — you can read more about our early experiences with Kubernetes here). We spent another week reading about Citus when we were evaluating whether to use it to scale out our data storage (we’ve since decided it’s worth trying out, and are currently in the middle of that migration project). And we spent a week learning about GraphQL (we decided to avoid migrating to GraphQL for now, though we might revisit that decision down the road).

Other weeks, we read about general engineering principles and practices that we can apply at Affinity. For instance, we spent four weeks reading The Effective Engineer. Our group discussions of that book led us to several concrete action items: among other changes we’ve made since reading it, we’ve been more careful to avoid one-person projects when possible and to improve our project estimation by tackling the riskiest, highest-variance tasks first.

And sometimes, we choose topics that are purely to satisfy our engineering interest, even if there’s not much short-term relevance to our day-to-day work. Early this year, we spent a week digging deep into the mechanics of the Meltdown and Spectre attacks (we thought this blog post on Meltdown was fascinating and very readable — check it out if you haven’t already!). Another of our upcoming readings involves a seminal paper on avoiding network congestion.

Of course, this all takes time: an hour or so of reading and 45 minutes of discussion each week. But the long-term payoff is worth it. Say, for instance, that reading The Effective Engineer increased our effectiveness by a conservative 1%. Over the course of a 2000-hour year of work, that means each of us on the team will save about 20 hours. That’s a great return for a book that took less than 10 hours to both read and discuss — and those returns keep compounding over time, paying for our initial time investment many times over. And beyond increasing our direct impact at Affinity, this practice of continual learning increases our fulfillment and enjoyment of our work.

Facebook famously used to promote a culture where engineers could “Move Fast and Break Things” (though they’ve since changed their stance on breaking things). There’s a lot to be said for focusing on speed and execution, but we hope that wherever you work, you can also make time for another priority: Learn Fast and Read Things.

What strategies does your team use to accelerate learning? We’d love to hear about them!