Abstraction and interfaces
Hiding complexity behind a contract, so you can use a thing without knowing how it works.
- Define an interface as a contract separating "what" from "how"
- Explain why information hiding lets systems and teams scale
- Spot a leaky abstraction and know what to do about it
You drive a car without understanding combustion. You use a function without reading its insides. That's abstraction: exposing a simple what while hiding a complicated how. It's the single most important tool for managing complexity, and the foundation of everything in this track.
An interface is a contract
An interface is the agreed surface between a piece of code and its users: the names, inputs, and outputs you can rely on, independent of the implementation behind them. "Give me a filename, I'll give you its contents" is an interface. How it reads the file — from disk, a cache, the network — is hidden, and free to change, as long as the contract holds.
This separation is powerful because it lets the two sides evolve independently. Swap the implementation for a faster one and every caller keeps working, because they only ever depended on the what.
Information hiding scales people, not just code
When the how is hidden, you can use a component while holding almost nothing in your head — just its contract. Multiply that across a codebase and a team: each person masters their piece's interface and trusts the rest by contract, rather than everyone needing to understand everything. Hiding detail is how large systems (and large teams) stay tractable.
Choosing the right level
Good abstractions are at the right altitude for their users. Too low and you expose detail that should be hidden (callers must understand the file system). Too high and you hide things people genuinely need to control. The art is designing a surface that gives users exactly the power they need and no more — which is also exactly the skill of writing a good function from the beginner track, scaled up.
Leaky abstractions
No abstraction is perfect. A leaky abstraction is one whose hidden details poke through and force you to think about them anyway — a "simple" network call that you must still handle timing out, a list that's secretly slow at one operation. The goal isn't to pretend leaks don't exist; it's to choose abstractions whose leaks are rare and to know the how well enough to cope when they surface.
When you review an AI agent's code, the interface is what you check first: does this function promise something sensible, and does the caller depend only on that promise? Implementations are easy to change; bad contracts spread.
Where to go next
Interfaces let us treat data abstractly too. Next: data structures — and how the shape behind an interface decides what's cheap and what's expensive.