Soft, or hard like mud

Soft skills are hard. “They take work to build and work to apply.”

@ruthmalan

The word “hard” describes sciences like physics and chemistry. It is confusing that “hard” can mean difficult, because these sciences aren’t more difficult than the “soft” ones like sociology and anthropology. They’re differently difficult.

The “hard” sciences are hard because they’re solid. We can stand on them. Physical laws are universal laws. They demand rigor, and rigor means proving that assertions apply in all cases, both through deduction and by checking against evidence.

The “soft” sciences are differently hard. They study humans systems, far too complex to make universal causal predictions. Conclusions about one culture or group are valid in some other groups and invalid in others. Rigor in complexity means studying which cases your assertions apply to. It means observing, discerning, and wallowing in context.

I describe my career progression from solving puzzles to growing products like this:

Correctness, puzzles, and the “hard” sciences are hard like rocks. Rock climbing is very technical. It takes a lot of skill and strength and hard work to climb. At the top of the cliff, you know you’ve achieved something specific.

Change, people, and the “soft” sciences are hard like mud. Like wading through goopy mud. Techniques can help, but each depends on the kind of mud. Strength helps, but pushing too hard can get you more stuck. It always helps to be okay with getting messy. When you finally reach that piece of relatively solid ground, the view is still a swamp.

Why would you want to wade through mud?

why does a fish want to swim through water?

People, interrelationships, change — this is our world. Sometimes we can carve out puzzles we can solve for real. The few universal laws we can find are priceless. But the rest of it — life is in the mud, in the deep context. The skills to navigate it are not easy. They are not satisfying in the same way, either. But they are how we find meaning, how we participate in a system bigger than our own self.

I am okay with getting messy.

Knowledge resides in teams

The magic of a gelled team is that they know how to work together, and together, they know how to do particular work. The members don’t know how to work together; the team does.

These learnings don’t reside in the members individually, the learnings are in the interrelations.

A shared know-how is jointly constructed between the participants. This shared know-how does not amount to the sum of the individuals’ know-hows nor does it strictly “belong” to any of the participants…. It involves instead the practice of coordinating sensorimotor schemes together, navigating breakdowns, and it belongs to the system the participants bring forth together: the dyad, the group, the family, the community, and so on.

“Linguistic Bodies The Continuity between Life and Language” Ezequiel A. Di
Paolo, Elena Clare Cuffari, and Hanne De Jaegher, quoted by @theblub

If you’re a director who gets to decide which teams stay together and which break apart, you have a lot of power — and very little control. Power can bust up symmathesies, but not build them or repair them. Other levels of hierarchy can set up conditions for success, but teams grow from within.

Leaving a company is scary because we know how to be in that company. Our own knowing-how-to-be exists partly in our interrelations there. Finding a new job means discovering a new way, a new self, to be in the new place. With families, even more so – this is part of what makes divorce so scary. If you’re in an unhealthy system and can’t imagine anything else, this is normal.

When you do get to be part of a healthy team, or a healthy family, appreciate it. Cherish it and nourish it.

Feature interaction

Why is legacy software so much harder to work in?

Why does development velocity slow down as a system grows?

Lots of reasons, sure, but I suspect the biggest one is oft unspoken.

Every new feature comes with the invisible requirement: “and everything else still works.”

Every existing feature, and even past bugs, makes every new feature harder. Every user with expectations is a drag on change.

Feature interactions are hard! And they surprise you. My favorite examples come from The Sims release notes:

  • Fish are no longer duplicated in the fridge when moving homes.
  • Televisions no longer play video after they are burned or broken.
  • Sims will no longer walk on water to view paintings placed on swimming pool walls.
  • Pianists will no longer continue playing pianos that have been detonated.
  • Sims will no longer receive a wish to “Skinny Dip” with Mummies.
  • Sims who are on fire will no longer be forced to attend graduation before they can put themselves out.
  • Sims can no longer “Try for Baby” with the Grim Reaper.

Your feature interactions are probably not this much fun.

Software gets harder to change as it becomes part of a larger system, with more users and more uses. Development slows down because it’s useful, and we want it to stay useful. This also makes each change more valuable, because it’s helping more people in more ways.

Don’t be discouraged. Do be diligent, and be okay with being slower. This is the price of success.

Teams are like bread

