These are questions for wise men with skinny arms

So I’ve been spending an inordinate amount of time on IT related activities lately, and boy have I gained some respect for people who do this everyday. My very first jobs when I was a kid were essentially help-desk level IT: setting up networked printers, digging through backups, making cables, removing viruses, installing drivers, and using more advanced Windows tools to automate things. These were all things that I could do because I generally had no real insight into how computers worked or how to program. I had picked up enough technical terminology to get the right search terms on Google that would get past the click-bait and hour long walk through videos to get to just the piece I needed to get to the next step. This isn’t a bad way to get things done, and it’s sure as heck more efficient than reading online documentation that’s either out of date or just incorrect.

Things have come pretty far from scrolling through forum threads for the one person who provides a hint at an answer. SO in particular has pretty much taken over for this sort of task, be it basic programming or systems related. I often find the off-topic answers more insightful than the ‘do this to make it work’ ones. I’d much rather have some insight into how the system is supposed to work than a cure for the particular symptom I’m experiencing. Even with a good level of understanding in computer architecture and operating system design, some of these systems require an immense amount of learning to be able to diagnose even the simplest of errors. The complexity dwarfs the OS in layers and edge cases. Most of the problem comes from big projects with sparse documentation (duh). Most operating systems are mature and well used enough that even if the 1st party documentation is lacking, there are blog posts or questions online to fill in the gaps. You can be fairly certain that if you aren’t trying to do something crazy, someone has documented what you are looking to do.

When attempting something crazy, sometimes you know going in. You know the framework/virtual machine/language compiler probably wasn’t designed with what you have in mind, but with a bit of terrible cleverness you can tilt the system to where you need to go. But then, you are going to be the one blazing the trail for others to attempt. Your deep knowledge of the hidden knobs and levers practically gave you this crazy idea in the first place. Even worse, other people might get the idea that because your crazy attempt was successful and documented that it wasn’t so crazy in the first place! It’s the saying in API design of: “If you make it available and decent it will be abused in ways you couldn’t have imagined.”

The scary kind of crazy is when you don’t know the system you are in as well. You think something should be simple but you just don’t know it yet. That’s when you start digging in beyond the external documentation. It’s the curse of the ‘open-source’ project, the code becomes the last level of documentation. Some frameworks revel in this sort of freedom, providing tools to read the source along side your code. Other projects are boxed in so many layers you probably need to instal a separate tool-chain just to build the debugger for the project you already use. The source might be available, but if it takes me 2 days to trace from the web form field to the script generated from the database columns by learning the entire system architecture along the way, then it’s not quite as accessible.

This is what my IT experience has been lately. Some of the pain was just skipping details (why do some specs leave off the v3 in 2011-3 when it’s important!!), but other parts have been just the pain of digging through the complexity of Qt, Jenkins, Pandas+py2exe, and Azure Virtual Networks. These have been necessary advances as I build tools around other core technologies.

I’ve been focused on the core application and its core (the language/ecosystem it’s written in) for so long that I’ve forgotten that the whole system is a village. The application is important, and building that strong central piece will make the rest of the support infrastructure worthwhile. But I’ve often lost sight of the fact that as you build a system you aren’t just making a program, you are building a suite of programs that will have to work together on different tasks to survive the winter! My IT tasks might have demoralized me if I hadn’t kept that in mind, but now I can take away a greater understanding of a more healthy whole as I unknowingly embark on crazy journeys.