Never and Always mean “right now”

I have this saying that I learned from dating in high school and college:

In love and anger, ‘never’ and ‘always’ mean ‘right now.’

When in love, there is a feeling of “I will always love you” and sometimes “I could never be with anyone else.”

Cuddled up to a lover, there is a feeling of “I never want to move.”

These remind me of the flow of action in probability spaces shaped by intentions (from Dynamics in Action). When I have an intention (to stay right here) and no intention of changing it, then that intention stretches out into forever.

It’s a great feeling, because the moment feels like eternity.

It doesn’t say anything about eternity or the rest of my life. It says something about the purity of my intentions right now.

Action is a process. Reasons matter.

Knowledge work has to be done for the right reason to be done well.

If I choose to implement a feature because I’ll get some reward for it, like a gold star on my next review, then I will implement it far enough to check the box. I won’t get it smooth, or optimal. I will optimize the wrong parts or not at all.

If I implement that feature because I believe it’s the next thing I can do to improve our customer’s experience, then I’ll get optimize for that experience. I’ll make all the tiny decisions with that in mind. I’ll check whether I’ve slowed the site down, or interfered with other features, or cluttered the interface.

Creation is a process, not a transaction.

We are guided throughout that process by an intention. If that intention is to check a box, we’ll check the box, and leave the rest of the system to fall as it will.

In Dynamics in Action, Alicia Juarrero models human action as a process: we start with an intention, which shapes the probability space of what we do next. We do something, and then we check the results against our intention, and then we respond to difference.

Action is a process, not an atomic motion.

Development is action, and it is knowledge work not hand work. To do it well, to shape the system we work in and work on, we line our intentions up with the goals of the system. Not with some external reward or punishment. Intention shapes action, over time, in response to feedback. Reasons matter.

Respond to input? No, we create it

Naturally intelligent systems do not passively await sensory stimulation.


They are constantly active, trying to predict (and actively elicit) the streams of sensory information before they arrive…. Systems like that are already (pretty much constantly) poised to act.


We act for the the evolving streams of sensory information that keep us viable and serve our ends… perception and action in a circular causal flow.

Andy Clark, Surfing Uncertainty

This book is about how human brains perceive based on predictions and prediction errors. I used to think we take in light from our eyes, assemble all that into objects that we perceive, and then respond to those perceptions. But it’s different: we are always guessing at what we expect to perceive, breaking that down into objects and then into expected light levels, and then processing only differences from us that expectation. We turn that into possibilities for our next action.

We don’t sit around waiting to notice something and then respond! We’re always predicting, and then thinking what would we like to see or explore next, and then acting toward that imagined reality.

Teams are intelligent systems like this too. Development teams (symmathesies) operating software in production have expectations of what it should be outputting. We are constantly developing better visibility, and stronger expectations. Then we want that output (data, usage volume) to change, so we take action on the software.

Teams and developers, as intelligent systems in conjunction with software, need to choose our own actions. Acting and perceiving are interlinked. Some of that perception is from the higher levels of organization, like: what does our company want to accomplish? What are people asking us to change? But in the end we have to act in ways we choose, and look for differences in what we perceive, to learn and grow.

Notice that “act as I choose” is very different from “do what I want” or worse, “do what I feel like doing” (which rarely corresponds to what will make me happy). I choose what to do based on input from people and systems around me, according to what might be useful for the team and organization and world.

If my boss wants something done in the code, they’d better convince me that it’s worth doing. Because only if I understand the real “why” can I predict what success looks like, and then I can make the million big and tiny decisions that are the work of software development. Does memory use matter? What is permanent API and what internal? Which off-happy-path cases are crucial, and how can I make the rest fall back safely? Where should this new function or service live?

If I choose to do the work only because they said to, only so that I can check off a box, I am not gonna make these umpteen decisions in ways that serve future-us.

Our job is making choices. We need to the background and understanding to choose our high-level work, so that we can make skillful choices at the low levels.

Intelligent systems don’t wait around to be told what to do. We are constantly looking for the next input that we like better, and creating that input. Act in order to perceive in order to act. This is living.

Mission Statement

“Code, as a medium, is unlike anything humans have worked with before. You can almost design right into it.”

me, in my Camerata keynote


But not totally, because we always find surprises. Complex systems are always full of surprises. That is their frustration and their beauty. 

