Our internal compiler
Most developers can master the skill of listening to spoken words quite well. It’s easy to grasp words, run them through the compiler in our mind and spit out instructions. The compiler is based on sub-routines created through our life experiences, ready to give an output based on any input. These sub-routines remove the cognitive burden of weighing and considering each and every spoken word.
We spend our careers learning how to understand communication with compilers, yet struggle to effectively communicate with the people around us. Can we shift our built-in compiler to interpret words and actions in a way that opens us up to more empathic communication?
Request / Response Optimization
Our compilers build in rules naturally as we grow, and each sub-routine becomes more and more specific. The more rules in place, the less brain-cycles needed to give a response.
Every response is a range of thoughts, feelings, understandings, actions and/or words. The more instructions we have in place, the faster we process what we hear and can compile that into actions. These optimizations are what allows us to focus on important tasks like programming.
Imagine having to focus all our energy on reflecting on each word, the meaning of the word, its place in the spoken sentence, the tone of voice. How would we have the mental energy to move past the words and focus on the task of programming a system?
The Danger of Premature Optimization
There is always a chance of optimizing prematurely. Boosting the performance of our listening-interpreter to free up those valuable brain-cycles. The more we optimize, the deeper a sub-routine goes into our compiler. The danger of prematurely optimizing results in bugs, glitches and stack-overflow exceptions. These can be often seen as irrational behavior, prejudices, irritation, anger and sometimes even violence towards others.
Refactoring the Fundamentals
All is not lost though. Through reflection, understanding and questioning the reason an optimization was put in place, we can evolve the architecture of our listening compiler. Sometimes deleting sub-routines is the way to go, other times introducing new sub-routines and refactoring the old into smaller re-usable chunks.
The deeper the sub-routine, the harder it is to refactor. New bugs may be introduced, but the overall system should stabilize over time, allowing for newer, better optimizations.
As with any change, we must be committed to it and not expect revolutions, but rather gradual evolutions. Changing how we interpret others words and actions is possibly the hardest thing to focus on, but has tremendous value. Over time this more empathic, understanding rewiring will become more natural and easier.
Our minds, thoughts, behaviors and actions are quite the same. For a developer to move towards a more empathic view of themselves, family, peers, users, and profession, they need to be open to refactoring themselves. Instead of focusing solely on what we deliver, also focus on why and how.
How do you approach your assumptions? Are understanding and communication valuable skills you spend time on honing?
Please feel free to reach out to me directly if you have any thoughts, questions or criticisms. Or leave a comment below.