People often ask me whether debugging code has helped me in psychotherapy – and if there’s a similarity between fixing a bug and “debugging” a psychological symptom. At first glance, it sounds tempting to draw parallels: both start from a problem that needs to be understood and resolved. But the truth is: there is no such similarity.
In software engineering, the focus is on the details of a very specific case: a function receives an unexpected parameter and the program crashes. The solution is to validate the input and return an appropriate error. The context is well-defined, the code is static, the logic is predictable.
In psychotherapy, the perspective is different. We are not looking for a quick fix but for the root of the problem – the deep mechanism that underlies not just one symptom but many manifestations in a person’s life. If in programming you ask, “How do I stop this function from crashing?”, in therapy the question becomes, “What changed in the external environment, and why did a mismatch arise between outside expectations and the person’s internal logic?” This is about exploring dynamics, not mechanics.
The analogy of a “breakpoint” can still be useful. In code, you stop execution to trace values. In therapy, a similar moment arises when a patient casually mentions a detail as if it’s insignificant. That’s when the therapist can “pause the process” and direct attention to what was dismissed—often revealing something central to the person’s story.
But here the similarities end. Code can be executed a thousand times and always yield the same result. The psyche is alive and reacts to every intervention. It changes, resists, adapts. This makes the analogy with software misleading: while a programmer seeks repeatability and stability, a therapist enters a process of continuous transformation.
Patients often arrive with the expectation of a “quick fix” – to eliminate the symptom that bothers them. Yet the deeper they go, the more they realize that the true value lies elsewhere. The symptom fades into the background, while much more fundamental questions about meaning, relationships, and personal history move to the forefront.
This way of thinking has also shaped my leadership in technology teams. My therapeutic experience helps me not to feel like a “boss” but as part of the dynamic. I notice what inner processes my colleagues are going through and remind myself that they are not just “resources” for the company. Today someone may be my teammate, tomorrow my manager, and the day after a partner in a joint project. What matters most is the prosperity of the individual, not the organization at the expense of the individual.
That is why I stress: it is dangerous to look at psychotherapy through the rational lens of software engineering. Such a view risks stripping the soul of its depth, turning a person into a robot-like, socially acceptable being but one deprived of creativity and vitality. In programming, this is the desired outcome – structured, predictable, stable code. But who would want to relate to a human being who has become “like code”—boring, predictable, and soulless?