The Brain Sandwich
21 points by ani
21 points by ani
This assumes that our brain capacity is somehow innate and constant. It’s not. It’s built and kept alive by the act of doing. Stop doing and the 2 external sides of the sandwich degrade.
The article ignores the fact that by completely delegating the second step implies a (measurable) process of atrophy of our skills.
doing
A lot is hiding in this word.
Matheus' article proposes that reading and understanding the task, its scope, the diff, the tradeoffs, and the explanation are the important part of doing.
I think what a lot of us are struggling with is the jagged, fuzzy, ever-shifting boundary between the vital self-improving struggle of doing, and the inessential mechanical routine of inserting UTF-8 characters into files or the wasteful soul-sucking development of expertise in minutiae that will be outdated in two years. They're not the same, but they're not cleanly separable, and yet we really do want to maximize one and minimize the other.
We used to mock architects that don't code because observing is not enough to be competent at design.
This is like asking someone who has never picked up a pen to create art.
The manipulation of minutae is what informs good design.
the wasteful soul-sucking development of expertise in minutiae that will be outdated in two years
I understand the point and somewhat agree, but I do not think that it is entirely wasteful. IMHO, any expertise development can be positive, one never knows what will be useful in the future.
we really do want to maximize one and minimize the other.
I wonder if this doesn't tend to the maximization of a single thing. E.g. "knowledge", "agency", "efficacy", ...
Whenever I use AI, it's almost always to save me time by writing a piece of code I would have written similarly anyway. So it's more like an advanced auto-complete than anything. I still know how to do it, and could have done it (albeit slower) with my own fingers.
Can a junior use this method and grow into a senior?
What made you a senior, from a junior? Countless failed attempts. Exploring both the right and the wrong paths, banging your head against the wall, experiencing along years how certain solutions, looking appealing at first, hid pitfalls only surfacing in the long run. Falling in love with design patterns and overusing them, then learning that simplicity is the ultimate sophistication. Then balancing the pros and cons of OOP and FP, questioning your believes, going outside your comfort zone.
Call me old styled but I think the key to learning is the journey, not the Right Solutions we encounter. Thinking we can learn just by looking at solutions, completely skipping the thought process that produced them is an illusion.
Since programming is like to solving quizzes and math problems, a metaphor I like is the detective novel.
Every crime book presents a set of clues, a detective's line of reasoning, and the solution.
Read sandwich-style, any criminal case is trivial: it's easy to check whether the solution holds up with the clues, without ever touching the middle of the book. I could "review" thousands of plots and determine if they make sense. But this wouldn't help me become a good detective. Show me a new case, and never having worked through the reasoning, I'd be completely helpless. An eternal junior detective.
Similarly, I can easily tell if a film is good, but does this make me a good film director? I promise I can tell if my son plays basketball better or worse than Michael Jordan. With enough time and effort I could be a professional "basketball players reviewer". So what?
How can we think that a junior detective/director/player/programmer becomes a senior one by only reviewing someone else's work, by only eating the outer parts of sandwiches?
This seems to work well for me. The review part is essential and a great feedback loop. I might be tempted to hand-wave this part through, but if a reviewer smells unchecked AI-generated changes they won't go easy on me (I know I won't if I'm the reviewer), so I quickly learn to be thorough here.
I like this framework, and I tried to work this way myself. The problem is that the workload keeps increasing. As companies expect more and more output, you start cutting corners to keep up. First you skip the initial thinking, or the final review. Then, gradually, you drop both. Before you know it, you're just passing work to an AI agent and shipping whatever comes back. And the scary part is how easily this becomes your default way of working.
I'm a senior engineer with over 15 years of experience, and I've noticed this happening to myself. We're increasingly expected to churn through work that used to be done by juniors, on top of our existing responsibilities. The pressure to deliver makes it difficult to protect the time needed to actually think. I can feel my own critical thinking getting rusty, and it takes deliberate effort not to fall into the convenience of letting AI do everything.
One thing I've changed is that I now prefer faster models that allow for quick back-and-forth interaction. That way, I'm still actively involved in the problem-solving process. With the larger, slower models, I found myself submitting a task, going for coffee, coming back to a completed implementation, and thinking, "Well, that looks good enough, let's ship it." I was slowly removing myself from the process.
And if I have to consciously fight against this after 15 years of experience, I genuinely struggle to imagine how a junior engineer is supposed to develop the judgment and critical thinking needed to become a senior in this environment.
The Brain Sandwich is a good principle, but it also requires an environment where engineers have the time and space to actually follow it.