Version 1.0 of my Career

About a week from now is the 40th anniversary of the start of my career as a software developer. I received the call informing me of landing my first programming job on Sunday, October 14, 1979. I was fresh out of high school with nothing but a ton of spirit, a seeming aptitude for this weird thing called “computer programming” … and my willingness to work for minimum wage.

I discovered this aptitude for computer programming during my senior year of high school. I signed up for a course called “Computer Math”. Ironically, I needed two math credits during my senior year to graduate since I had a rough time until then. It’s ironic because if it wasn’t for my poor high school performance until my senior year, I wouldn’t have been forced to take this class that defined my career.

Most of the world was barely cognizant of the word, “computer”. What was this “Computer Math”? In the hindsight of 40 years passing, “Computer Math” was a naive title for the course. It was just an introduction to BASIC for we 1970s kids who barely started using calculators.

I pretty much took over the class from the poor teacher, out-of-his-element. I re-worked the tests, graded the tests, provided material for lectures, for example working with my trig teacher (the other math class I took) on how pi is calculated.

I even set up and ran a booth at a high school exhibition at Pearl Ridge. I knew this computer thing was special with all the people who seemed genuinely mesmerized by how we “talk” to these strange machines. Much of that day was monopolized by none other than the not yet internationally known Israel Kamakawiwo’ole. I was mostly demoing to him while others came by initially to meet him.

However, I may have had an aptitude for programming at the time of my first job interview, but what I quickly discovered is that what I learned during that senior year of high school was not even close to “industrial-strength” programming. It was analogous to the English comprehension required for “Go Dog Go” versus “War and Peace”. I had – and for many years still had – a long way to go.

I had no idea about what I was going to do on my graduation day. It’s hard to comprehend how the notion of college wasn’t on my radar upon graduation from high school. But it wasn’t. This was 1979 in a little plantation town on Oahu, along with a few disruptions not of my doing.

I quickly found a job at a hardware store making minimum wage. Any money was more than I was used to. It took just a couple of months to realize that this was a road to nowhere. I had to do something. I looked in the newspaper ads for something. And there it was, an ad for a “computer programmer”.

I excitedly called, too stupid to realize how in over my head I should be. I told my soon to be boss about what I did for that high school course called Computer Math. He invited me for an interview, which I believe was Friday, October 12, 1979. I only know that date because it was the day Fleetwood Mac’s Tusk album was released and the local rock station played it in its entirety. That was my tunes as I drove in.

I hardly remember anything else about the interview. I think I left feeling I had a shot. I sensed the talent pool in Hawaii was so small that a hungry high school kid stood a chance, especially at $2.05 per hour. As I mentioned, I got a call a couple days later on October 14.

I drove into the office the day after that fateful call, loaded my mom’s beat up Corolla with a four-foot high stack of manuals and disappeared with a promise to return in two weeks ready to hit the ground running.

Back then there wasn’t a gentle on-boarding process, no senior programmers expected to mentor you, no stackoverflow, no github, no vast riches of expert bloggers, YouTubers, no online course sites providing spoon-feeding, high-quality, dirt-cheap content on just about any topic you can imagine. What I got to set me on my way back in 1979 was that four-foot high stack of 3-ring binders written in the most terse, obtuse manner possible, all black and white. A foot each for the hardware specs, the operating system, the programming language, and the user’s guide for the basic accounting software from which we built specialized versions.

Honest to God, I don’t know how I did it … but I did it. Sheer will, the wondrous brain plasticity of a 17 year old, and too naive to know failure was the betting man’s pick. That’s Version 1.0 of my career. I snatched the opportunity and never looked back!

Versions 2.0, 3.0, 4.0 of my Career

I never did look back, but I fell down to the ground a few times over the years when the rug was pulled out from under me. There were many career-changing events along the way, tracking along with all the disruptions in the industry – “mini computers” and mainframes to networked PCs, to client/server, to the Web, to the dot-bomb, to the rise of business intelligence – to big data, the Cloud, and machine learning where I am now.

Each of those disruptions were intense chapters of reinvention, getting up, dusting myself off, and sprinting my way back towards the front-runners. Many of my colleagues were knocked to the ground along with me, but didn’t quite get up. Fortunately for them, the increasing complexity of software projects spawned roles beyond programmers and analysts, non-technical roles – project managers, testers, business analysts, product owners, etc. So many were able to rebound from the disruptions in different ways.

None of those roles suits the personality of a rogue. Most real programmers are rogues at heart. We’re renegade artists thriving in the act of bringing order to ambiguity and relishing in our conquest over it.

Wait a minute. Isn’t being rogue un-Buddhist, the anti-meaning of “go with the flow”? The dictionary definition of rogue is not flattering – the most amusing being Merriam-Webster’s #4 definition: a horse inclined to shirk or misbehave. To me, a well-behaved horse, while useful to the general audience, it isn’t very interesting.

