Configuration is the Real Magic

I talk about writing software being like magic. It’s how I view the craft in a lot of ways–using arcane words and phrases combined with strange tools to conjure amazing things out of a series of 1’s and 0’s on a circuit board. But when I describe my ultimate career goal as “being a wizard” I mean something, or someone, very specific.

I’m not talking David Copperfield or Penn and Teller. They are very skilled magicians, not wizards. That sort of magic is based on memorizing an illusion, of doing a thing in a certain way because of the reaction you know you’ll elicit. One does a very specific thing, or specific set of things, in a well organized way, over and over and while it gets more polished with practice, it will always be the same.

The words “programming is magic” conjure up Gandalf for me, from the Lord of the Rings universe. For the majority of those adventures, it wasn’t actually magic that made Gandalf the go-to guy–it was never “Gandalf has a spell for that.” What made Gandalf the truly formidable foe and an invaluable ally was the fact he knew things. He understood the old lore, the behavior of people and animals, how the elements of the world fit together and how they could either help or hinder a particular goal.

Gandalf knew the configuration of Middle Earth. Maybe not the *exact* configuration for every situation, but he knew what was missing, or what was the blocker. His magic was always a tool to divine knowledge or to force something into place, to adjust the configuration of a situation. Never magic for the sake of magic, happening in isolation.

“Gandalf knew the configuration of Middle Earth.”

Just like the veteran programmer on the team who always seems able to spot the problem

There’s a parallel here with writing software. Hopefully I’ve already set your mind to some old programmer who has looked over your logs for a failing build, tapped on the screen, and said something like “Oh. It’s looking for the source folder in the wrong place” or “Why is this talking about version 3.2? Didn’t we decide to use 3.5?” Their knowledge isn’t restricted to one language or framework–they speak the patterns that appear across the development landscape.

As I learned how to code, I kept to a safe little bubble where I didn’t need to learn anything about configuration. If it wasn’t in a Visual Studio GUI it shouldn’t be touched. Always following very specific instructions on how to structure folder hierarchies (so they would match IDE defaults, I now know) and not needing to understand the why. If a library or plugin required a .json file to tell it what to do then I simply didn’t use that tool. I didn’t understand how the solution was built or how it interacted with the environment, and as a result was at the mercy of Visual Studio.

It was a time of great fear, because if VS had a hiccup while installing a NuGet package and didn’t update the version number, I could be down days without any clue what to do. If I changed a namespace or added a folder, it might break the solution or it might be fine and I never knew which it would be or why. It must have been how people felt living in the shadow of a volcano or along the coast–never knowing when or why nature would lash out, and barely equipped to deal with it when it happened.

“It is the absence of facts that frightens people: the gap you open, into which they pour their fears, fantasies, desires.”
― Hilary Mantel, Wolf Hall

Lately, I’ve been part of a culture where a major goal has been to understand what happens under the hood. “This works and that’s fantastic–but why?” and  “How can we change the output?” have been questions that I’ve come to really appreciate and incorporate into my development process.

It’s brought a lot of peace into my life. The frustration of “Well it’s not in the drop down so I guess we can’t use that feature” is gone, replaced by “I bet I can figure out what to change in the project file to make that happen.” When a build fails, I no longer go to a place of panic, assuming I’ll never figure out what happened–now when a stack trace goes into the system library or points at a framework method I can start connecting the dots.

It hasn’t been an overnight success and it’s far from a finished journey; I’ve broken some things, spent hours going “Nothing is real and this is all made up and I never should have stopped delivering pizzas.” But now, more so than in the past, each time I solve one of these mysteries it’s like another tool goes into the toolbox, ready to make the next breakdown that much easier to fix. It’s not nearly as comprehensive of a toolbox as I’d like, but the list of situations I’m prepared to handle only grows as time goes on.