This post is part of a series interviewing veteran developers, asking them questions about their journey to tech mastery and sharing the advice they have for those getting started.
This week we’re talking to Jonathan Hall. Jonathan started out as a self-taught developer and is now a consultant and blogger who helps small teams benefit from DevOps best practices. He publishes a daily newsletter with advice about implementing DevOps, and you can follow him on Twitter @TinyDevOps.
Let’s learn how Jonathan got his start in programming and how you can be a self-taught developer, too.
Stack? How long have you been doing it?
These days, I spend a lot of time helping teams improve their effectiveness, learn how to focus, and generally get better at software development. But when I still write code, it’s almost always in Go. And for the past five years or so of my programming career, I focused on Go programming. For about 10 years before that, I focused mostly on Perl. I started professionally writing code in 2006, so about 15 years.
What made you want to go into programming?
My father was a freelance magazine writer and book author, and he worked from home on a Commodore 64 he used for word processing. One night, when I was 8 years old, after I had gone to bed, I heard him typing, and I heard the computer making strange beeping noises I was unfamiliar with. In violation of curfew, I got out of bed and went into the living room where he was typing to investigate. “What are you doing, Dad?”
His response: “I’m typing in some programs from the manual. You can look at it tomorrow. Go to bed.”
From the next day, I dove into the user’s manual (which came with simple BASIC programs back then) and entered every one into the computer. When I finished that book, my parents took me to the local public library, where over the course of a few years I checked out every book on the topic of BASIC programming (many more than once).
I’ve been hooked ever since.
What were you most worried about when you made the decision to pursue a programming career?
I don’t think I ever made this conscious choice. In fact, at one point, probably during high school, I remember thinking that maybe programming wasn’t for me. There were too many little details that were hard to manage. So that was definitely something I worried about, and it even (temporarily) turned me away from software development.
I still enjoyed it, but I started making a shift to other technical areas. I ran a small dial-up ISP and free email service during high school, so I spent a lot of time focused on that, learning networking and server administration. My customers would use a modem to dial over standard telephone lines to connect to my servers sitting in my bedroom. Anyone had access to a free email address this way, and customers who paid could have full internet access—all before broadband and always-on internet was popular.
In fact, when I started my first programming job in 2006, I was hired as a network administrator and became a programmer almost by accident when the lead developer suddenly quit and someone had to step in.
What surprised you most at your first programming job?
I was too naïve to be surprised. But just a few weeks after starting, we had a major software glitch. We were selling spam-filtering software, which was installed in our customers’ data centers (this was before cloud-based software as a service was a popular business model). The programmer on the project shipped a broken release that caused all mail to stop working for all of our approximately 150 customers.
It was quite a fiasco. But in the end, this incident has proved to be a catalyst in my career for focusing on building more resilient software and teams.
Who has influenced you the most so far in your programming journey?
During the early years of my programming career, I didn’t have the benefit of working with more experienced developers. I guess this was both a curse and a blessing at the same time. On the one hand, it meant it probably took me a lot longer to learn things since I was doing everything on my own. On the other hand, it forced me to learn how to teach myself.
So, during the first decade of my career, probably the most influential people were authors and bloggers. Joel Spolsky’s blog Joel on Software was a huge influence. I still fondly remember the time when I was binge-reading his blog. And I think most of it is still relevant today, so anyone who hasn’t already read it can probably get almost as much insight as I did back in 2008 or 2010.
And next to his blog, I can easily say the most influential book on my career was Working Effectively with Legacy Code by Michael Feathers. This book changed the way I looked at code and the value of testing. It eventually led me to adopt test-driven development, which has made me a much better and (contrary to popular belief) faster programmer.
What programming reference materials can you not live without?
The internet. LOL.
Of course, like every developer, I use Stack Overflow and Google all the time. But could I live without them? Sure. I did. For many years. I learned programming at the public library, so when I didn’t know how to do something, my options were to keep experimenting until I figured it out; to wait a week to get back to the library, read another book, and hope it helps; or to give up.
Naturally, this meant I spent a ton of time experimenting until I figured things out. On rare occasions, I did give up.
The “fast-food” programming reference that is the internet I fear has nearly killed this “keep trying” mentality, except among the truly dedicated.
What’s something that no training/bootcamp/degree could have prepared you for?
Well, I’m mostly self-taught. Although I never got a degree, I did take a few programming courses in university. The title of one I most vividly remember really sums up what I believe is the focus of most computer science education: Data Structures and Algorithms.
And while few people ever truly care about the computational complexity of bubble sort versus quick sort, it’s essential to understand that there is a difference and to learn how to investigate those differences if and when they actually matter. So, I’m not downplaying this area of study. The problem is that this isn’t want most programmers care about for the first few years of their career.
What matters so much more are things like how to write readable code, how to write good tests, and how to use Git properly (a surprisingly complex topic that even many senior developers haven’t mastered).