The road to and from and (hopefully) back to simplicity
I wrote my first computer program when I was 8. It was a simple adventure game written in BASIC, a mess of
I continued to write games and curios into my early teens. I wrote text adventures and arcade ripoffs. I hacked at biometric data collection using a busted set of paddles and mixed mode graphics. I designed and built a large (but clunky) side scrolling adventure game using only a set of customized fonts. I plagiarized code from magazines and hacked at my machine until the wee hours of the night.
I learned almost nothing about writing production code in my early years. And while discovered that I loved to imagine and build things in code, I barely brushed against the principles that would later be required to make real learning possible. My skills didn’t improve much either as my time was largely unfocused.
I was a hobbyist. I discovered the joy and love of software, but entirely missed the nuts and bolts of it. I didn’t learn anything about the science, the skills, the mechanics, or the business behind software, which limited how much I could learn and improve. It’s a limit that prevents most of us from eclipsing hobbyist, even those who end up making a profession of it. Failing to escape hobbyist damns you to a shallow relationship with understanding.
“You want to know how to paint a perfect painting? It’s easy. Make yourself perfect and then just paint naturally.” #
But it’s more than just knowledge. After you discovery where to start learning the right things, you must then endeavour to follow it with practice. Failing to practice leads to a lack of reinforcement and eventual atrophy.
A sideways journey
I shied away from computers as high school progressed. I was bored with my slow progress and was naturally gravitating away from solitary activities. Instead, I spent time with friends and worked in various menial jobs. I enjoyed working too, especially in restaurants where I was making food with my hands (even fast food).
I made my way to college, and wandered through it mostly without direction. I passively avoided computer science, though I found myself programming in various capacities anyways. I wrote software for restaurants, built data analysis code for agriculture and biology courses, and coded simple tools for print operations. I was still sure that I wasn’t a programmer, so I continued working in restaurants and studying anything but computer science.
I also considered myself an artist at the time, even though I spent very little time being artistic. I would binge on art from time to time, especially enjoying block printing and photography. I also enjoyed sketching, though I never reached the escape velocity required to do much more than doodle icons and simple caricatures.
It was around this time that I realized that I wasn’t really very good at anything I did. I mistakenly suspected that I wasn’t trying hard enough, so I doubled down on my studies and changed my major to computer science, as it seemed somewhat inevitable.
“The truth knocks on the door and you say, “Go away, I’m looking for the truth,” and so it goes away. Puzzling.” #
Unfortunately, trying harder was a vague proposition, and I found myself bored when my lack of skill eclipsed my need to produce useful software. I did well in my studies and project work, but I didn’t really learn how to write software despite writing quite a lot of it.
A first glimpse
I developed a schizophrenic relationship with making things though college. My mind would race at the prospect of building something, excited to get started. I would enjoy the tedium of construction and I would revel in finishing. But at some point in every project I would realize how far from great it was.
I tried to ignore the reality: I didn’t enjoy thinking about how much I didn’t know and how limited my abilities were, even though the thinking about those things would have pointed me toward improvement sooner. I continued along a superficial path of creation for many years. It was a dichotomy that would follow me for some time, the excitement and passion for making things, and the inevidable disappointment of knowing they weren’t great.
I continued meandering through college, bored with my classes and part time work. I left my program early for an opportunity to work in the real world, hoping that it would nudge me out my rut. And it did.
When you want to hurry something, that means you no longer care about it and want to get on to other things. #
My first few years as a full time professional were liberating. I was working as part of a team where my lack of skill and knowledge were no longer limiting. We were given simple, defined problems to solve, mostly tied to specific customer support requests. The team was knowledgable, at least in terms of how to solve specific problems, so I was able to start and finish projects quickly and with some quality.
Smaller, more defined work was the first step to successful practice. Our time was limited by customer deadlines, which forced us to keep our approaches and designs simple as well. Combine small and simple with compiled languages, and we kept the code clean too. This principle drilled a few things into my head that were important, though I wouldn’t fully grasp them until later.
This first real software job was important in another way: it showed me how little I knew. Both through the practice of churning out a release every few weeks and the fellowship of our early staff I came to realize that I was still just a fledgling in the craft. And as luck would have it, the employer embraced continued learning and they graced us with a very ample book budget. I spent every penny I could of that budget, and read every book cover to cover numerous times. I felt like I was finally learning.
Of course I had already learned more than I realized, but by this time I had some experience and perspective. My experience helped me focus the time I spent learning, and it helped me filter the learning materials too. Both focused time and quality inputs are important for learning, as is having enough perspective to see the value in what’s being learned.
After my first few years as a professional I became aware of how making things affected me. I learned that when I made something the experience was deeply satisfying. And as my results improved, the experience was better. In short, making things felt good. Getting better at making things felt incredible.
“Logic presumes a separation of subject from object; therefore logic is not final wisdom.This is Zen. This is my motorcycle maintenance. ”
There is a problem, however, with associating satisfaction with making, especially when it’s your profession. Sometimes you are forced into unsuccessful projects, either through simple missteps or through external pressures. When we are attached to the our successes, our failures become part of us too, and we suffer emotionally and physically.
Over the years I’ve had to fight the attachment to the things I make. On one hand there is great satisfaction in the process. On the other hand the failures eat away at who you are. Conflating satisfaction with value is an expensive mistake that I’m only now learning how to avoid.
I am neither my success nor my failure, nor am I the journey. In the end I am who I choose to be, in how I allow the experience affect me, and how I perceive the journey itself. I’m not suggesting rose-coloured glasses, rather that you accept the reality (whatever it be) and choose who you become (or who you don’t become), without prejudice. This plays for both success and failure, and for the things in between, as lot of what we do in computing is on the long road between inception and shipping.
The sum of the parts, mostly
I look back on those early successes when I get lost in software development. I also look back on the time when I started to understand learning as a reminder of what I can do when the inputs and circumstances are just right. These experiences help me find my way back to reality, inspiring me, and reminding me what can be done.
Looking back on some of my earliest, successful projects also gives me a sense of perspective, one I could not have found at the time. Those early projects were not as bad as I thought they were. They were a balance of pragmatic, functional, and creative (at least the ones I remember). I often find myself wishing I could find that balance again, a balance that I was forced into by my lack of knowledge and experience, a balance that is now more difficult to find.
Some of our art is in learning how to learn, learning how to practice and hone our craft, and in exercising our experience and knowledge. The craft is also in finding that child-like simplicity, where the balance hinges on the limitations more than the infinite possibilities, and where that youthful passion is clearly seen in the things we make.