Take a moment. Think about it. Turn to your neighbor and tell them.

Boom! It's gone! Now what? Take a moment. Think about it. What would you choose? Tell your neighbor... Why? What makes you want to choose it? But let me introduce myself ...

Last year, I had a heretical idea to ask Clojure developers about other programming languages! On the official survey!

What did they say? Well first, some background. Where did this idea come from?

Over the last 3 years, I've interviewed countless Clojure developers. I get the full backstory that leads to Clojure I noticed a pattern: testing, ops, dev rel, project owner, project manager, even a *manager*! Programmers that tried something else. Even management! Lost their joy. Burnt out on programming. Felt anecdotal. I wanted some data!

Give up programming? Some were surprised by the results or thought it was a joke. I knew better from my interviews. Why give it up?

Actually, some would argue that making software is now easy!

That implies the question...

Well..thank you for coming to my talk. It was a bit shorter than expected...

The answer matters because it's hard to do. We do hard things, but we need a purpose. Example: Marathon Why? We want to feel success, but what are we up against?

surpass what? superior to what?

What do you want to maximize? Manager: prioritize everything! Those managers were not clearly not devs that had quit programming. It depends! No universal “winner”.

Congratulations! You have real problems!

Unbounded change Unbounded uncertainty I learned this as an entrepreneur.

Real-world problem: * Changing conditions * Uncertainty * Limited resources

Fewer resources, at least. Some choices have high impact, others low.

Eg. Functional programming separates values and behavior. Joke: Dysfunctional programming. dis- means "lack of, not", "opposite of", "apart, away" dys- means "bad, ill; hard, difficult; abnormal, imperfect" “When you separate functional from programming? Dis-functional.”

The paradox of change: Making a change, requires making choices, but choices constrain future change. Therefore change constrains change.

World is changing Uncertainty means surprises! Limits force change of approach

E.g. Functional programming has higher-order functions to defer specifying behavior. OO has interfaces and (gasp) inheritance Someone will make this choice later

Let’s formalize this.

Not that kind of formal! I have found it helpful to view software as an infinite game. What is that?

I learned it for entrepreneurship. Entrepreneurship is brutal: struggle to survive.

For infinite, the rules *must* change. The rules must change to take those into account. Finite players play within boundaries; infinite players play with boundaries.

--- Trap: A succession of finite games. We “win” now, but impose limits later. Those limits can force us to stop playing! Background: I worked in live production. It has constant change, but you don’t want any on-air mistakes!

We want to keep the game going!

--- ## Let us consider ... * What ends the infinite game? * What lasts? * What keeps the infinite game going?

What are game ending conditions?

Everyone abandons Business fails

Looks good now but get a constraint future?

Which features are going to change in the future? Which ones can we avoid doing now?

Velocity. ROI. Short-term earnings.

You suffer, management wins. … for a while until everyone quits

You have to play finite games to make progress in your infinite software game. You just need to make sure your finite games do not compromise the infinite games.

there's no fixed endpoint, no fixed set of players, and no way to ever truly "win.”

* Opt in to constraints * Separate pieces * Make things non-brittle and non-fragile

Preserves optionality and therefore changeability Not moving Moving expends energy, so you can only move so much.

If you bet on lasting things, you will alway win!

E.g. Weather data

The example Fibonacci versus it in Ada. JVM example Hiccup is more general than HTML

E.g. Ingredients, not cooked things.

The Internet is an infinite game. Good basis of illustration.

Data is stable. I never reset a thing. It only changes as often as that thing.

How many cascading changes do you have to make? e.g. Change types. Change "helper" code for your pattern. Hidden dependencies

In strength in constraints Conveyance Interactive development JVM example Hiccup examples

The most minimal specification? No specification!

What if you could make a change without changing any code?! The preferred solution is the one that doesn’t require any code change at all! (Sorry Scala devs. You have my deepest condolences.) Possible when things are *not* specified.

We want to keep the game going!

Software is for us! Satisfying, at the very least.