Using magical practices to work with large code bases

A large and legacy code base, can sometimes be like a collection of mystical documents, they are riddled with number magic, cryptic references, mysterious rituals and descriptions. Some are are guarded and governed by old masters, that are grumpy and quick to dismiss any newbie asking for access to their code. They answer in muffled mumbling, and are easy to anger.

Also, the habits and customs with which the guardians of the old code work with the code, interpreting it continuously, rewriting it, trying to understand it, very much matches which how I would expect a magical order to be working through old manuscripts trying to recreate ancient rituals.

However, many of the maintainers of old code do not necessarily indulge into this kind of self reflection about their work. They tend to be governed by fear, from failures in their code, from changes in certain “mythical” parts, from confrontation by their superiors, or by the choleric masters of certain rooms. The strategy to deal with those challenges is often a form of rationalizing, which includes denying how emotions and relationships might influence the code. Communication is often channeled into ineffective rituals, including meetings with no results, and throwing around jargon that aims to hide, what needs to be said, because of lack of a common vocabulary. The value of deep and completely open communication in such endeavors is often completely neglected, and there exist no mechanisms to facilitate such communication.

Part of this phenomenons is often a very deep focus within the programming community on “rationality”. The programming community prides itself on its reliance of “facts” is composed largely of atheists, and in general people who keep a high nose, in respect to religious, mystical, esoteric practices. Everything that carries even a scent of “softness”, is immediately thrown into the corner with hocus pocus and fairy tale magicians.

Those prejudices are unfortunate, because some of the techniques of working with mystical and old manuscripts and ancient rituals, might be quite well suited to deal with old and difficult to understand code.
There might be complicated code bases, that deal with legacy functionality and complex algorithms, that are quite well understood by their teams, and those teams might dismiss this quite “esoteric” approach. And maybe for those well oiled and effective teams, it might not make any sense indeed.

However, there are teams, where I believe much healing needs to be done, misunderstand needs to be cleared up, and honesty as well as understanding needs to be fostered. Often this also goes along with a feeling of exhaustedness, mistrust, and aggression. Team members tend to withdraw, and build walls around them. And in such cases, I believe magic practices and experiences might come in useful, to help resolve those situations.

I also believe, that industry practices, which are often described in books and are believed to be easy to apply by practicing the theory often fail to work. Which is because the required self transformation does not take place. Those industry practices often even fail to mention the necessity of transformation, rather the indulge into detailed descriptions of their “rituals” and artifacts. And therefore they fail to create a conscience for spiritual development in the industry.

This actually is a common pitfall of many industrial and developed nations in which the dominant mainstream consciousness is based around the notion of consumerism. The consumer-culture, that often promises happiness and success, to be tied to objects and artifacts that can be bought. Like to better computer, or the faster bicycle, or any kind of more effective product. However, the fact that growth results from discipline and from transformation of the inner self, and not from buying arbitrary artifacts is seldom communicated and highlighted.

Even advice that goes into building teams and software companies always starts at the point of selecting people based on their psychological qualities and their ability to work and communicate together. It start with the notion that some people simple are mature enough to engage in the art, and some are not. Without elaborating on how people, who might not yet have the required maturity might acquire it. It deals more often also with the suggestions of how to remove “poisonous” team members rather than how to inspire them to grow. Sure, some people might effectively work against such efforts and sabotage them, but those that can be reached, should be.

And here comes in what I believe magic (or magick) could do for the development of programming as a craft and art form. Especially, because something that is seen as “wishy-washy” and arbitrary and be members of the programmers community, and especially because it would evoke quite an emotion and foster discussion. In a sense it is a provocation. It would rattly things up.

And therefore it would require quite some questioning and reflection about ones art.

What I failed to mention in this article is mentioning some concrete techniques. This is intentional, and the entire point, what I suggest should not necessarily and even could not be learned by reading an article on the Internet. It should be developed, and learned in communities, by reflection, coaching, mentoring, and self discovery. We are just at the starting point of this journey. How could I know where it ends?

Take care,
Cheers
-Richard