Maybe when companies make you do “team-building” activities, what they’re looking for is a phase transition into a gelled team. Because it is a sudden, magical thing, right? When a group of people turns into a team.

Once you get there, to that feeling of team, it’s self-reinforcing. You trust each other, so y0u don’t take miscommunications personally; you work to restore communication, and so trust increases. You understand each other, so it’s easy to build further understanding. Working together gets smoother and smoother.

But how do you get there? pfft. How do you make sourdough bread? You grow it from sourdough starter, which you got from … someone else’s starter. Or from putting sugar water out on a windowsill and hoping some yeast lands in it. Seriously.

Will Larson suggests that when you have a gelled team, keep it. If you need to adjust how many people are helping with which pieces of software, then shift responsibilities from one team to another, not people.

When you have a gelled team, you can grow it gradually. Let the team reform with the new member incorporated before adding another.

Will suggests that when you want another team, gradually grow a gelled team up to 8-10 (max size) and then fork it into two teams of 4-5 (minimum size). It’s kind of like the sourdough starter: grow it, divide it, make the bread. Keep it alive the whole time.

If you have one team where the magic is flourishing, don’t kill it. Feed it, grow it, and let it be a source of further strong teams. No rushing.

Otherwise – if you take the group to paintball, or get them to mob program, or put them in a team room with sugar and water, maybe the yeast will blow in?

(if you want these little posts as I make them, plus a bit of extra context, sign up for my newsletter!)

Develop before define

First the loose thinking and the building up of a structure on unsound foundations and then the correction to stricter thinking and the substitutions a new underpinning beneath the already constructed mass.

Gregory Bateson on the advance of science. (From Steps to an Ecology of Mind)

This expresses a process I have observed in developers. We can develop something faster than we can define it.

That loose thinking includes the construction of loose code. We think with our fingers and eyes, keyboards and screens, editors and runtimes as well as with our brains. We try things, we draw them out or code them up. This eliminates a lot of impossible paths.

Then afterward, we shore up the useful ones. We put an API around it, error handling within, types throughout. We describe its interface and action in documentation.

Bateson grants permission to code loosely as an extension to thinking loosely, with the responsibility to return with rigor before we rope in other teams.

So do this, play in code the way we play in thought.

Then please realize that putting the foundations under it, defining the functionality so others can use it, is 10-100 times more time-consuming than your happy-path sketch.

When time gets tight, we make it tighter.

What do you think are the personality traits that contribute to being a good mathematician?

Flexibility. A willingness to change course when you see that things should go a different way. The ability to backtrack, and go forward and follow different paths and then come back to where you were. 

Dr Amie Wilkinson

This happens in code, too. When we explore a solution, we need to try one path, then come back and try another. This makes git incredibly valuable, with local branches and reverts.

I see Rod doing this often, when he works on exploring the design space of an API. (Rod is famous for creating the Spring framework for Java.)

If we are rushed, backing up can feel like wasting time. We push forward in directions that are slower. Worse, once someone else is using the API, it takes coordination to change it. That slows all of us down forever.

Yesterday Llewellyn Falco talked about how we tend to be prudent with money, leaving ourselves slack and valuing more-money-in-the-future more than less-money-now.

The multiplier of how much more money we require in the future is called the future discount. If you don’t think you’ll be alive in a month, or that you’ll really get any money at all then, your future discount is zero.

Under pressure, under scarcity, there is a psychological effect that reduces the future discount to zero. Saving money feels utterly pointless. Current needs are too pressing.

Llewellyn pointed out that while developers are prudent with money, they believe in the future, we often aren’t with time. We would not budget every dollar we have for a trip and leave no slack for surprises. But we do with sprints, and then we get under pressure and our future discount invisibly drops to zero and we can’t even think about future us or future whole-company who is stuck with the first design we thought to because backing up is just not an option.

Plow forward slower and slower, because we don’t believe in the future. Or step back and try a few things. Take a breath, take a walk, and maybe you’ll spot a smoother path.

Domain-specific laws

“there appear new laws and even new kinds of laws, which apply in the domain in question.”

David Bohm, quoted by Alicia Juarrero

He’s talking about the qualitative transformation that happens in a system when certain quantitative transition points are passed.

Qualitative transformation

