Tackling Problems From Both Ends

I recently read Thinking in Systems. The book was a great high-level look at Systems. There was no math involved, no low-level details. It was all about understanding the big picture. It approached things from the top down, whereas my traditional Electrical Engineering classes in college were the exact opposite. They focused on all the math and low-level details. This got me thinking about the idea of tackling problems from both ends. What do I mean by that? It's this idea of blending high-level knowledge and low-level details.

Examples

Here are just a few examples of places where I've seen this idea in action.

Visionaries and Engi-nerds

There are a lot of visionaries who have great high-level ideas. They can see the big picture and envision the future, but they struggle with the details of how to get there. They know enough to know it's possible, but they haven't worked out those pesky details.

There's also the engi-nerd type who is very good at details and understands exactly how the low-level pieces go together. However, they often struggle to connect those low-level pieces to the bigger picture. They can get stuck debating minutiae that have no effect on what's really important.

In order to solve any meaningful problem, you need a combination of both visionaries and engi-nerds. You need the inspiration and the high-level goal to aim for, but you also need to understand the details of how to get there and make it all work on a technical level.

Learning Git

Learning Git is another area that benefits from approaching things from both a high-level perspective and a deep dive into the details. I often recommend 2 very different books. Version Control With Git starts at the bottom with the details about how exactly Git works and how it actually stores information. It gets into all the various commands, but doesn't do a good job of putting it all together. Git For Teams starts at the other end by defining various workflows for teams and then backing into what Git commands to use. It assumes that you already have an idea of what the individual commands do. To use Git effectively you really need both sets of knowledge.

System Design

I also see this idea a lot when I am designing systems. I typically start with a high-level overview. I figure out what the major modules are and how they communicate with each other. Then I switch to the low-level view. I start developing individual hardware drivers and testing them. Then I start to plugin them into the overall program architecture. Each side informs the other. In order to design the big picture architecture, I have to have some idea of the details of how the hardware works. When I am writing the drivers I have to take into consideration the larger framework I am plugging them into.