The Garden of Code

Chris Zhou, 2022-06-24

About

I discovered many of the following thoughts through gardening and they continue to influence the way I think and code.

Origins

I cannot remember how exactly I came to enjoy gardening, but I knew prior to the hobby, a past coworker and friend replied the following when I asked about his philosophy and approach on coding:

I like to think of myself as a gardener tending to a garden of code. -- Satmeet

Satmeet is no longer with us, but this is a tribute to him on the origins for the thoughts that follow in this document.

Context

The following are gardening concepts mapped to their coding concepts (emphasized).

garden: code
gardener: coder
gardening: coding
flowers: desirable subsets of code
trees: code created over a longer period of time
weeds: software entropy/complexity
bugs: bugs
Nature: left as an open interpretation

Concepts Explored

Understand conditions vs causes as drivers for observed effects.
Undestand open vs closed systems.
Rethink negative concepts e.g. (complexity, entropy, bugs).
Rethink absolute vs relative time.
Systems and subsystems
"When others consists of beliefs, I consist of doubts. -- Zdzisław Beksiński"

One is nearer God's heart in a garden than anywhere else on earth. -- Dorothy Frances Gurney

The word God is left as an open interpretation e.g. God, Nature, Universe, Self, Truth, Beauty
Gardens are at the heart of many spiritual teachings e.g. The Garden of Eden in the Bible, The Seeds of the Mind in Buddhism.

The main elements of gardening: plants, water, sunlight, time, the gardener.

A garden is a closed system of plants, interacting with an open system of water/sunlight, and develops over time, under the care of the gardener.
Code is a closed system of data and algorithms, interacting with an open system of APIs, and develops over time, under the care of the coder.

Seek to forge, and not force.

If one seeks to force a look for their garden, one will only be disappointed as the garden inevitably changes over time.
A forced garden is unnatural while a forged garden is natural.
One needs to adapt and forge the garden based on changing conditions instead of being forced to keep the garden based on initial conditions.
Forge your code and be mindful that initial implementations tend to be "forced" based on initial conditions (specs) which will likely change over time.
Instead of only considering clean/clear code construction and best practices in current time-scope, consider how the code is could evolve across time and people in a larger time-scope.

Focus on conditions, not on causes.

Causality is a powerful mode of thinking, but it is only effective in closed systems. When a system is no longer closed, arguments of casuality fail and arguments of conditions become more powerful.
The tree is unable to grow because the conditions are not ideal (e.g. climate, water, sunlight)
When conditions improve, the tree grows. Similarly, when conditions change, the weeds grows.
The bug exists NOT because of a simple cause at a specific point in time (even if one can be provided). It likely exists because the non-ideal conditions over a PERIOD of time prevented observing/understanding/resolving the bug AND relating systems.
Coding conditions is not limited to just the quality of code. Coding/developer experience, non-coding business processes, XFN communication, effectively drafting/evolving/broadcasting specs and ideas all contribute to conditions.

The state of a tree reflects its history of conditions.

A healthy tree under good conditions grows tall with rich foilage.
A struggling tree under poor conditions grows thin with few leaves.
A pruned tree under varying conditions grows based on the actions of the gardener.
git history is a very useful way to observe conditions and health of code. Code that is stale maybe problematic but it also maybe a good sign that existing APIs are stable.

The trees will outlive you.

This is a powerful insight if your point of view of lifecycles is different. Trees are long-lived and the garden you create will outlive you.
The codebase will outlive you. Do not be overly attached to a specific implementation detail. Focus on the broader scope of things.

The weeds will outlive you.

Weeds are short-lived but the recurrence of weeds is eternal.
Every year, thousands of buried weed seeds re-energize and thousands of new wind-swept weed seeds are brought into the garden.
It is common to find solutions that destroy weeds effectively in the short-term, but they will always outlive you. If one destroys weeds with weedkiller or weed fabric, new problems are created in the future. The soil is poisoned or calcified respectively.
Software entropy and complexity will always exist. There is no magic solution out of this. One should not re-invent the wheel but one should be mindful on overly-relying on vendors. For example, the over-reliance of npm packages in JS development creates new problems from such problem-solving.

The garden reflects a balance of energy. The gardener is the balancer.

Weeds represent negative energy, eagerly ready to overpower the garden.
Flowers and trees represent positive energy.
The gardener balances the energy of the garden, by expending one's own energy, to deal with negative-energy weeds while growing positive-energy plants in their place.
If the coder finds bugs and complexity in the codebase but does nothing, then the bugs and weeds are in plain sight. Their negative energies will overpower the code very soon. The coder needs to expend and balance priorities and strategize to address the problem.

The weed is the flower, and the flower is the weed.