We live in complex systems. From biology up through cultures and nations and economies, we breathe complexity. And yet in school we learned science as reductive.’

In software, we now have seriously complex systems that we can play with on a time scale that helps us learn. We have incidents we can learn from, with many clues to the real events, to the rich causalities, and sometimes we can trace those back to social pressures in the human half of our software systems. What is more, we can introduce new clues. We can add tracing, and we can make better tools that help the humans (and also provide a trail of what we did). So we have access to complex systems that are (1) malleable and (2) observable. 

My work in automating delivery increases that malleability. My speaking about collaborative automation aims to increase observability.

My quest is: as people, let’s create software systems that are complex and malleable and observable enough that we learn how to work with and within complex systems. That we develop instincts and sciences to change systems from the inside, in ways that benefit the whole system as well as ourselves. And that we apply that learning to the systems we live and breathe in: biology, ecology, economy, culture.

That’s my mission as a symmathecist.

Open Source needs Open Source companies.

The other day, AWS announced its latest plans to work around the license of ElasticSearch, a very useful open source project cared for by Elastic.

“At AWS, we believe that maintainers of an open source project have a responsibility to ensure that the primary open source distribution… does not advantage any one company over another. “

Can I call BS on this?

I mean, I’m sure AWS does believe that, because it’s in their interest. But not because it’s true.

Great pieces of software are not made of code alone. They’re made of code, which is alive in the mental models of people, who deeply understand this software and its place in the wider world. These people can change the software, keep it working, keep it safe, keep it relevant, and grow it as the growing world needs.

These people aren’t part-time, volunteer hobbyists. They’re dedicated to this project, not to a megacorporation. And they eat, and they have healthcare.

Reusable software is not made of code alone. It includes careful APIs, with documentation, and of communication lines. The wider world has to hear about the software, understand its purpose, and then contribute feedback about problems and needs. These essential lines of communication are known as marketing, developer relations, sales, and customer service.

Useful software comes out of a healthy sociotechnical system. It comes out of a company.

If a scrappy, dedicated company like Elastic has a license that leans customers toward paying for the services that keep ElasticSearch growing, secure, and relevant — great! This benefits everyone.

Poor AWS, complaining that it doesn’t have quite enough advantages over smaller, specialized software companies.

Then the next sentence: “This was part of the promise the maintainer made when they gained developers’ trust to adopt the software.” Leaving aside the BS that a person who gives away software owes anyone anything —

The best thing a maintainer can do for the future of all the adopters is to keep the software healthy. That means watching over the sociotechnical system, and that means building a company around it. A giant company fighting against that is not on the side of open source.

CSS Positioning: a summary

I’ve been frustrated every time I try to grasp CSS for years. “I just want this on the left and this to be over here!” etc. Now I realize that CSS doesn’t work that way for very good reasons. In most programming, we give instructions for what we want to happen. But in CSS, it’s more like we are describing a situation — relationships — and then letting the browser figure it out. That’s because the browser has to handle many different circumstances. Resolutions, interfaces, font sizes. I describe how the parts go together, it figures out how to put them on the screen.

When I get upset about the properties for one part being dependent on the properties of its parent containers and siblings, it’s OK Jess: remember that CSS is about interrelationships, so this is normal.

Having got that, I’m now able to learn about how to put things on the screen without yelling in frustration and confusion.

So far, I’ve looked up the position property and learned that it doesn’t do much. There are other ones like display that seem more important. But meanwhile here’s my executive summary:

The position property determines two things: whether the element participates in document flow, and what the properties top bottom left right do. These are the useful ones:

position: static – the default. Stay in document flow; top bottom left right do nothing.

position: relative – nudge. Stay in document flow.  top bottom left right nudge the element in that direction from where it would have been. This also has some effect on child element positioning, at least in the case of ::before pseudo-elements (weird CSS tricks).

position: absolute – override. Remove the element from document flow. top bottom left right tell it where exactly where to be within the document (or within the next absolutely-positioned element up the tree).

position: fixed – override and hold weirdly still. Remove the element from document flow
tell it exactly where to be within the viewport. That means within the browser window (or the iframe if it’s in one). When the page scrolls, this element stays in the same place. People use this for menus.

Please lmk if you have corrections.

Growth Loops: circular causality is real

