How do you know a land? Pt 2
What it means to "know software"
Does a mapmaker know the land? To use a software engineer’s favorite answer, “It depends.”
Any engineer will tell you that the best way to get familiar with a code base is to contribute to it— to “get your hands dirty” so to speak. Sure, you can read it line by line, open its commit history and blame layer, look at all the design documents and architectural diagrams. But fundamentally the way you get to know a code base is to simply work on it— that is, contribute a feature, submit a bug fix, or refactor it.
Recently, I’ve been learning more about code analysis tools. You can use them to detect layering violations in your code and create references in your code indexer. These tools are generally built on top of graphs of your software, maps of all the function calls and build dependencies in your program. Often, it can be impossible to view these graphs in their entirety because of how large and dense they are.
Code analysis tools serve to aid and accelerate the process of development. They can teach you about the properties and performance of your code and help you build a big picture understanding of how everything works. However, until you actually submit a change to the code base, you’re not really a software engineer.
Maps are great tools that increase legibility. But you cannot know a land from reading a map alone. And you cannot know a piece of software just from looking at it. In order to know a piece of software, you must develop it. And when you develop it, you change it a little as well, making it a bit different than what you see on the map.
So then, I posit, the only way to truly know software is to develop it.