The Hackers Guide to Refactoring Reality

What's with the title?

I am not the guide, and neither is this post itself intended to be. Rather I hope to create a discussion where we may guide each other to greater mindfulness as people and as programmers. As programmers we speak in metaphors, because these lead to greater understanding things that are hard to describe directly. Its all switches and electrons at the end of the day, and so talking of objects is easier.

Mindfulness is very similar, in that what you are describing is so innate and fundamental that we almost constantly overlook it. To call it mindfulness and compassion only goes so far, and we must be more descriptive about the path if we are to walk it. Here is my attempt to use programming metaphors to shape my understanding, and I hope it helps you refactor yours.

Why Be Mindful

Our lives are filled with wonderful moments. For example, as I write this I am sitting in the morning light with my dog at my side, and that is something I treasure on its own. But while I sit and admire this moment — I hum the first bars to a song, so I am also in an another world created by my imagination of the song. So, in the reality of my mind, I am a being both in the world and in a bubble of my own creation.

This dichotomy is not the problem to be solved, as it is a natural way to live. It is helpful however to simply bring attention to the bubbles of reality we occupy. If you had no knowledge of the ground beneath you, you might misstep. So to step more closely to our path in life we can practice being mindful of ourselves and our surroundings.

Being Mindful

Being mindful, in any context, is achieved when we begin to train our awareness towards how we are at this moment, and how things are around us. While the steps that lead towards this momentary awareness are as uncountable as the moments and things that experience them, the start of the path is always close at hand.

Finding that first step, and those that follow — is not so dissimilar to the development of software instructions. We experiment, we error, we fix it, we ship it and own it. This may seem superficial, but in our minds these parallels can lead us to tools we might use to shape ourselves as we would our code.

We are already a great group of software developers, so how might we apply these well honed practices towards developing skills that are helpful outside editors and terminals? Life would be more DRY for the mindful programmer if software development skills were reusable in other contexts.

Examples:

The purpose of this discussion is to experiment with the application of software development skills to improve our mindfulness in real life situations. A tagline for these contextual mashups might be “Apply a hard skill to improve a soft skill”. Some examples:

1. Apply debugging principles to resolving a disagreement over a diff.
2. Apply test driven development to improving communication with team members.
3. Apply domain modeling to writing a concise message to an important recipient.

🐛 Debugging a Disagreement

I'll give one example from my experience, and let you all think about the rest. As developers we follow a process to determine the root cause of a problem starting from its peripheral effects in a system. When confronted with a personal problem, could we apply the same process to go from a problem to a solution?

An example of such a personal problem might be an intractable disagreement over a code change. You’ve written the solution in a particular way, and another developer has left feedback asking you to rewrite the code differently. The ideal in this situation might be to continue to hold separate viewpoints, but let go of your own belief in a practical sense to commit as a team to a single course of action.

Just as we search for a bug fix closest to the root of an issue, letting go is easiest when you have some understanding of the root of your attachment. And, just as the effect of the bug isn’t always immediately indicative of its cause, your immediate reasoning for continuing a disagreement might have more depth and nuance than is immediately obvious. In doing so I've seen that my feelings towards these things are less clear cut than I often think, and there is actually a great deal of space to form agreement!

To find the root of your attachment, begin by enumerating the elements of a situation from your perspective, and identifying how you feel towards them. They may be large like the direction of the product, or as subtle as the tone and delivery of communication around the issue. The right things to choose are simply those that come to mind. If you find something of note, note it! When you feel finished, try again to visualize an agreement. Did you find it?

Conclusion

There really is no conclusion. This is not even my idea actually. It will live as your idea I hope, and you will contribute to this guide more than I could possibly do on my own. Thanks, and happy hacking.