Hey there!
Lately, I have been thinking about how little of the community actually shows up in the newsletter.
The community hosts a ton of great conversations in threads, but, most of all, every month we run two live sessions, hosted by our awesome coach-in-residence Melinda Seckington, and always joined by yours truly. These sessions are:
Mastermind — leaders bring a real problem and we work on it.
AI Club — people show what they learned about AI that month, including the parts that did not work.
But a lot of the good stuff stays in Zoom. So, once a month, I want to start sending out a short recap. This should work on multiple levels: 1) it makes you learn useful things, 2) it gives you a feel of whether you should join the community, and 3) it gives you a heads-up of the upcoming events.
So here is the agenda for today:
🏝️ How to take time off right — what we discussed in the August Mastermind.
🪄 August AI Club — verbosity, legacy migrations, and a weirder kind of tired.
📅 What’s next — next events on Sep 4th and Sep 21st.
💬 How this works — and how to join.
Let’s dive in!
🏝️ Taking time off without the team stalling
In this month’s Mastermind, we talked about going on leave without making your inbox or your team fall apart.
One of the biggest points of discussion was about whether it’s okay or not to check in while away. Personally, I have found there is no hard-and-fast rule for that. Something you might consider is that checking Slack and replying on Slack are different things. You can glance at it, sure. But the moment you reply, you are telling everyone you are reachable. You are setting an example (for the better or worse) and presenting yourself in a way that is hard to walk back.
Whatever you choose for yourself, it’s critical that your ownership of things moves to someone else. Otherwise, if some recurring thing is still waiting on you, it’s not really time off. Voluntary, optional check-in is different from someone still relying on you to do things.
At the end of the discussion, I feel like we landed on some kind of model to make this work:
Mentally walk the one or two weeks you will be gone
Write conditional-ish guidance (if X happens, do Y, only call me if Z)
Name three things in the handover:
Open projects — and what needs to happen on each
People — and who is covering what
Processes you currently own — those that need a temporary owner
Appoint a deputy for the stuff you did not think of. There will always be plenty.
The deputy is particularly important because it should be the one person who can make the unexpected calls, and ideally the only one who is allowed to escalate to you for emergencies.
Doing all of this right is incredibly valuable, not just for your peace of mind while away, but because you may come back and figure out that some of the handovers can actually... stay that way. Many people reported it, and I confirm that from my own experience. When people are given the opportunity to fill bigger shoes, you might be surprised by how well they fare.
If you want the full writeup, you can find the community thread here (if you are in the community! If you are not, scroll to the end for instructions).
🪄 August AI Club
In this month’s AI Club, a few people shared their AI experiences, including both wins and failures. I liked three stories in particular:
Agents that will not shut up — two small skills came up for Claude: one that leads with the next action and bans the preamble, and one that rewrites into simplified technical English (the register airplane manuals use). We all agreed that agents can be incredibly verbose, so these skills can definitely help.
Treat the codebase as the source of truth — someone was migrating a 25-year-old Salesforce app and drowning in meeting notes that constantly would go stale mid-build. They eventually instructed agents to treat the codebase as the single source of truth, and docs, tickets, and transcripts as “best-effort context”. We also agreed that, out of all docs, the why behind a decision is the part worth writing down on purpose, because that’s what agents can’t likely reconstruct by looking at code. A couple of folks also have agents that update docs as they ship, plus a nightly pass that checks whether yesterday’s work left the docs behind.
Faster leads to a different kind of tired — it feels that automating the work is not making people less tired. Quite the opposite. Constantly reviewing what the model hands you back can make you more tired faster, as opposed to doing creative yourself. It’s also unclear how to do better on this. Some people try to speed themselves up to keep up with the models. Some protect the human part of the thinking. Some intentionally do less.
All in all, a very interesting conversation, where we focused more on the human parts of the process, than the technology of it.
Full notes are here.
📅 What’s next
Both the Mastermind and the AI Club, like all community activities, are for paid members of Refactoring. Here are the next editions 👇 you can RSVP on the event page to help us size the room and plan accordingly:
🪄 AI Club • Fri 4 Sep, 14:00 CEST — five-minute shares, questions, and a one-sentence fireside round at the end.
🧠 Mastermind • Mon 21 Sep, 14:00 CEST — this month we’ll talk about developer productivity and what “good” looks like when measuring output is getting less useful.
Bring your questions! These sessions work because of the members, not because someone gives a talk.
💬 How this works
The Refactoring Community is a private space for paid subscribers of Refactoring: it hosts async threads, Q&A, and monthly live rooms like these.
It is home to more than 1500 engineers and managers, and it’s my favorite place on the internet!
To join it, subscribe to the full version of Refactoring!
That’s it for today! See you on the 4th, or the 21st, or both!
I wish you a great weekend 👋
Luca