I notice this when something that used to be a pain gets easier, sufficiently easier that I stop thinking about it and just use it. Like git log. There is such a thing as svn log but it’s so slow that I used it once ever in my years of svn. The crucial value in git log is that it’s so fast I can use it over and over again, each time tweaking the output.

  • git log
  • git log --oneline
  • git log --oneline | grep test
  • etc.

Now git log has way more functionality, because I can combine it with other shell commands, because it’s fast enough. This changes the system in more ways than “I use the commit log”: because I use the log, I make more commits with better messages. Now my system history is more informative than it used to be, all since the log command is faster.

The REPL has that effect in many languages. We try stuff all the time instead of thinking about it or looking it up, and as a result we learn faster, which changes the system.

Non-universal laws

I love the part about “laws, which apply in the domain in question.” There are laws of causality which are not universal, which apply only in specific contexts. The entire system history (including all its qualitative transformations) contribute to these contexts, so it’s very hard to generalize these laws even with conditions around them.

But can we study them? Can we observe the context-specific laws that apply on our own team, in our own symmathesy?

Can we each become scientists in the particular world we work in?

A definition of play, and how to live

In games, we choose an objective that has no intrinsic value. Get points, run out of cards, reach the finish line. We take aim, and restricting our actions with rules, because this leads us to actions that we enjoy. Thinking, interacting with other players, running all-out. We play the game because it’s fun. We try to win because that makes it fun. (Some people get happy if they win. But if you don’t enjoy the play, you won’t keep coming back.)

This is play, because the ends don’t have particular value, but the means of getting there give us satisfaction.

We can take this strategy in life too:

Choose the ends that lead you to the means that get you what you need.

I call it a quest, an unreachable star, this aim that we choose not because we expect to get there (that would be a milestone) but because it leads us in useful directions.

The book Obliquity (amazon) explains it well: there are some things we can’t get by aiming for them, such as profit or happiness. So you choose an end (“build the best airplane”) that leads you to means (engineering, research, investment, production quality) that get you what you need in order to keep going (profit). Choose an end (“build up my community”) that leads you to means (forming relationships, organizing, helping people) that get you what you need (joy).

When the end has some intrinsic value of its own, like the airplane, or the community, or operating useful software — then we call it work.

People say “Do what you love.” This is how to do that: find an objective that matters to others, which also leads you to means that bring satisfaction. Some people find hard physical work satisfying, others mental exertion, others human interaction. It doesn’t need to be your favorite activity; fun does not equal joy.

When both the ends and the means are fulfilling, then work and play align.

Each milestone (produce an engine, get someone to like you, code up a feature) has many routes to reach it. If you aim for the quickest route, you might end up messing up your quest (the fastest code is harder to operate) or worse, missing out on what you need (long-term profit is down, the community is poisoned, the work is unsatisfying). How do we restrict our means to the ones that take us toward our quest, not just our milestone? and also give us what we need to keep going?

In games, we use rules. In life, we use values.

Change at different timescales

On recommendation from @mtnygard and others, I have acquired a copy of How Buildings Learn (Stewart Brand, 1994). Highlights so far:

Buildings are designed not to adapt, but they adapt anyway, because the usages are changing constantly. “The idea is crystalline, the fact fluid.” They’re designed not to adapt because “‘Form ever follows function’ … misled a century of architects into believing that they could really anticipate function.”

We think of buildings as static, because they change at a timescale slower than our notice. They change over generations. Humans operate at some natural timescale, and we see things slower as unchanging, and things faster as transient, insignificant. We are uncomfortable with change in stuff we think of as permanent, like buildings or culture or language. It isn’t permanent, just slower than us.

A jar of honey on its side will leak. The lid doesn’t trap the honey, just slows it down. Imperceptible movement is invisible, until the whole cupboard is sticky.

Software’s pace of change can be unnaturally fast, the opposite of buildings. That makes people uncomfortable. Updating buildings, “we deal with decisions taken long ago for remote reasons.” In software, “long ago” might be last year.

As usages change, so must our environs, in brick and in computers.

What changes faster than usages? Fashion. “Buildings are treated by fashion as big, difficult clothing, always lagging embarrassingly behind the mode of the day. This issue has nothing to do with function.” The latest hot tech may not improve on the value of your legacy software. “The meaningless change of fashion often obstructs necessary change.”