Skip to main content
Liz Basson
Thou Mayest: What East of Eden Can Teach Us About Technology

Thou Mayest: What East of Eden Can Teach Us About Technology

October 20, 2026

There are some books you read once and remember. Then there are books that quietly change the way you see things. East of Eden is one of those books for me. At the centre of the novel is a word: timshel. It is often translated as “thou mayest.”

You may.

The idea is deceptively simple. We inherit things we did not choose: our families, our circumstances, our histories, and the choices made before us. But what we inherit does not necessarily determine what we do with it. I think about that idea often when working in technology. Because developers inherit things too.

We Inherit More Than Code

Most developers don't start with a blank page. We inherit codebases we didn't write, systems we didn't design, frameworks chosen years before we arrived, and processes that have survived because nobody has stopped to question them. Sometimes the inheritance is good. Sometimes it isn't.

We inherit technical debt. We inherit architectural decisions. We inherit documentation that is incomplete, dependencies that are outdated, and assumptions about users that may no longer be true. And eventually, we have to decide what to do with it. We can maintain it exactly as we found it. Or we can change it.

The Past Is Not the Same as the Future

There is a tendency in technology to treat what already exists as inevitable.

  • This is how we've always done it.
  • This is how the system works.
  • This is how the client wants it.
  • This is how the industry does it.

Sometimes those statements are useful constraints. Sometimes they are simply descriptions of the past being mistaken for rules about the future. There is a difference between understanding why something exists and assuming that it must continue to exist. Good development requires understanding the history of a system without becoming trapped by it. You need to know why the decision was made. But you also need to be willing to ask whether it is still the right decision.

Technical Debt Is an Inheritance

Technical debt is often discussed as though it were a mistake made by someone else. Sometimes it is. But more often, it is simply the accumulated result of decisions made under different circumstances.

A shortcut made to meet a deadline. A framework chosen because it was right for the team at the time. A feature added without knowing how much the product would eventually grow.

The people who inherit those decisions have a choice.

  • They can resent them.
  • They can ignore them.
  • Or they can understand them, work with them, and eventually decide what needs to change.

That doesn't mean rewriting everything. In fact, rewriting everything is often its own kind of bad decision. It means being deliberate about what deserves to survive.

We Are Doing This With AI Too

The idea becomes more complicated when we look at artificial intelligence. AI systems are built from what came before them: human language, human knowledge, human-created code, human decisions and, inevitably, human biases. We are not creating technology from nothing.

We are building on an enormous inheritance. That makes the choices we make now more important.

  • What do we preserve?
  • What do we change?
  • What assumptions do we carry forward simply because they are embedded in the systems we inherited?
  • And what do we deliberately choose not to pass on?

The question is no longer simply whether we can build something.

It is what we choose to build with what we have been given.

Thou Mayest

This is what I keep coming back to in East of Eden. Timshel does not mean that we control everything. We don't.

A developer cannot choose the codebase they inherit. A company cannot erase its history. A technologist cannot control every consequence of a new technology. But there is still a space between what we inherit and what we do next.

That space is where choice lives.

Technology often makes that choice feel invisible. A framework becomes an industry standard. A workflow becomes a process. A piece of technical debt becomes “just how the system works.” Eventually, someone has to decide whether to leave it that way.

We do not always get to choose the starting point. We do get to choose what happens next.

What We Pass On

Perhaps the most interesting question isn't what we inherit. It is what we leave behind.

Every developer contributes something to the systems that come after them. Code. Documentation. Architecture. Decisions. Patterns. Sometimes even problems that someone else will eventually have to solve.

The same is true of the technology industry as a whole. The choices we make today become part of someone else's starting point tomorrow. That is a responsibility worth thinking about.

Not everything we inherit needs to be preserved. Not everything needs to be destroyed either.

Sometimes the work is simply to understand what came before, decide what still serves a purpose, and have the courage to build differently where it doesn't.

Thou mayest.

You may.

And perhaps that is one of the most useful ideas we can carry into technology: the past may shape what we inherit, but it does not have to decide what we build next.

—Liz Basson

Elegant workspace with laptop and design sketches

Ready To
Explore?

Take a look at my projects and see how I craft elegant, user‑friendly web experiences.