A few hundred years ago, we decided that circular causality was a logical fallacy. All causes are linear. If something moves, then something else pushed it. If you want to see why, you have to look smaller; all forces derive from microscopic forces.

Yet as a human, I see circular causality everywhere.

  • autocatalytic loops in biology
  • self-reinforcing systems (few women enter or stay in tech because there are few women in tech)
  • romantic infatuation (he likes me, that feels good, I like him, that feels good to him, he likes me 🔄)
  • self-fulfilling prophecies (I expect to fail, so I probably will 🔄)
  • self-regulating systems (such as language)
  • cohesive groups (we help out family, then we feel more bonded, then we help out 🔄)
  • downward spirals (he’s on drugs, so we don’t talk to him, so he is isolated, so he does drugs 🔄)
  • virtuous cycles (it’s easier to make money when you have money 🔄)

These are not illusory. Circular causalities are strong forces in our lives. The systems we live in are self-perpetuating — otherwise they wouldn’t stay around. The circle may be initiated by some historical accident (like biological advantage in the first days of agriculture), but the reason it stays true is circular.

Family therapy recognizes this. (In the “soft” sciences you’re allowed to talk about what’s right in front of you but can’t be derived from atomic forces 😛.) When I have a bad day and snip at my spouse, he withdraws a bit; this hurts our connection, so I’m more likely to snip at him 🔄. When I wonder if my kid is hiding something, I snoop around; she sees this as an invasion of privacy, she starts hiding things 🔄. When my partner tells me something that bothers him, and I say “thank you for expressing that” and then change it, next time he’ll tell me earlier, and it’ll be easier to hear and fix 🔄.

Note that nobody is forcing anyone to do anything. This kind of causality acts on propensities, on likelihoods. We still have free will, but it takes more work to overcome tendencies that are built into us by these interactions.

Or at work: When I think a coworker doesn’t respect me, I make sarcastic remarks; each time he respects me less 🔄. As a team, when we learn together and accomplish something, we feel a sense of belonging; this leads us to feel safe, which makes it easier to learn together and accomplish more 🔄.

Some of these cycles are merely self-sustaining. Many spiral us further and further in a particular direction. These are growth loops, which Kent Beck describes: “the more it grows, the easier it is to grow more.” There is power for us in setting up, nourishing, or thwarting our own cycles. Growth loops are more powerful than individual, discrete incentives. The most supportive families, the most productive teams have them.

Because a growth loop moves a system in a particular direction, it’s more of a spiral than a circle. I want to draw a z-axis through it. Like snipping at my spouse:

a spiral toward disconnection, of me getting snippy and him getting sarcastic

As my spouse and I get snippy with each other, we spiral toward disconnection. When we talk early and welcome gentle feedback, we spiral toward connection. Whereas, when my team bonds and accomplishes things, we spiral toward belonging — with a side effect of accomplishments.

a spiral toward connection, of a team learning together and accomplishing stuff and bonding

I like to use this to explain why JavaScript is the most important programming language. It might be an inferior language by objective standards, but “objective standards” are like linear causality: limited. Reality is richer.

JavaScript started by being the first runtime built into the browser. This made it useful enough for people to learn it, and that’s key: a language is only useful if the know-how of using it is alive inside people. Then all these people create tools, resources, and businesses that make JavaScript more useful 🔄.

a spiral toward usefulness, from the first runtime to people learning and language improvements and tooling

Call this “the network effect” if you want to; network effects are one form of growth loop.

In our situation, JavaScript is the most useful language and it’s only getting more useful. It may not have the best syntax, or the best guarantees. It does have the runtime available to the most humans, the broadest community and a huge ecosystem. Thanks to all the web-based learning resources, it is also the most accessible language to learn.

When I start looking for these growth loops, I see them everywhere, even inside my head. I’m low on sleep, so I’m tired, so I don’t exercise, so I sleep poorly, so I’m tired 🔄. I’m not sleeping, so I get mad at myself for being awake, which is agitating and makes it harder to sleep 🔄. Once I recognize these, I can intervene. I notice that what I feel like doing and what will make me happy are not the same things. I step back from my emotions and feel compassion for myself and then let them go instead of feeding them. I stop negative loops and nourish positive ones.