When weeds die, they become soil and nutrients for other plants to grow.
When other plants die, they create opportunities for weeds to set in.
Problems are a source of opportunities and opportunities can degrade to problems.
As the coder codes, one creates entropy ("Software" Law of Thermodynamics)
Bugs and complexity expose gaps in the system that the coder is not aware about, and there is an opportunity to improve the state of code.

There is a cycle and order to everything.

Understand the cycles to understand its blessings and curses.
When there is heavy rain, mosquitos begin their life cycle. They disappear when the garden dries up.
When there is new sod and rain, earthworms and beetles spring to life. Their castings fuel the health of plants. They die fast when the garden dries up.
When bugs multiply, you will notice birds visiting the garden. They sing and leave when the bugs dwindle.
The cycles occur with or without the gardener's presence.
There is an obvious cycle of developing code, addressing and resolving bugs, enjoying a period of stability/equilibrium before the cycle starts again. If one is aware of the short and long cycles, one will be less surprised by the onset of various cycles.

The garden is not a closed system.

It is common to initially create a garden as a closed system of plants.
The garden is exposed to an open system i.e. Nature. This system brings both positive energies (rain, sunlight) and negative energies (weed seeds).
The code is a closed system by design but true stateless (closed) systems do not exist and side effects exist.
Even if one achieves a perfectly closed coding system, the system is still open because coders are free-willed (open) beings.
Do not simply trust specs as absolute truths, because they are only at best relative truths in different points in time.

The garden itself is meaningless, and it is given meaning through the process of gardening.

A garden is objectively a closed system of plants. It exists with or without observers.
The gardening process involves meaningfully tending to the closed system, with subjective decisions performed by the gardener.
Code itself is meaningless. A machine could construct it if instructions were perfectly machinized. Coding itself is meaningful, as the coder is creating code with others addressing a specific problem for specific audiences at specific times.

Nature is the silent teacher when the gardener is eager to learn.

Trees and plants do not speak, smile, or feel.
Yet all these personal thoughts are formed by observing Nature while working in the garden, understanding the nature of things and why things work or fail, and drawing parallel lessons in live.
The coding ecosystem is the silent teacher if the coder is eager to learn. One learns from literatures of code, or from coders, or during the coding process of designing/writing/discussing/reviewing code.

A garden is a stabilizing equilibrium.

Things take time to settle and stabilize.
A garden forges itself over time. Plants grow denser. Rocks are painted with dirt and moss. Trees grow taller. Insects destroy or pollinate the garden. Birds and animals settle in the garden.
Good software ideally stabilizes. Its APIs are well-defined and nothing more needs to be done. The goal is to arrive to stabilized code. For larger softwares, codesplit and stablize well-defined areas of subcode.

Life is everywhere.

From the moss, to the grass, to the trees.
From the aphlids, to the aphids, to the ants, to the spiders.
From the dead matter, to the worms, to the bacteria.
Instead of only valuing beautiful masterworks of code, appreciate all aspects of code/coding/coders. Even redundant/duplicated code that has been in stable use for long periods of time plays an important role to the general health of code. Overly abstracted code reduces complexity but not neccessarily entropy (an increased cognitive cost for coders exists).

Wonderous beauty born from simplicity.

From a single seed, a tree slowly grows needing just water and sunlight.
From a single tree, an ecosystem of insects and birds spring up.
Coders wield the abstract powers of Intelligent Designers in the digital world. We can create and destroy software at will. Yet, it is a difficult goal to arrive to a "simple seed that creates a wide diversity of features with good failure mechanisms".

The gardener shapes the garden and the garden shapes the gardener.

Most people understand that a gardener shapes the garden, but the evolving garden shapes the gardener's evolving thoughts and actions.
The coder shapes the code and the code shapes the coder.

Nature is both the Garden and the Gardener.

A garden is a closed system open to Nature, being shaped by a gardener.
Nature is the enclosing open system and is both the Garden of gardens, and is the Gardener that tends to itself and provides for all other gardens.
In a codebase, the coder may forget that larger patterns of code exist. Avoid being stuck in the domain without context of the broader system. E.g. ReactJS/Vue/AngularJS are great JS frameworks, but they all belong fundamentally to the JS Garden of Code

Code Gardens

This presentation is written entirely in Markdown (CommonMark).

It is presented using md-slides (a hacked POC) utilizing the following microlibraries:

These libraries have influenced ideas in this presentation, and also have been continuously refined by the ideas in this presentation.

They represent the "simple seeds" for the coding gardens of UI systems and document APIs respectively. They are also gardens of code, and belong to larger gardens of code (uinix-js and unifiedjs respectively).

Questions

Interested in gardening? Join #fun-plants
Interested in uinix-ui? Check out EDS!
Interested in unified-doc? A future tech talk is planned!
Interested in md-slides? A beta release is planned after having a lot of fun hacking it up.

chrisrzhou/the-garden-of-code.md