A Programmer's Journey
by Frank Riccobono
This is the story of how I first got started programming and some of the milestones that lead me where I am today. It may be a bit too self-indulgent and dripping with nostalgia, but after listening to a bunch of other programmers share their stories, I wanted to get as many of the details written down now, while they're still somewhat fresh. Some of the earlier details are already pretty fuzzy.
I was fortunate to be introduced to computers at an early age. According to an old school report I found in my hoard, we got our first family computer when I was four. You probably wouldn't take my dad for your typical computer geek, but he latched onto the technology when it started transforming the workplace. He, in turn, taught me the basics. By the time I was five years old, I already knew a handful of basic DOS commands. (At that point it was limited to switching directories and launching games – Reader Rabbit was an early favorite). By eight, I was using Microsoft Office to write silly short stories and PowerPoint to make “art."
I started programming almost by accident. Although I liked school and my teachers, I wasn't quite a star student in my earliest primary education. I hated coloring inside the lines, my penmanship was atrocious, and I've always tended towards absent-mindedness. I would forget to do homework or frequently leave books at home. That changed once I got to third grade and even more so by fourth and fifth. That's the point where school became less about learning behaviors and more about acquiring knowledge. I was (and still am) insatiably curious, and this new chapter of education was what I had been waiting for. I was also very impatient. I would look ahead in my textbooks, anxious for the next lesson even before the current one had fully sunken in. What was worse was that many of our books were longer than we'd be able to cover in a school year. I found myself particularly drawn to the final chapters that we would otherwise never see.
One day in fifth grade, something in the appendix of my math textbook caught my eye. It was an extra credit assignment of sorts written in a mono-spaced font. The instructions said to type the instructions into a program called QBasic, which at that time was still bundled with Windows. I don't quite remember what the program was, but it was something simple like a coin flip simulator. Whatever it was, when I entered the instructions, it worked! I was experiencing some new kind of magic that I didn't fully appreciate at the time. I flipped through the book and found a few more extended code listings and tried them out. I was exclusively following the textbook instructions, though. I had no idea what any of the keywords meant, and it never occurred to me to change anything or to try to write my own program.
Another joy at that time was the annual Scholastic Book Fair (I’m a nerd if you haven’t figured that out by now). A year or so after my first foray into QBasic, I found a book and accompanying CD at the book fair called “Learn to Program BASIC” by Interplay. In it, a bizarre-looking cartoon character named Media Man( reminiscent of Clippy) taught you through wacky video clips how to write a dialect of BASIC developed by the game company. I learned about strings, subroutines, sprites, arrays, and much more. I still didn't stray far from the tutorials, but I was able to internalize much of the material. In particular, programming in an XY-coordinate system gave me a leg up in math class when we started learning how to plot various graphs. It also helped in Computers Class where Sr. Blanche was introducing us to Logo.
LTPB felt more like a video game than a useful tool, though, and I lost interest when I’d finished all the lessons. I still never thought to try creating something original, and I did not do much more than that until another coincidence occurred in high school. I was chatting with a friend at the end of freshman year, and we somehow got into the topic of programming. His father was a programmer, and he was learning Visual Basic 6. I'd never heard of it, but it had Basic in the name, so I assumed it was similar to what I'd seen before. He agreed to teach two other friends and me. The four of us had bold plans to create a video game company that summer, powered by VB6. Those plans never materialized, but I did learn the language and my friend, the ringleader, did write an Apple Catcher game that "went viral" in the sophomore class (before "going viral" was a thing).
Part of the problem with our ill-fated video game company endeavor was that we couldn’t agree on what type of game to make. I had suggested an RPG, not imagining at the time, how much work was involved. I spent the summer learning a bunch of things including how to do Bit Block Transfers (BitBlt) to remove the backgrounds from sprites (something I missed about LTPB), how to generate tile-based maps, and, most-ambitiously, how to implement the A* path-finding algorithm. When that last one (mostly) worked, I was ecstatic. Mind you, at that time, I still had no sort of formal training.
When the college admissions process started in my junior year, I received an advertisement for a summer program at one of the schools I was considering (Stevens Institute of Technology). The program allowed high school students to take an online college-level class over the summer. I signed up for CS115, Introduction to Computer Science. I didn't know what "computer science" was at the time, but the syllabus mentioned programming, and that was enough for me. The class involved learning Java, which had enough in common with VB6 that I was able to pick it up pretty quickly. That class convinced me to choose the heretofore unknown Computer Science as my major when the time came.
I ended up attending Stevens for college. It was a blur of languages including C, PHP, Assembly, Scheme, Matlab, MySQL, and even a smidge of COBOL. Like most graduates, I thought all that was everything I needed to know about programming. One concept I later learned was conspicuously missing from the CS course load was the idea of "Legacy Code" and how to work with it.
My first job out of college had me working with a several-years-old Java project that had been cobbled together by outsourced contractors. I can't say too much about the experience due to confidentiality agreements. It suffices to say that academic knowledge of Java did not prepare me for J2EE, or for making sense of tens of thousands of lines of code and a bunch of terrible variable names. I was not given a lot of guidance since our lead developer worked remotely and only at night. And my conservative inclination left me afraid to change much. I did eventually get to the point where I could contribute to the project. I was writing software for a business, but I had no real sense of what business software engineering entailed.
The next milestone didn’t come until three years later. There were two sources. First, I was taking some graduate-level classes in Natural Language Processing, a topic that had long interested me. As bad as corporate code can get, academic code is generally worse. PhDs and grad students typically write software for an upcoming paper and, unless their discipline is software engineering, they usually don't write with maintenance in mind. "Battle-scarred" as I was by the corporate world, I rejected this writing style and strove to try to make any code I wrote for those courses as clean as possible. This goal required reading lots of tutorials outside of class, but I think it paid off. Most of those courses required us to code in Python, and I made an effort to learn the Pythonic way. For the first time, I wasn’t just thinking about whether or not my code worked but also how it was structured.
The other influence was a part-time gig I took on in between grad school semesters. One of my college professors contacted me regarding an opportunity with a startup looking for an intern. They were developing a Ruby on Rails e-commerce site. Ruby and Python had enough similarities that I was able to pick up the former pretty quickly, but Rails was eye-opening. I had never used a framework. I was fascinated by tools that not only reduced boilerplate code, but that also imposed structure on the application.
On top of that, the team was also using Capistrano to automate building and deploying the app, and they had AUTOMATED UNIT TESTS through rake! I had used simple makefiles in my college C-programming days, but, for a technology aimed at creating efficiencies, programming and testing of programs always seemed very manual to me. My college professors had even convinced us not to use IDEs when learning because they introduced too much magic. The idea that you could introduce automation and tooling seemed revolutionary.
In the end, the startup didn't work out (long story for another time, but no hard feelings toward anyone involved). In the meantime, I found myself in the lead developer role for that software product I had started working on after college. The time had come to put some of what I'd recently learned to use. Over the next few years, a junior developer and I worked to wrangle the legacy code. We imposed structure where there was disorder and wrote automated tests where there had been none. It was exciting.
Today we’re working on a new system. We’re using technologies like Hibernate in the back-end and React in the front-end. It's been a bit of a paradigm shift from never using any frameworks. There are various challenges and successes every day, but the best part is there is always plenty to learn. I can still be that curious kid, stealing furtive glances at advanced topics, that I was when I started.