Mental Models, Programming Fictions, and Wittgenstein

This is a follow-up essay to my previous one about <a href="https://vojtechtuma.medium.com/debuggers-and-empathy-ec7d0a976436" rel="noopener">Empathy and Debuggers</a>, where I confessed to my preference for empathically understanding the code rather than for line-oriented debugging. Here, I would like to expand that slightly mystic notion of empathic understanding with a more exact one of mental models and share a few tips on how I build and update them. <h1>Mental Models for Fixing Bugs</h1> Troubleshooting why an alert has appeared, why tests started to fail after you did a change, why a command is failing for your colleague yet works for you — those are very often solved by one small change at a single place, and the difficulty lies in finding that place and that change. My usual strategy to find it is to consult the mental model I have for the pipeline/code/command in question: <ul> <li>What should be the behaviour under given circumstances?</li> <li>What circumstances would lead to the observed behaviour?</li> </ul> I don’t usually have an answer for both questions — one is sufficient. The first question leads to an iteration — if the behaviour suggested by my model does not agree with reality, I suspect a bug in the code. I decompose the pipeline/code/command into smaller pieces, each with its own, more detailed model, and repeat the procedure for those until I find the misbehaving one(s). Eventually, I get to the point where I just directly compare the model with the code, ideally a few lines at this stage, and identify the culprit. The second question, on the other hand, suggests that the bug is in the parameters the user provided, in the external response, in the infrastructure, etc. So I instead move away to the parameters/external service/infrastructure and investigate them. <a href="https://betterprogramming.pub/mental-models-programming-fictions-and-wittgenstein-d97f1c849df2">Website</a>