A Software Origin Story
I got my start in computers as a junior graphics artist, working in downtown Chicago for a place called the Parsons Group. It was gig work for a multi-year project tasked with developing multimedia training content for 3M. I was in college and it all felt very… legitimate. And serious. I had to obtain a lanyard and take an elevator up to the 33rd floor of a building right next to Arthur Andersen’s headquarters in the loop. People entering the building wore suits and carried briefcases.
Up on the 33rd floor in the carpeted confines of the office, I’d walk past a receptionist. There were HR people, lawyers, project managers, business process analysts, subject matter experts, sound engineers, graphic designers, voiceover actors, user acceptance testers, and multimedia Lesson Logic Developers (LLD’s). Over on my side of the office, there were huge cabinets filled with brand new keyboards and mother boards and graphics cards and various plugs and adapters. New computer parts were delivered almost daily. Down the hall, there was another more serious project underway that was somehow related to Y2K compliance.
Day 1: A crash course in Compression, Bandwidth, and Web Graphics
“You ever heard of Director or Photoshop?”
A guy named Dave asked me this as I settled into my desk. He was one of the senior LLD’s. I perked up in my chair. Photoshop? Yeah, I’ve seen that program in the computer lab at school, but I’ve never actually used it. It was a hard no on Director. Dave smiled, then spent a bunch of time explaining the concept of modems and bandwidth as it related to our project. One of the primary challenges we faced as content producers was shipping a product that looked good to users accessing it from home, over 28.8 modem connections. The compression technology we were using allowed our 15 minute lesson modules to be squeezed down to about 2mb.
TWO MEGABYTES!! This had no meaning to me. My eyes must have glazed over, because Dave chuckled and told me not to worry too much — I wouldn’t have to think about any of that compression stuff. Not just yet. I just needed to make sure the images we were using looked good on a screen, and weren’t too big — in terms of FILESIZE. I’d be working primarily in Photoshop to prep graphics for the lesson logic developers who assembled this stuff into full-blown multimedia modules. That was the job: read a script (prepared by a BPA), use the software like a CPA would, click on things, take screenshots, store those screenshots as optimized images, and check them into the lesson factory.
Dave showed me how to take screenshots with some special software that let you zero in on a small area of your screen, and make tiny adjustments using crosshairs, then bring that image into Photoshop. Once in Photoshop, he showed me how to make sure the color mode was set correctly. I had no idea what he was talking about, so he explained the basic differences between color for print vs color for the web. And he gave me a primer on the differences between RGB and CMYK and screen DPI. Then he talked about the importance of downsampling and optimizing. But not too much. Using actual example files, he showed me how layers worked and layer locking and then he showed me the marquee and the lasso tools and how feathering and selection adjustment worked. This whole thing took quite a bit of time, but by the end of the day, I felt like I had learned something of value.
So I worked on Graphics. A lot. I got really good at not doing dumb things. Then I got good at doing somewhat smart things—like adjusting my tool presets, organizing my layers, experimenting with export settings, and adopting standard naming conventions. I started to learn about more of the tools and concepts—like how the History panel works, how gradients and masks and opacity and paths work together. I learned how to use Sound Forge for basic editing — to retroactively fix audio so we wouldn’t have to do another studio session. I actually got pretty good at this, and occasionally made audio files of the voiceover actors saying things that made no sense. People in the office got a kick out of that.
A few months into my gig, I was promoted to LLD — authoring lessons in Asymetrix Toolbook like Dave. And though I was by no means a wizard, I had mastered the basics. I also became comfortable learning things on the fly, like the Toolbook sequencer, and its companion authoring language OpenScript — which could be semantic cousins with AppleScript or Lingo. I found the work to be an enjoyable break from my college classes, which at that time, included a graduate level seminar on Gödel's incompleteness theorem 😬. I learned how to write one-liners for doing simple things, and longer subroutines to handle more complex interactivity that relied on a user’s input. Funny thing is, being expected to figure things out as the need arose — though scary at first — became the new normal for me. It gave me the reputation of being the go-to guy for weird problems, and gave me the opportunity to work closer with the BPA’s and the sound engineering team. I even traveled to Minneapolis for client visits. I was still technically just a college student, and completely blown away that a job would pay for me to board an airplane and sleep in a hotel and attend a few meetings.
My First Software Optimization
One of the problems that kept biting us in the ass, especially as we produced more and more content, was ballooning file sizes. Home users in Minneapolis were complaining. Back in those days, most ordinary people could go about their lives with no knowledge of the internet. In fact, tv “experts” still commonly used the cringey moniker information super highway. To put this relative dark ages into perspective for modern people, I am talking about an internet era that was…
5 years before
Gmail6 years before Senator Ted Stevens called the internet a series of tubes
8 years before the
iPhone9 years before
Github11 years before
Instagram13 years before
TypeScript14 years before
Docker17 years before
Tik Tok23 years before
ChatGPT
The problem of bloated lesson files didn’t really make sense — until someone pointed out that there were lots of duplicate and triplicate files. And then a bunch of us gathered around Dave’s desk to look inside a Toolbook file’s asset library. Sure enough, buried in there were files that looked identical, but stored as separate copies. When the severity of this problem sunk in, there were collective face palms and sighing. As a person who no doubt was partially responsible for creating this mess, it made complete sense to me why it was happening. It was so easy to accidentally re-import images you didn’t realize were already in the library — especially when you were busy working on multiple lessons. The same problem existed for .wav files (audio), and was in fact much worse because they were enormous.
We all agreed to spot-check our lessons — locating and removing duplicates before exporting the final product. Which was OK… I guess. But it was very error-prone since you had to manually eyeball or listen to every asset in the library. This could sometimes number over a hundred.
So I studied the OpenScript manual and discovered that you could access a lot of under-the-hood Windows functionality by using their OpenScript-to-Windows-dll SDK. It sounded scary, but it was really just one or two steps beyond the stuff I was already doing. After a bunch of attempts, I got a hello world sample working — a menu item that, when clicked, would print all the files in the current lesson’s library. After some tweaks to the main loop, it printed only the files that were unused. And with one more tweak, I got my menu item to not just print, but delete, the duplicate files—each time incrementing a counter to keep a tally of how much (in terms of file size) was being recovered from the lesson. When all deletions were done, it would spit out this feedback to the user.
💡 HOLY CRAP
A light bulb went off. I wanted to do this again — solve problems using common sense paired with what I like to characterize as an expeditionary mindset — a frame of thinking I attribute to my time as an Army Combat Engineer — a kind of problem-solving posture shared amongst light infantry units that says: when you’re in a jam, you can’t wait for the cavalry to arrive and save the day. You are the cavalry.
Essayons is the Combat Engineer regimental motto, and is taken from the French verb essayer. It literally means… Let us try.
Essayons is the US. Army Combat Engineers’ regimental motto.
The Sapper Creed
Sappers are like super Combat Engineers, and though I never had the distinction of going to Sapper school in the Army, I absolutely have to include the creed below. Every line of it is inspirational.
“I am a Sapper, the cutting edge of my country’s sword.
I will always endeavor to complete my Sapper mission, regardless of available assets.
My flexibility and special training shall provide my task force with the tools to overcome insurmountable odds.
I realize that I will be called upon for my expertise in all aspects of mobility, countermobility, and survivability.
The failure to effectively accomplish my mission could cost the lives of others.
I will set the example by keeping myself physically fit and mentally tough.
I will strive to sharpen my Sapper skills and the skills of those I support.
Sappers Lead The Way!”