I caught the programming bug after watching the 1970 thriller film Colossus: The Forbin Project. My first programming language course was FORTRAN (circa 1973). I wrote my programs in longhand, typed them out on card decks on a keypunch machine, and loaded them into the card hopper/reader for transmission to the mainframe or to the green-bar printer for a program listing. The first thing I had learned from the seasoned programming students was to opt for a green-bar print out of your program so you could walk through the code until you had the confidence that it would compile correctly and execute. Having to wait 24 hours between submitting a card deck and receiving output from the mainframe made this piece of seasoned advice logical. Needless to say, as finals week approached the two key punch machines saw no idle time, and a physical confrontation was not unusual. My girlfriend at the time was one of the mainframe operators on the raised floor in the computer room. She’d sneak me in during her midnight shift to let me use an IBM 2250 Graphics Display Unit to type my programs directly onto mag tape designated for the nightly batch processing run at 3AM. (We broke up during summer vacation, and I lost my computer room access for the fall term.)
Commercial BASIC and Pascal were my next languages on the job until 1985 when I got a position in telecommunications that required me to learn C and maintain software builds on a PDP-11 running Ultrix. After graduating from university (an eighteen-year odyssey), I was recruited as an analyst/programmer to work at a DOE facility in a Cray super computing environment with Sun SPARCstations as far as the eye could see (ah, the good, old SunOS days). When the 90s rolled into town I saw an opening to use my computer chops in retail, finance, and state government. I literally yawned when I was on duty for the Y2K rollover, a triumphant marketing campaign by vendors eager to make easy money. My tour of duty ended in 2006 as a technical architect, and I symbolically tossed my keyboard into the trash. I’m done; it is time to move on.
What does one do after twenty-something years in IT? The last thing I wanted was to be near a computer. Yeah, right, I thought. When Apple debuted their 2×2 Xeon Mac Pro, my wallet forced me down to the Apple Store. I couldn’t resist the temptation of seeing how much UNIX was under the OS X hood, and I wasn’t disappointed, but work flashbacks, chills, and cold sweats kept my user experience limited to the GUI. I learned to love the GUI. I buried vi in exchange for MacJournal. Instead of writing code, I wrote essays and stories. Then the music bug hit me hard; it took me down. Memories of my musical life from my youth overwhelmed my daily meditations. I felt compelled to pick up that musical journey I had left behind in my youth, but my violin would remain in its case. If I wasn’t programming or architecting designs during my IT career, I was dreaming of playing guitar. Since that was the case, I had no choice but to follow my guitar dream.
As each month of music lessons and guitar practice passed, I felt content that the IT geek in me was slowly slipping away. I joyously allowed my musical journey to consume me. Three electric guitars later, my home data center was dark, and that was ok. A lowly Macbook was sufficient power for my writing, blogging, surfing, and email needs. Life was good.
Then on one ominous day I was thrown back—against my better judgement—in front of a code editor. I couldn’t live with a few quirks in my commercial WordPress theme so I downloaded a thirty-day trial of BBEdit to hack some PHP and CSS code to tweak my theme. I promised myself to bury the code tools after I completed my hacks. Life was good again as order returned and Bach’s Minuet in G Major was sounding pretty damn good on electric guitar. Addicted to guitar tone, I invested in a preamp/FX processor so I could experiment and create different tones for specific music scores and effecting a particular musical ambience or mood. The preamp/FX processor is a standalone unit, but it can be controlled (and programmed) via a GUI that runs on a computer. Programming the unit via the GUI is accomplished graphically by moving specialized blocks and connectors around, and setting their respective parameters through virtual knobs, dials, and sliders. When you have created what is called a “patch,” it is saved as a preset in a memory location identified by its bank letter and preset slot number. The preset is saved in the MIDI SysEx messages (MIDI System Exclusive) file format.
The current version of the GUI manager for the FX processor doesn’t support splitting individual presets out from their respective banks or bundles. There isn’t an easy, fast way to clear an individual bank of presets, and there’s no way to bulk-organize the 384 preset memory locations. I could wait for an anticipated update to the GUI manager, but how long is that wait and will it address my needs? I did promise myself to bury the code tools, but it’s easy to take the geek out of IT, but it’s damn hard, perhaps impossible, to take the IT out of the geek. It wasn’t long before I was back in front of the terminal, using the UNIX command od to profile how the data is structured in the MIDI SysEx files.
Last week I turned on the power to my home data center and resurrected an idle 2008 Mac Pro to be a dev machine, running Mac OS X Mavericks (release 10.9) and Xcode 5.02. Tonight I bought the Kindle edition of Objective-C Programming: The Big Nerd Ranch Guide, 2/e (Big Nerd Ranch Guides), as my design entails coding the MIDI file parsing and message checksum routines in standard C and writing the UI and application logic in Objective-C. My C is a little rusty, and I’m new to Objective-C. This is a case where I have a need to make something in software, and it could be a one-off app, but who knows. I just know that I really want an easy, flexible way to manage my library of tone presets.
Having a need to program can make the whole learning process more fun, practical, and efficient because you have determined that you need to make something in order to accomplish a specific task. Choose your development environment accordingly, using a language (or two) that best suits the implementation of what you need to code.
Attempting to acquire programming skills without a specific focus or application in mind can potentially send you down unnecessary rabbit holes. Having a need to make a specific app can bring additional focus and awareness to your learning effort as you study a programming language. Really, the hard part is researching all the books and reading endless reviews in your quest to find the book (or books) that works best for you. Many programming books introduce concepts in small chunks, followed by hands-on exercises or experiments, which is a good thing. The ideas swirling around in your head about what you need to program will make the book-learning process more productive and palatable.
As we age, it’s no secret that learning new skills—be they artistic, musical, or technical—forces your brain to create new cognitive connections, thus exercising the grey matter in ways that will improve your mental faculties. If you want to learn how to program, think of something you need that can be made in software. If you have a little electronics knowledge, think of something that you would like to control and do just that by programming an embedded system with micro controllers.
I had no idea that I would find myself programming again, but I have a need to make something of which will benefit my musical passion. Possessing coding skills with no app to write is like having a custom-made guitar with no music to play. Having an idea for an app can put a destination on your learning roadmap, and for those of us in our second-half of life, it’s imperative to be as efficient as we possibly can, avoiding the rabbit holes along the path to acquiring new skills, after all we’re getting too old to be expending unnecessary energy.