The Universe we experience is all about the neat stuff that happens where opposing forces meet – where the rubber meets the road, where the shit hits the fan, the Yin and Yang. What is Buddhist is to know and accept that fact. Here, I use the word rogue to describe relentlessly seeking the truth of reality, no matter what delusion our brain and the brains of others paints for us.

Well, as bad and as those stumbles were to my career, none of those reinventions were nearly as intense as that first one. Nor is this current one.

Reinvention – Version 5.0 of my Career

With just a few more Bodhi Days to my “big six-oh”, my Earthly body is showing signs of wear and tear. But I still love what I do to for a “living” to sustain this Earthly body as well as the Earthly bodies of my loved ones. So in order to retrofit myself for another twenty years or so, I realized I need to take proactive steps sooner than later towards reinvention.

The downside of being a gainfully employed old-timer in an insanely difficult and evolving field as software is that you don’t ever have enough energy left at the end of the day to fully keep up. These days, for IT workers life is a non-ending series of two-week sprints in a field where you don’t know what you don’t know and the environment is made of lots moving parts and everything is a moving target. At the end of the day, you’re wrung dry.

Unlike professions where things don’t change much, those who are just starting out in software are on par with us old-timers. The constant flow of brand new things means that experience doesn’t matter quite as much. It’s odd to ponder that many colleagues are about the age of children I could have had (in their mid-thirties or so) who grew up only knowing a world with the Internet, and already a with a decade of experience after their PhD!

This Version 5.0 is a proactive reinvention, unlike most of the others that caught me with my pants down. I could still easily make a good living for a few years as a “Business Intelligence / Data Warehouse” architect without this reinvention, but I’m better off doing this a few years before sixty years old than closer to seventy.

I hope that the insights below offer inspiration and guidance to my fellow “old-timer” colleagues as well as to those just starting out.

Version 5.0 Career Strategy

A few weeks ago I published a blog titled, The Dukkha of Original Thinking, where I mentioned a system I have in place to keep me in within my lane on the path while my mind is preoccupied with the tasks at hand, the Now. The graphic just above illustrates that system.

First off, my real interest is Zen. If I could, I’d spend all of my time away in the desert, away from the hustle of modern life, pondering, observing. But there are great advantages to bustle of modern life, such as lots of food and modern medicine. And besides, every square inch of real estate is owned by somebody. So I require a way to earn a living and contribute value in order to partake in those wonderful things.

Fortunately, I happen to love what I do for a living. I’ve written that programming is My Zen Art. So my profession isn’t just a means to provide the Earthly bodies of my loved ones with the necessities of life. It also serves as an Earthly model helping me towards progression with my Zen studies.

Because my intent is to set me up for a long period of time, it isn’t good enough to simply learn about the new technologies. In fact, I’ve already been dabbling in these new technologies (beyond the current Cloud and Machine Learning stuff) for a few years.

Providing high value means I need to shift to the next gear, genuinely mastering the skills – beyond varying ranges of novice to advanced, and on to “Expert”. But because my brain is finite, there isn’t enough capacity to run my old mastered skills in parallel with these new ones. I’d need to clear some room (empty my cup) for these new skills by hitting the delete key on some of the older skills.

Math

It wasn’t hard to see that raising my math skill to very high levels is key. To non-programmers, it may sound odd learn that a large percentage of programmers are not good at math. Some never learned it, some learned it only long enough to pass the tests in college. I’ve learned and forgotten higher maths several times over my career.

Software development is actually a highly mathematical field. Math and programming are both realms for computing algorithms but in very different ways. Unless a programmer works at NASA or SpaceX, the programmer doesn’t speak and think in math but in “code”. So as I learn to “read and write” calculus, unless I continue to study it every day, daily and intense coding quickly vaporizes it from my brain.

The vast majority of software developers work in IT shops where they mostly maintain and improve current systems or they work to further automate enterprise processes. Now that I work in an IT department, in the normal course of work, I rarely need to tap into even plain old algebra.

Unlike math, emphasis is placed somewhere other than building a solid foundation of truths upon which we can compose derivative truths. It’s more a matter of knowing how to make the necessary changes to code as quickly and cheaply as possible and without breaking anything else in production. Software are tools. Like all other tools, they need to provide a net value to the enterprise. Meaning, the best, most efficient, most elegant solution is rarely the best towards the goal of adding value.

Sometimes, there is hidden math in programming that just looks different. For example, instead of ∑ the rough equivalent in programming is “for loop”. Many of those intimidating Greek letters in math equations are simply functions or constants. Programmers using imperative languages such as C++ or Java (the vast majority of programmers) certainly understand constants and functions, but laid out as a clear logical series of steps with relatively clear variable names, not as a single cryptic equation. If programmers started out as functional programmers, it would probably be easier to understand.

