Easing Simple

what if simple was easy?

I’ve been posting around the internet with this phrase as my bio for a while. I figure I should probably try to explain it. Those in the know might have already recognized wat this is a riff on, if not there’s a great Strange Loop talk by Rich Hickey called ‘Simple Made Easy’. It’d add some context to this if you’ve already watched that, but not so much that you should stop right now. Rich Hickey does not talk about easy for very long, and that is most of what I have been thinking about.

I don’t think the title actually fits. Hickey focuses on the difference between simple and complex (or complected, as he put it). Simple gets a passing mention at the beginning in comparison to hard, when we talk about the approachability or familiarity of a new system. But after that his main case is not for ease, in use or while building, but for simple. I want to talk about easy.

Easy is almost as hard to achieve as simple and the worst thing about it is there is no clear deterministic answer. People understand things based on their past experiences, so making a concept approachable to one group might move it farther away from another. Despite this, software has manged somehow to make all sorts of systems more approachable than their ‘bare’ forms. But how specifically do you do this in a way which is sustainable and, importantly for me, data-as-layer-zero|leaves room for future migrations? Let’s talk about git and Pace Layers.

git the binary cli git the event store github the platform lazygit, github desktop, vscode, git, magit, (seamful abstractions, leaky abstractions, superpowers, ) GitButler Competing with git: jujitsu

In 2025, git has conclusively won. It is not enough to replace git as it did with SVN. One must also contend with the surrounding ecosystem from package managers and platforms to individual applications and workflows. It’s difficult to say this is an example of pace layers working as expected. Jujitsu’s approach has been to join the ecosystem by offering compatibility even as they try to nudge users away.

• I make the case that simple often gets abandoned for complex, because the complex system has put more effort into providing easyness

• You can’t really ignore this, because you end up in the same ecosystem as the people making these choices. My messaging app is decided by the majority of people I need to talk to. The speed I can work, my productivity, depends on the tools which are available to me, my language, framework, operating system, and even hardware of choice.

• so there are a lot of benefits in pushing others toward simple if I do not want to import their complexity into my life. And this tada means making simple easy.

• Well, now I’ve clearly convinced you there’s a benefit, where does the problem come from, why do sim

• and here are a couple examples where the alternative happens

  • lazygit: how do you abstract away a tool, in a way that provides training wheels instead of crutches?
  • clojure: let’s do functional programming, but on the JVM