Boy scout maintenance, ICAP framework, and cognitive load 💡

Monday Ideas — Edition #71

Hey, Luca here! Welcome to the Monday Ideas 💡

Every Monday I will send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.

You will also receive a long-form, original article on Thursday, like the last one:

• How to Handle a Departure 🚪

To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!

p.s. you can learn more about the benefits of the paid plan here.

---

🐺 QA Wolf (Sponsor)

Last week you read about how QA Wolf offers a cost-effective approach to getting 80% automated test coverage in just 4 months.

Here's how they do it:

1. QA Wolf builds your tests in open-sourced Playwright. 

   You own the tests — no vendor lock-in.

2. Unlimited, parallel runs on their K8s infra are included at no additional cost. 

   Running your test suite, on every deploy, will only take a few minutes.

3. 24-hour maintenance and triage.

   Ask them a question at any time and they'll respond freakishly fast.

4. Human-verified bug reports include video recording and reproduction steps.

   Fix bugs before they reach your customers.

---

1) 🧠 The Three Types of Cognitive Load

Engineers and teams are able to bring the most value when they sustain the right amount of cognitive load for their work: not too much, not too little.

However, not all cognitive load is created equal. Based on Team Topologies, there are three kinds:

1. 🔨 Intrinsic — your tech skills, which are intrinsic to your work. E.g. how classes are defined in Java.

2. 🐌 Extraneous — stuff you have to remember that doesn’t bring value, so it is mostly a distraction. E.g. how do I deploy this app, again?

3. 🌟 Germane — knowledge about your business domain and the problems you need to solve. E.g. what are good abstractions for financial data, or best practices for an e-commerce checkout.

Germane load is the only knowledge that creates value. So, you want to create teams where such load is maximized, while intrinsic and extraneous ones are minimized.

🔨 Reducing Intrinsic Load

Intrinsic load is about technology.

You can reduce it via good tech choices that make stuff easy to build. E.g. building your prototype with a low-code tool can reduce the intrinsic load required to operate it, as opposed to going for a custom full-stack app.

Also, you can reduce intrinsic load by working on your team capabilities, with training, pair programming, and hiring for the skills you are missing.

🐌 Reducing Extrinsic Load

Extrinsic load is about bureaucracy — meant as the unnecessary tasks and steps you need to perform in your dev process.

Extrinsic load is minimized by creating good DX. I have found that optimizing for fast and frequent releases, good tooling, and, in general, a culture of continuous delivery, is the best cure for this.

🌟 Optimizing Germane Load

When you put all things together, you should organize teams so that they are able to apply their domain knowledge to solve problems of the right size, minimizing the amount of plumbing and non-business-related effort.

You can find the full review and summary of Team Topologies in this past edition 👇

Team Topologies 📘

---

2) 🏅 Boy Scout Maintenance

Always leave the code better than you found it.
— Robert Martin (Uncle Bob)

The boy scout rule, coined by Robert Martin, is about taking the chance to improve the code whenever you are already making changes to that code, for any other reasons. Think of adding a test that wasn’t there, or updating a small dependency.

This approach works well, but not for everything. A few upsides and downsides:

• 🟢 It avoids context-switch — it makes the change cheaper than scheduling a separate task.

• 🟢 It doesn’t require negotiation — it is just agreed that estimates keep some slack for these type of tasks.

• 🔴 Timeline is best-effort — doing such improvements depends on other tasks, so it’s only suitable for issues that can afford to wait kind of indefinitely.

• 🔴 Only suitable for very small tasks — Adding a few hours to improve existing tests is ok, but you can’t slip e.g. two days of maintenance on top of two days of feature work. I have seen it happen and it breaks trust. Don’t do it.

A corollary of the rule is to do immediately whatever is too small to be otherwise tracked and planned.

"Will it take less than two minutes? If yes, then just do it.”
— David Allen, Getting Things Done

This is lifted straight from the GTD methodology, where David Allen advocates doing on the spot any task that requires less than two minutes to complete, like sending a short email or making up the bed.

In software, you might want to put the threshold to 5-10 mins, and there is plenty of stuff that falls into this, like cosmetic UI updates, small bugs, or changing pieces of copy.

In these cases, you will spend more time creating a ticket and pondering (multiple times in the long run) when to do it, than just by doing it on the spot. So do it, or ignore it forever (which is equally ok).

I wrote a full piece about how great teams handle maintenance 👇

How to Plan for Maintenance 🛠️

---

3) 🎓 The ICAP framework

The ICAP framework was created in 2014 by Michelene Chi, who demonstrated how higher student engagement leads to a better learning outcome.

ICAP buckets learning experiences into four main categories, in ascending order of engagement, and, therefore, effectiveness:

1. 🔴 Passive — experiences where you are just exposed to some learning material, like a book, or a lecture.

2. 🟡 Active — experiences where you have exercises to complete as part of your learning like regular online courses.

3. 🟢 Constructive — experiences where you learn by doing. The building is a core part of the learning process, like in a workshop.

4. 🟣 Interactive — experiences where constructive learning is augmented by asking questions and getting continuous, real-time feedback, like in pair programming.

Interactive learning leads to the highest retention, especially in areas that are very hands-on, like tech skills.

You can put popular education options on this scale, from the most passive to the most engaging: books, newsletters, online courses, workshops, 1:1 coaching, pair programming, etc.

When it comes to the quality of the learning, there is no doubt that the more you move to the right, the better.

However, deep interactive experiences are not always the best call. In fact, these are also:

1. Hard to design — it’s tough to create learning material that includes a lot of building and active stuff, as opposed to simple slides or text.

2. Hard to scale / expensive — the more feedback loop people need, the more bespoke the experience needs to be, the worse it scales. Some of the most interactive learning experiences in tech are pair programming and coaching, which are both 1:1.

3. Demanding for the learner — interactivity is about intensity. You are getting more results because you are putting it more effort. You can’t always afford that.

So, passive experiences may have low retention but are also cheaper and low-effort. Sometimes, that’s bad — but sometimes that’s just what you need.

E.g. I am a fan of the RealLifeLore Youtube channel to learn more about geopolitics. I don’t have a personal goal about this, so I am just happy to watch some videos, knowing that my understanding will be shallow, and retention low. Also, I usually watch them over lunch, so I don’t really have the energy bandwidth for more. For this use case, the passive approach is perfect!

So, I believe you can maximize learning by finding the right blend of passive and active experiences, based on what you need the learning for.

More ideas about investing in your professional growth (and that of your team) 👇

How to Invest in Engineers' Growth 🎓

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.

2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.

I wish you a great week! ☀️

Luca