Where heavy duty math is required, particularly machine learning, there are packaged functions written by a minority of developers who are math whizzes. It’s not just heavy duty math that’s encapsulated away in tidy modules. Most programmers don’t even really need to know the basic computer science algorithms and structures, which are also encapsulated in tidy modules written by CS whizzes.

But our relationship with computing machines long ago reached a point where we depend on them for more than calculating tips at a restaurant. As it is with the inability to read, the inability to fully comprehend those awful equations renders the latest and greatest ideas and discoveries inaccessible to you.

Further, the for most developers, the primary driving force isn’t the elegance of code, but return on investment. Software doesn’t need to be the best possible. In fact, sometimes software is purposefully written to be “simple” at the cost of performance so that it can be understood by more. A few seconds a day is easier to deal with than finding a highly skilled developer capable of comprehending the code then optimizing away those few seconds in less time than it will take her.

Anyone can run a linear regression model with a few lines in R or Python. For the vast majority of the time across all customers in the world, that’s good enough. But tougher cases require a deep understanding of math to approach and tune a problem.

Functional Programming and Abstract Algebra

Another looming factor in my field is the rise of Functional Programming. It is the paradigm required to reign in the exponentially growing complexity of the systems we programmers intend to “automate”. Functional programs look more like math than the currently “traditional” object-oriented paradigms.

Functional Programming, along with Category Theory (the math upon which it is founded) is a subject I’m glad I began delving into a few years ago. It’s been quite a struggle, a real shift in thinking. But it’s a profound shift in the right direction for software development. It brings up closer to the ideas of math, science, and yes disciplined engineering.

It’s tough making such a mental shift while I need to continue to keep earning a living using the older paradigms (primarily object-oriented programming). But I found a nice trick. While I try to keep up at least a “working level” of skill with functional languages (most F#), I find I can kill the math and FP birds with the one stone of Abstract Algebra.

In fact, a big hint: If the term “Category Theory” sounds completely foreign, take a step back even further to Abstract Algebra. Trying to learn Category Theory without first understanding Abstract Algebra is like trying to learn anything without understanding the purpose.

For even those well versed in math, Abstract Algebra is hard! The way I had to learn it is through the Richard Feynman method of going back to the beginning once you start to get lost. But it’s where Computation Theory meets back up with math and they are united. That’s powerful. It’s not something to give up on.

Quantum Mechanics

I’ve always had an interest in quantum mechanics and maintained at least a cursory awareness of what’s going on by devouring the pop articles of Scientific American, books by folks such as Michio Kaku, and now the wonderful YouTube channels such as Veritasium, Physics Girl, and PBS Space Time.

But I’ve always realized that unless you’re a working physicist, no matter how much you think you understand quantum mechanics, you probably don’t. It’s such a sophisticated skill that like law and medicine, it’s imperative to learn it through a rigorous formal process and genuine daily application. More so, quantum mechanics works at the infinitesimally small and indirectly at the mind-bogglingly large scale. Not that little sliver in between where our brains are optimized for dealing with things at the scale of normal life on Earth, the things we can see with our naked eyes.

It’s also a field where much of it is very difficult to directly test. Tests can be many layers of inference deep, the result of statistical probability, or just the purely virtual result of math. That is very unlike with software where practically every idea can in the end be objectively validated.

No, I’m nowhere near ready to apply for a job at CERN – not even ready to teach physics at my local high school. So is it just a guilty pleasure for me, just a hobby? Not quite.

There is the saying: We can’t see the forest for the trees. For Zen, I can say something similar: We can’t see the reality of the Universe for Life on Earth. The study of quantum mechanics (even at the pitifully noob level) helps tremendously cut through that lens of the brain.

For this latest reinvention, I initially thought of delving deeply into quantum mechanics since I’m concerned about being left behind when/if quantum computing goes mainstream – whatever that ends up actually being. But quantum computing isn’t yet a clear and present danger to my career.

What I did find, though, is that further understanding of quantum mechanics drives improvement in my understanding of both math and Zen. Quantum mechanics moves high maths from pure abstraction to something real (at least kind of real). Math is the language of physics.

The North 40

I’ve taken a couple of days off to celebrate and kick off another 40 years. Mrs. Hanamoku and I plan to watch the Breaking Bad movie, El Camino (released on Netflix 10/11/2019), along with our favorite pizza.

For anyone interested in meeting me, I’ll be at Eureka in Boise this coming Friday at 3pm. I’m having a celebratory shot of William Larue Weller – I think $75!

In software development, it seems like Version 5.0 is the peak of a product. It’s finally mature, finally getting it right. Further versions just add complexity. By Version 8 or 9, it’s a bloated monstrosity. Perhaps after this, your Reverend Dukkha Hanamoku will take up a completely new career.