My Favorite Ideas From Ldx3
Hey, Luca here, welcome to a new edition of Refactoring! Every week you get:
Here are the latest editions you may have missed:
To access all our articles, library, and community, subscribe to the paid version: Last month I spent two days in London for the LDX3 conference. To me this was kind of a big deal because, to be honest, I don’t go to conferences that often. Most of the time, the opportunity cost of traveling + losing several days of work feels just too much, and my general laziness does the rest. Instead, I am so glad that I did. I had a blast meeting many internet friends (most of whom for the first time) and putting faces behind names. It was also a chance to connect with the latest industry trends: the talks were excellent and I took a ton of notes.
So, I am back in my cave now, going through such notes. What do my notes look like? As a writer, I love individual ideas. I write down things that feel atomic — things that work well in isolation and I can later mix and match into larger articles. In fact, the book that had the largest impact on my writing work is probably How to Take Smart Notes (which we are currently reading in our book club, btw!). It convinced me—about 5 years ago—to create and maintain a long-lasting repo of evergreen notes, to be used for writing and reflection. Fast forward to today, I have 700+ of such notes, and I have written ~250 articles. The book was right! So at the conference I did just that: wrote down the best ideas I heard, and stored them at first into a giant file, and then as individual notes on my Notion db 👇
Today, in the spirit of writing something different from usual, I will recap the ones that I liked the most. These will be 1) useful by themselves, and 2) all together will also give you a slice of the current engineering leadership zeitgeist. Finally, I also write this as a nod to the great folks at LeadDev who organized the conference: they were really kind to invite me, and organized one of the best events I ever had the chance to attend. So here is the agenda:
Let’s dive in 👇 1) 🎯 Precision vs accuracy (slides)Pat Kua opened the second conference day with a great talk about delivery management. One of the ideas that I loved the most was the difference between precision and accuracy in software engineering.
At a high level, these are about:
This distinction matters because it leads to different failure modes for teams. You may have teams that are:
Diagnosing how your team fails is the first step towards improving. 2) 🔬 The quality confidence matrix (slides)Christine Pinto delivered a great talk about quality — this ever elusive concept in software. A common approach to quality is that all changes are created equal, and should go through the same QA process. While this is hard-and-fast and has some merits, it also risks cornering teams into extremes:
Christine proposes a more nuanced approach where confidence in what you ship should be proportional to two values: customer impact and technical risk 👇
The more the stuff is up and to the right in the quadrant, the more you should only ship it with high confidence and high quality. She also argued that improving quality in teams is a journey, which usually goes through three steps:
3) ⚖️ Empowerment vs direction (slides)Lara Hogan delivered an amazing talk — probably my favorite of the entire conf. She went through what feels like different eras of engineering management over the last 20+ years, through the lens of a single, crucial tradeoff: empowerment vs direction.
As managers, we often tend to stick to the same playbook: the one we are the most comfortable with. Some of us like being more directive, while others (like myself) are more at ease when they can leave ample room for people to explore and develop. Whatever strategy we like the most, there always come times where that strategy becomes ineffective. Sometimes it’s about the type of project, or the team, or a teammate we want to get the most out of. Good managers should get comfortable with both ends of the spectrum, and the spots in between. 4) 🤖 Measuring AI impact (slides)There is a lot of buzz around AI adoption in engineering teams, but most reports you can find focus on usage rather than actual impact. Laura Tacho, as she often does, pulled signal out of the noise and provided a simple framework to measure AI that focuses on three areas: utilization, impact, and cost.
Laura argues that focusing on the % of code written by AI is like focusing on LOCs for engineering metrics: not totally useless, but surely inadequate to figure out how you are doing. She also reported on how early we still are on the AI adoption curve, despite all the hype. As of today, top organizations (not average ones) still report only 60% of developers using AI on a weekly basis. Such devs, in turn, report around 4 hours of time savings per week. We are talking elite organizations here — with their house in order and top notch developer experience: numbers get sensibly worse for the average team. So, these numbers paint a wildly different picture from what you may get from social media, VCs, and entrepreneurs. AI may replace us all one day, but that day is not today. 5) ✨ Culture is what you leave out (slides)One of the highlights of the conference for me was watching Charity Majors bring on stage the article she wrote for Refactoring a few months ago: In Praise of Normal Engineers. She did an amazing job, and also added a few bits that were missing in the article. One sentence particularly stuck with me:
I love this bit because company culture is extremely hard to capture, and a great way to do so is by thinking at the things you are intentionally leaving out. The things you are not. You might be a company that hustles and moves fast, or one that is thoughtful and sweats the details. One that thrives through process, or one where people need to be comfortable with a little bit of chaos. One that looks like a family, or one that looks more like a professional sports team. For each of these, there is largely no right or wrong: the particular combination of qualities that make up your culture will be a good fit for some people, and a bad one for others. Being aware of where you stand is important to make sure you bring in the right ones. 6) 🪴 Growing engineers in the age of AI (slides)Meri Williams delivered a fantastic talk about how the life of junior engineers changes with AI, and what we should do about it. We often say that AI makes the job market harder for junior engineers, because it can do a lot of what they are capable of. The second-order effect is that juniors are expected to do a lot more than just a couple of years ago, like:
None of this is work that did not exist before — but people now encounter it way earlier in their careers than previous generations. So how can they cross this chasm? Meri argues that teams will need to focus more intentionally on teaching and mentoring, because the speed at which learning happens through simple osmosis is not enough anymore. 📌 Bottom lineAnd that’s it for today! Here is a recap of the six ideas, in one sentence each:
See you next week! Sincerely 👋
|
