How Understanding Maps Can Help You Make Progress As A Developer 🔊

What is progress?

Let’s imagine you've contacted a tourist map maker. You’ve asked to build a map that represents Sydney. The goal of the map is to make it easy for you, who is not familiar with Sydney, to find yourself in it.

You assume that for the map to be useful, it needs to be as accurate as it possibly can.

Would you say a map for tourists containing the main tourist places, roads, and public transport is the most accurate representation of the unknown territory you're trying to understand?

If the map is the most accurate representation of a territory, then:

• It needs to have the roads and buildings in the real size, for that you can't find yourself in a place where the roads are much smaller than they really are.
• It would need to have all the geographic elevations, for that you can't predict how difficult it's gonna be to go from one point to another with the bicycle.
• It would need to have all pedestrian crossings, for that you can't predict if your journey is gonna take longer because you'll be stuck trying to cross the street.

There's no map that can provide the most accurate representation of an unknown territory. If there was, then that map would have to be of the same size of the territory. In that case, you wouldn't need a map at all, you would use the territory itself.

The best representation of the territory is not a map, it's the territory itself.

A map sacrifices information. It's an abstraction of reality.

The format of the roads, the order of the buildings, the relative location of the businesses… all of this can be mapped and be useful, although at the cost of losing information like the geographic elevations, the real size of the buildings, and their relative distance.

A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.

— Alfred Korzybski, Science and Sanity (1933, p. 58)

In software development, you can say a map is an abstraction and the territory is the reality.

The abstraction is what affords you to comprehend reality, for that the reality is too complex for you to understand as a whole.

A map is for the territory what a Turing Complete programming language is for the runtime.

You can't create a program using binary commands. You need a language that can serve as a map for you to make sense of the bits and build things that will be eventually compiled to zeroes and ones.

A map is for the territory what one of the many software development techniques are for the system that needs to be created without bugs.

A team can't sustainably write certain kinds of complicated and critical-level programs without tests, for example. You need to understand testing and other techniques in order to be able to walk through your territory seamlessly and avoid mistakes.

The map is for the territory what the theory is for the practice.

You can't assume your understanding of a software development pattern or technique is correct if you only know the theory. There will be people who will talk about the same theory but will do it differently. Sometimes they will execute it better, sometimes they won't.

He who learns and learns and yet does not what he knows, is one who plows and plows yet never sows

— Ancient Persian Proverb

It's very common to see developers doing Test-First believing they are doing Test-Driven Development, or to write functions and assume they're doing Functional Programming.

It's also very common to see managers implementing best practices instead of experimenting things in practice, like forcing Scrum and assume their team will magically become Agile.

The map is an abstraction and the territory is the reality. Use the map as a tool to help you comprehend the reality, don't try to explore reality without an efficient map.

You’ll need maps for different purposes if you want to understand the territory better, even if you don’t use them every day. Maps for hiking, driving, public transportation, tourism…

The same way, you’ll need techniques for different purposes if you want to understand software development better, even if you don’t use them every day. Techniques such as task estimation, logical problem solving, software management, design patterns, coding principles, Event-Driven Design, Aspect-Oriented Programming…

The good thing about understanding the fundamentals of maps and how they relate to the territory is that you realize there's no absolute solution for everything. There's no silver bullet.

You’ll never be able to comprehend everything, but having more than one map will be the most effective way to comprehend everything you need to.

There's no such thing as one true map. If there was, then it wouldn't be helpful as a form of abstraction.

Your mind or mental model is only your personal map and it does not represent the reality. If it did, it would be reality itself and therefore there would be no need for a map.

That’s why there’s no silver bullet, for that a map shows only a small subset of reality.

What you can do is always learn a new map every day through a journey of Continuous Improvement.

And that, my friend… that is called progress.