Circular causality is real, and it powerful. In biology, in our lives, and in our teams, it feels stronger than linear causality; it can override individual competition and incentives. It forms ecosystems and symmathesies and cultures. Linear causality is valuable to understand, because its consequences are universal, while every loop is contextual. But can we stop talking like the only legitimate explanations start from atoms? We influence each other at every level of systems. Circular causality is familiar to us. I want to get better at seeing this and harvesting it in my work.

Your Goals Are Holding You Back

“Enter your concrete goals for the next six months.” This software is supposed to help your career. Seriously?

If the best I can do is something I could name six months ago, I am not learning anything. If I hit some metric, what did I ignore or sacrifice to get there?

Knowledge work is about learning. Maybe I set a concrete goal for today “Complete these three tasks” — chances are good I’ll learn about a fourth one that is more valuable than any of those. If I’m good at my job, I’ll do that, and let some of the three languish. Is that gonna get me a mediocre review at the end of the period? If I’m really good at my job, I will ignore that.

I do need direction, a quest. But concretely, I want to look only at the next step in that direction. Once that is complete, it’s time to look up and say, “Did this help? What looks like it would help next?”

I do need indicators of whether I’m accomplishing my mission. Metrics are useful as clues, but not as absolute measures. If I maximized this metric, what did I damage in the process? I want to detect progress, not pretend that I can measure it precisely.

What is my quest for the next six months? Now that’s a useful question. Start with the company’s mission, and ask, what is my contribution? Maybe your company does heat treatment (running metal parts through furnaces to harden them), and your mission is to

become one of the leading companies in the heat treating industry by fulfilling a simple, fundamental promise:

We’re here to help you succeed and to help you reveal the true strength in your most important parts and components.

Maybe you’re a metallurgist there, and your part is “to help customers succeed by participating in process design and material selection.” We can help prioritization with some emphasis: “… especially customers who do a lot of business with us. Especially business-crucial parts. Especially automotive parts; pass aerospace to Lindsey. Especially hardening; consult on Mark for coating. Especially aluminum, as we want more business in that.” (I’m making this up.) This is the part you want to update every six months. Then every few weeks, review open tasks for priority. Every day, answer phone calls and serve the customer needs of the moment.

Every moment, learn. Learn about customer needs, learn about furnaces and metal and what the company can do. Respond to that. Measure outcomes (customer satisfaction, revenue per customer), but evaluate decisions based on information you had at the time.

There is no good way to use concrete-goal-setting software. The best you can do is subvert it, ignore it, or compare goals to actual work and say “wow, we sure learned stuff in the last six months.” There’s a reason the best task-trackers are post-its: because they fall down. Set direction every six months, not concrete goals.

Shared Values are Overrated

The other day, I heard a story about a leadership retreat where the goal was to agree upon shared values. They held a vote, and lo, there was an even split between all the values. The group could not agree on which ones represented the company.

This makes sense. Our values are part of our identity. You can’t compromise on your values! That would make you a bad person!

How can we come together, then? Must we fire half the leadership and replace them with people willing to espouse the same values as the remaining half? or can we settle for mutual purpose, and go with a mission statement?

Values

Corporate values are mostly generic. Honesty, integrity, innovation, teamwork, quality, respect, empathy. What do those even mean in the course of a workday?

To communicate that, you need to give examples of how a value is expressed in the workplace. For example:

  • Integrity: we do what we say we will do. When this becomes impossible, we communicate clearly and promptly with the people affected.
  • Honesty: we contribute our knowledge, especially about the limitations of our knowledge. We thank other people when they bring us surprising information, especially when it is bad news.
  • Innovation: we spend 80% of our time working within the system we have, and 20% of our work time improving the system we work in.
  • Collegiality: when we have disagreements, we resolve them peer-to-peer, not by appealing to higher management.

Agreed-upon Methods

Once we’ve expressed what we mean with implementation strategies, let’s strike out the names of the value and call the list “agreed-upon methods.”

See, people can’t compromise on values. But we can compromise on methods.

As itriskmanager describes it:

“When they become a team, they do not necessarily expect everyone to adopt the same values and beliefs. In fact, they grow to value and respect the values and beliefs of the other people in the team.”

When we already share a common purpose — success in the company’s mission — we need to agree on how we will accomplish that. We need protocols to coordinate work and encourage dialog. But we don’t need to all emphasize the same basic human values. In fact, balance can help.

That’s why I think we should replace “shared values” with something that doesn’t smack of morality. Something like: mutual purpose and agreed-upon methods.