Top-down vs Bottom-up

I like to look at the world around me in layers of hierarchy, and there are two lenses that I apply when thinking about how these layers come together.

The first lens, “top-down”, looks at the world by starting at the top, something high-level or abstract, and then working down to the lower layers. The second lens, “bottom-up”, is the opposite—starting with something low-level or concrete and working up. This sounds pretty vague, but you can apply these two lenses to pretty much everything, so let’s explore by looking at a few examples.

Top-down learning is starting with a high-level concept and then digging deeper and deeper, asking questions like “why is that? how does that work? what does that mean?” Bottom-up is learning fundamentals and building them up until you can explain higher-level concepts.

A Mathematician’s Lament is a great essay about how the way we teach mathematics in a bottom-up way, by starting with low-level mathematical concepts and techniques and building them up into a useful model of the world, can cause people to lose interest early on. He argues that this approach is backwards to the way that most people prefer to learn.

This is perhaps backed up by Richard Feynman, one of my favourite teachers, who explains in the video Richard Feynman. Why. how repeatedly asking “why?” helps you start with a simple high-level view of the world and dig deeper and deeper into physics, whilst always being rooted in a real-world problem.

Top-down works great when you know what you’re trying to learn, when you have a specific goal in mind. Have you ever taken an online training course where you have access to the reference material while taking the quiz? Most people find that it’s easier to read a question and then go looking for the answer, than to read through all the content and try to memorise it well enough to answer every question.

Similarly, if you’re trying to learn a foreign language it can help to have a pressing need to actually use what you’re learning. When I lived in Japan for a year I found it relatively easy to learn the language because I was using it every day—it wasn’t really a choice. Conversely, my attempts to learn Chinese have failed miserably for the last 7 years because, despite my wife being Chinese, I don’t have the same pressing need to learn and use the language every single day.

All of this isn’t to say that top-down is the best way to learn. Sometimes you don’t know what you’ll need to know and it’s good to build up a solid base of fundamental knowledge. This is essentially what university courses try to do.

I wrote about top-down programming in my post Programming by Wishful Thinking, where you start with high-level functions that call mid-level (yet to be defined) functions and implement your way down to low-level functions. Compilers don’t really like this approach, though, and are constantly pushing us towards a bottom-up approach by forcing us to define things before we use them.

How do you think about your career progression? Do you have a high-level goal for where you see yourself in 20 years, and then plot out a path for getting there? Or do you use a bottom-up approach, building on your experiences, looking for the best opportunities/building blocks you can find now and working your way up, perhaps unsure of what exactly you’re building towards? Some people need to have that anchor in the future that pulls them towards their goal, and they assess every career opportunity in terms of how it helps them get there. Others like to go with the flow and see where life takes them.

What about product ideas? Some people start with a high-level goal or vision that they want to achieve, and then develop a mission or strategy for achieving it, and then a concrete plan or backlog of features to deliver it. Others start by just putting blocks together, building from the tools and skills available to them, and then seeing to what mission/vision it leads. Airbnb’s mission is to build a world where you belong, but they didn’t know that when they started with renting air mattresses. They got there from the bottom-up.

What about software testing? Unit testing is a bottom-up approach, focused on literally the smallest units of software. If a unit test fails, is it the code or the test that’s wrong? Hard to know when you aren’t looking at the big picture. End-to-end tests are the top-down approach, which focus on higher-level use cases. But if an end-to-end test fails, it’s hard to know where in the code-base the bug is. You need a good mixture of both.

Top-down and bottom-up can also apply to writing and story-telling itself. Informational writing is often done bottom-up, where you start by laying out the facts and then build and build until you reach a conclusion. This can be really boring, and a common reaction to this style is “get to the point!” and “where are you going with this?” Academic writing often uses this approach, which is why they usually stick an abstract at the beginning to summarise the conclusion.

The conclusion contextualises the facts and helps the reader follow along because they can understand how your points fit into the big picture. Stories also often use this approach, because without that up-front context it provides a sense of mystery and intrigue.

The top-down approach is to start with high-level statements and dig down into the details as required. This can start out quite vague, and a common reaction to this style is “what are you actually saying?” and “what does this mean in practice?” Marketing copy for software often uses this approach, because it gives you an overview of why you might use the software quickly and then lets you dig deeper into the technicals of how it works if you think it might be a good fit.

There are alternatives and variations to these two lenses too. “Outside-in” is where you start simultaneously at the highest level and the lowest level, and work your way in until they meet in the middle. As an example, you might have a long-term goal for your career, and in the immediate-term you make career moves based on opportunities available to you, but you’re still working out the mid-term plan that joins the two.

Of course there’s “middle-out”, made infamous by the scene in Silicon Valley. An example of this could be that you have a great product idea (mid-level), but you’re still working out the features/UX (low-level) and the vision/business model (high-level).

Finally there’s what I call the “lightning-method”. If you’ve ever seen a lightning strike in slow-motion, you’ll know that it starts in the cloud, branches and branches searching for the ground, and then as soon as the connection is made it surges back up. An example of this is finding product/market fit, by starting from the bottom exploring with features in search of your users’ real problem. Once the connection is made you flip focus, the problem you are solving becomes the vision, and you work your way down from there.

When thinking about writing this post, I struggled for a long time with the question: should the post about top-down and bottom-up be written in the top-down style or the bottom-up style? Wouldn’t it be interesting if I could use a weird mix of the two at different parts of this post to emphasise the way they work?

Maybe some day I’ll attempt that perfect meta-post, but for now this is what you get. I’ll just leave you with the following questions. Where in your life do you apply these lenses? And the more interesting question, can you think of cases where you use one but you’ve never tried the others?