Tension Seeking Resolution (The Law of Polarity)

Before we continue, you can get 25% off the new Testing Mastery: The Best Practice-First Phase (Bachelors Program) using the discount code TESTING-MASTERY before October 31st

--

He holds out a rubber band, expands it until it snaps and says,

“Tension seeking resolution. That’s it. That’s the key. The fundamental principle.”

The instructor’s name was William Whitecloud.

I thought about this lecture for months, which was a testament to the teaching itself.

How it began

After the initial early adopter launch of The Software Essentialist, I was pushing my mind to its limits to produce the initial batch of material for around 300 new students to play with.

Yes, I wanted to do my best work, but I was not pacing myself properly.

My family could feel it.

My now ex girlfriend could feel it.

And much like the rubber band, my mind was going to snap eventually.

And it did.

It felt like I had been hit by a car.

I took a few weeks off to recover, because my body and my mind were clearly telling me to.

When I returned, I studied leadership, self development, psychology, NLP, high performance, and spirituality.

I learned more about myself during that period than any other time in my life.

At some point along my path, I came across an image I hadn’t seen in a long time.

I’m sure you know it.

The yin-yang.

Well that’s profound, I thought.

I printed it out and kept it with me, because I knew there was something aptly important here.

The law of polarity

Upon returning to recording the videos for the first version of what would today become Testing Mastery and Best Practice Phase of Craftship material, I took note that of the fact that my work occurred differently to me.

As I wrote a test, I began to notice something…

When I wrote an empty test, I could feel a sort of tension.

It was different from the psychological tension I experienced writing the code first, full well knowing that I’d be creating a temporary mess to later clean up.

Instead, this tension generated when I wrote an empty test. It seemed to create a vacuum — asking to be collapsed.

A sort of curiosity gap.

You know, because when you write an empty test… when you Program By Wishful Thinking (my favourite Best Practice-First technique), sometimes, you have no idea how you’re going to make that test pass.

And while I’ve always known that half of the work is:

• upfront
• top-down

And the other half, of implementing the working code is:

• emergent
• bottom-up

…this time, instead of just knowing these truths, I understood them.

The Metaphysics

I've observed something about reality: it's cyclical, multi-dimensional, and multi-perspectival.

This will go above 85% of people's heads, but for any sort of long-term success, we really have to dig into this one a fair amount, because as Ray Dahlio says,

Truth - more precisely, an accurate understanding of reality - is the essential foundation for producing good outcomes.

Understand: every time you ask a question, write a test, make a plan, declare an estimate, commit to a new habit, or take on a goal to improve your life… you simultaneously commit to a temporary period of struggle.

You encounter the inevitable tension seeking resolution.

What a beautiful game of chaos and order we get to play.

The art of life.

When expectation meets reality.

To all you magicians who zig the zag and zag the zig.

To Mastery, I say to you.

The way of the middle path

Imagine you're an entrepreneurial developer.

You're ready to go all in again.

So you quit your job with 12 months of savings, you identify a problem in the world that you want to solve, then you start to throw some code at it.

You’re not guarding any of it with tests, but that’s okay. You know how this game goes.

You stack more and more code.

In other words, you stack more and more tension.

Then you get your first customer.

Relief, bliss, and then more tension. Why?

Well, it’s really on now.

You keep on building.

You hear the little voice say, will this little project of mine work?

It seems like it will, because you just got another customer.

Over the following weeks and months of building and refining, you start to notice:

• it’s getting harder to add features
• the code is starting to feel overwhelming
• you have a fear of breaking something in a distant area of the codebase by changing code in another

So what do you do?

Well, you’ve validated your project already.

So now you decide it’s time to cover that ground you’ve trodden with tests.

You know the “right thing to do” would have been to have started with tests, but hey — this wasn’t guaranteed. You had no idea if any of this was going to amount to anything.

If you were in an office and could expect a paycheque every month, you’d have probably taken a different path.

Some BDD and TDD practitioners will tell you to always start with the tests. Every scenario.

But this is a very different game you’ve chosen to play.

It requires a certain type of maturity to know how to keep the balance.

But one thing is for certain: not knowing how to write tests is a lot different from deciding not to.

It's clear that we achieve outcomes in the universe using cycles.

And when you write code, you start the cycle of tension, which can only be closed with a test.

In my eyes, until you learn how to test as well as you can code, you are continually at odds with the law of polarity.

Expect the eventual slingshot of entropy. Expect that your code will come back to bite you.

Because believe me, reality does not discriminate.

My advice then is to learn how to test.

Master it, move on to the next challenges, then play the game of balance only accessible to those who know the rules.

Because nothing in life is perfect.

Seek not perfection. Seek the middle path.

Of wu wei.

Of effortless action.

And dance with tension seeking resolution.

Enjoy your weekend, and as always.

To Mastery

Check out Testing Mastery: The Best Practice-First Phase (Bachelors Program) and get 25% off using the discount code TESTING-MASTERY before October 31st