The Bike That Taught Me How to Code Better 1

Introduction

I used to think programming is about typing code. But the best programmers don’t just write instructions — they build systems that behave, adapt, and survive.

A Lesson from a Bike That Wouldn’t Start

When I went to my old town, my bike refused to start. I took it to a nearby mechanic. He didn’t open the engine. Instead,

▸ He pressed the horn → Nothing

▸ Then checked the battery wire → Loose

▸ One twist, one spark → Fixed

He didn’t guess. He diagnosed. That’s the first habit I noticed in experienced programmers. They ask:

▸ What changed?

▸ What’s connected to what?

▸ What is this thing responsible for?

🚫 Beginners Do:

Bike won’t start → Opens engine

Bug in code → Rewrites function

✅ Instead:

Check the battery wire.

Check inputs, states, logs

🧩 Thinking in Interfaces:

That mechanic didn’t know my bike. But he knew how bikes work. He treated the battery as a component. It should supply power. If it’s not connected, nothing works. That’s an interface mindset.

🧠 Inform 7 – The Language that Thinks Like the Real World

Some languages make this kind of thinking natural. Inform 7 is one of them. It models systems using relationships and rules. Instead of classes and structs, it gives you:

▸ Things (Objects)

▸ Rooms (Locations)

▸ Relations (Connections)

▸ Activities (Behaviors)

You describe your system like writing a story:

No boilerplate. No classes. Just relationships and behavior. You describe how the world works — and the code follows.

🧑‍💻 What If We Wrote This in Go?

In Go, we model the same behavior using structs and interfaces:

The bike doesn’t care about the battery’s internal design — just whether it’s connected. That’s interface-based design.

🖥️ How It Looks in JavaScript

JavaScript doesn’t have formal interfaces, but the pattern is the same:

This is called duck typing –  If it behaves like a battery, it’s treated like one.

🔃 The Shift

The best programmers move:

▸ From writing code → to designing behavior

▸ From thinking in lines → to thinking in flows

▸ From depending on structure → to depending on contracts

They don’t just build features. They build systems that make sense — and don’t break when one part changes. Just like the mechanic – They know the real problem is often in the wire, not the engine.