Accelerated Expertise

This is a summary of a remarkable 🌳 tree book, which presents a theory for and methods to accelerate expertise in real-world contexts. This summary is not comprehensive; it only covers some of the actionable theories and recommendations in the book and leaves out the considerable lit review and the book’s recommendations for future research directions. I’ll note that Accelerated Expertise is not written for the lay person — it is a book primarily written for organisational psychologists, training program designers and researchers employed in the US military. If you must read it — say because you want to put the ideas in the book to practice — my recommendation is to read Chapters 9-13 and skim everything else.

This is a companion discussion topic for the original entry at

Great summary @cedric.

2 things struck me while reading through this.

  1. The case model that Harvard uses for their MBA program seems like the closest existing learning model in business that I’m aware of to these techniques. What is a case but an interview with an expert and the actions they took?

Reflecting back on my own process my school wanted to do case style study. But I feel the instructors weren’t brave enough to actually require us to do the upfront learning of the tools so the sessions could be throwing us into a case situation (or don’t have expertise in case style learning in the first place!). And instead many (not all) classes ended up being going through the underlying basic content where you could simply just read a textbook for a similar learning outcome.

  1. While learning web development at the moment I feel that learning mental models on application at this beginner stage isn’t that useful. Somewhere between initiate and apprentice / junior journeyman according to the graph in the article.

However, once I’ve gotten to the point that I can build a fully functional something badly I’ll want to then transition mental models. I’m curious on other software engineers / web devs point of view here though. If you’d spent much time at the start of your learning the technical skills focusing on models / expertise have been significantly useful? Or does learning a certain amount of foundational knowledge beforehand make more sense to you?


I’ve been doing professional software engineering for 4 years and doing programming for 7 years. According to my experience, having an understanding of how compilers work and fundamental OS concepts help tremendously in the long run, but not very useful at the very beginning.

I’d lean in more on the learning the foundational knowledge than learning mental models from experts. One of the things that I think almost no university students really understand is design pattern. They indeed may have learnt from textbooks and done exercises, but I haven’t seen any fresh grad being able to really appropriately apply the design patterns in a real, production code base.

Why do design patterns seem so difficult despite being taught in so many courses? That I don’t know for sure, but I suspect it’s because design patterns are most useful for system design, and Effective system design requires insights drawn from serious contexts of use.

I’ve always felt that developing functional software isn’t that difficult, what’s difficult is to design it in a way that would still be resilient tomorrow, the day after, months later when someone else decides to make some changes to the code base, and even years later when the software is stopped being developed. A lot of important mental models in software engineering are about withstanding changes. They either describe the common patterns of changes and the common patterns of effective solutions, or they describe heuristics that would prevent your software from being affected negatively by changes.

Failures to take change into consideration have always led to some kinds of problems downstream, when they are much more expensive to fix. And I suspect only after having our existing mental models (i.e all the ways to develop software that do not take seriously the inevitability of change) destroyed do we really understand why new ones are necessary. Not sure what the literature on expertise and tacit knowledge would say about this though.


I’ve wondered this as well, and I think a huge part of it is that it depends on developing taste, or judgment. But … the interesting thing here is that the whole design pattern approach in software was inspired by Christopher Alexander’s A Pattern Language, and he’s argued that much of architecture design is this ‘step-by-step unfolding’. (And I’ve argued that the step-by-step unfolding is how product taste is expressed. )

So here’s what I don’t get — how does software taste/judgment and the design pattern approach combine? There’s certainly something to investigate here, though I don’t quite have the time to do it.

I think I couldn’t have said it any better.

There’s this piece by Li Hongyi that I think you might find very resonant where he goes “software is about developing knowledge more than writing code”.

Full section:

In software development, most ideas are bad; this is not anyone’s fault. It is just that the number of possible ideas is so large that any particular idea is probably not going to work, even if it was chosen very carefully and intelligently. To make progress, you need to start with a bunch of bad ideas, discard the worst, and evolve the most promising ones. Apple, a paragon of visionary design, goes through dozens of prototypes before landing on a final product. The final product may be deceptively simple; it is the intricate knowledge of why this particular solution was chosen over its alternatives that allows it to be good.

This knowledge continues to be important even after the product is built. If a new team takes over the code for an unfamiliar piece of software, the software will soon start to degrade. Operating systems will update, business requirements will change, and security problems will be discovered that need to be fixed. Handling these subtle errors is often harder than building the software in the first place, since it requires intimate knowledge of the system’s architecture and design principles.

I wish I had something more useful to say, but I went through a traditional Computer Science education, and it was everything this book says not to do.

I will say that building lots of throwaway side projects during university was pretty important to my skill development, though. You’ll want to build totally trivial things (e.g. todo apps, a Twitter clone) and use each project to experiment with some new technology — or even some weird approach.

But for now, I think learning the basics probably does help. And anyway — as I understand it — you’re already learning it through some sort of syllabus, right?


This is rather interesting: Yen Liow from Aravt Global uses a case study/library approach to train analysts.

Very similar to the tenets discussed in this book.

1 Like

It looks like there’s an attempt to create a learning program for children (ages 8-14) around creating simulations.

It’s an outgrowth of a school that Elon Musk started for Space-X kids.


Something interesting for the product folk here — Chris Butler has a post on creating and using Decision-Forcing Cases to train PM experience:

It draws on many of the same Marine training programs that NDM had a hand in creating, and is worth a look. The sample DFC is available here:

CC @minhthanh3145, @Jonathan

1 Like

I literally just accepted a job last night leading a team of 8 product managers.

I’m going to dig into this @cedric, thanks!

1 Like