When talking with people about what I do, it’s obvious that it’s difficult to explain quickly in a way that they understand any of it. I’ve written a bit about that here: Agile vs. Formal Management Systems. What’s even less obvious in a casual conversation is how one could even get to doing what I do, and whether it would be worthwhile. This is the kind of thing that will have to be updated periodically because I’m definitely not standing still. I’ll leave this strictly a description of education and professional development. That’s certainly not the end-all — it’s important to be able to manage what you build and earn, I talk about that here: Phases of Investing. Motivation is also important, but that’s an enormous topic.

In my early years I was a console and computer gamer. I still would be if it didn’t take so much time and produce so little. Gaming was much more a solo activity back then as Internet gaming wasn’t as feasible given available technology. We did figure out how to play Doom multi-player with a modem connection and later we got a couple of computers linked up to play Starcraft and other titles.

I wanted to make computer games. My friends and I would bounce around various ideas for games and talk about making them. We didn’t really have an idea where to start, but I knew programming was involved. I started playing with MS-DOS batch file scripting and made a few small useful things.

In high school I was lucky enough to have programming classes available to me. I jumped on them. There we learned the (even then) relatively obsolete QBASIC and got an introduction to C++. I think high school programming classes are common-place now, and I would encourage anyone to take advantage of them.

At age 16, I started to work at a local retailer. This isn’t the first job that I had, but it is the first one that I took seriously. I would have been happy as a cashier or pushing carts, but they wanted me at the service desk. I didn’t like it, but I did it. In retrospect, it really helped me to figure out how to interact with people better — especially people who were starting off upset. I probably owe a lot more to that experience than I typically give it credit.

I went to university and studied Computer Science and Mathematics. I wasn’t sure what I was getting into when I started, but it turned out that I liked the Computer Science side a lot.

Throughout my school years I continued poking at programming projects — mostly with the goal of making games. I picked up PHP and MySQL to make a small, ultimately unused, web site. At the time, there were several massively multiplayer HTML games that I thought I could take a swing at.

This small web site was key in helping me land my first programming job during my sophomore year. It demonstrated some ability that a resume would never communicate alone. I ended up helping a small company build and manage their web applications. Looking back, it was pretty poor work, but it did help them. That job beat into me the value of testing, revision control, and clean code in ways that the classroom had not yet been able to emphasize. There were very lax controls around the deployment of code, and I hadn’t developed nearly the required level of discipline for checking my work. It bit us badly. The complete embarrassment of bringing the productivity of an entire office to zero is something that most kids don’t get anymore. It changed me. Before long I had a script for verification that was better than anything they ever had. Other hiccups encouraged me to bring revision control (CVS) to the office.

Realizing the valuable skills I’d learned in just a few short months on a programming job, my view of classwork dimmed. I got through my classes with little enthusiasm, but they were definitely good for me.

I took a generalist approach in school. I tried a little of everything. Before I left undergrad I had seen the basics of operating systems, compilers, security, databases, networking, graphics, software engineering, algorithm analysis, and digital logic. The advice seemed to be to specialize, but that didn’t appeal much to me. Why specialize if you don’t know why you’re specializing? I think I’ve since used aspects from most of those classes. It was worth it.

In between classes I figured out how to use Linux. I started with Slack 8 (not recommended), then tried Mandrake, and eventually settled on Debian. With that I set up a small home network made up of old computers that I had collected over the years. That taught me a lot about networking and some sysadmin basics. Today it’s easier to get started with Linux. The graphical user interface (GUI) on those older versions wasn’t as developed as it is today, so I stuck with Windows for my day-to-day. Today I’m almost exclusively using Ubuntu.

My first job out of school was programming small embedded Intel 8088 and ARM7 processors. They were plugged into custom boards designed by the company. My first project was to work with the hardware engineers to design a new board using a relatively “new” interface called USB. Embedded development was new to me, but the new processor and board had so much more CPU capability and memory available, that it rarely gave me a problem. Virtually every significant piece of code I wrote for the board had an accompanying program to test it. I was almost doing unit tests without knowing it. We also created a standard hardware testing harness and accompanying software to verify that all the parts of the board were communicating as expected.

In the 3 years I worked at this job, I grew from a competitive, passive-aggressive, pain-in-the-ass know-it-all to a much more mellow, more humble pain-in-the-ass. Partially that was due to doing meaningful work over a longer period of time. That’s a difficult experience to find in school. I also credit the fact that I was working with a wide diversity of experience. Most of my co-workers were at least a decade older than me, and several had started working at that company before I was born. They had a long view of their work that had rarely occurred to me, but I slowly adopted it. That’s also a difficult experience to find in school. There was also a wide variety of professional backgrounds: mechanical engineers, electrical engineers, embedded engineers, UI engineers, chemists, biologists, and veterinary experts. The spread of domain expertise was so varied that I regularly had to rely on other people to get my job done. Some level of humility was a requirement. That’s also a difficult experience to find in school.

In 2007, another opportunity came along, and I jumped at it. This time I would be working on some compiler-like tools. Specifically, we were taking programs apart and reassembling them with some modifications. Testing was crucial to this company, and they had the best product validation practices I had seen to-date.

During this time, I found a renewed appreciation for classwork. I could see that my classroom training in the more abstract topics like algorithm analysis was an asset that some others were lacking. It also hit me that the abstract concepts taught in school will never announce themselves as necessary. They just appear as a lot of work that the knowledgeable know how to do faster and better. It reminds me of the people who claim they’ve never needed some kind of math. Strictly speaking, you don’t need math, but you’re probably doing a lot of extra work without it. Throughout these years I took advantage of computer science and math classes at the nearby university. I have not regretted it.

The next group I worked with made a distributed system that coordinated data across hundreds to tens-of-thousands of sites. Their development practices needed some help, and I was more than happy to provide it. Their historical decisions throughout the product’s history had made it a very support-heavy organization. The support team was well-staffed and very busy. Tier-three support was a phone that the engineers traded amongst themselves for some extra pay, and it was a nearly guaranteed angry, late night phone call.

We wanted to get ahead of the support calls. I and a couple of other engineers led an effort of infrastructure and testing improvements. Product deliveries went from hand-assembled to automatically generated. The database went from a mish-mash of direct table edits to a set of scripts that were guaranteed idempotent through arbitrary upgrade paths. Unit testing was added at every level. Interface testing was introduced every time one was touched. The UI also got a lot of testing attention.

The customers went from regular failure on installation (not to mention downstream problems) to zero installation failures in about the space of a year. It was remarkable. At one point I noticed someone with the tier-three support phone, which I had been avoiding. I asked him how it was. His answer: “It never rings, so it’s free money.” That was a moment of silent celebration. We had spent a lot of time to make things better for the customers, but I hadn’t realized that we had almost completely transformed the despised support phone into a paperweight.

Once the raging fires were squelched down to contained bursts, I put some effort into learning how to do large-scale communication correctly and started collaborating with local grad students on what the right design would look like.

Unfortunately, circumstances worked out such that the parent company saw our office as unnecessary and closed it — perhaps we engineered around the urgent workloads a little too well.

I ended up working on more build tools afterward. I would alternate between being a feature developer and team lead. Then the company signed a deal requiring compliance to a formal quality management system, and my name came up as someone to assist with the deployment. At the time I thought it would be a good way to drive the company and products toward better practices through measurement and analysis, so I jumped at it. The job ended up being a lot of paperwork and document management, but the spark of a data-driven effort remained, and I drove on. One of the greatest benefits of this position was that it gave me the clearest picture of company organization and management that I’ve ever had, and I find it’s very relatable to the concepts learned in computer science.

In retrospect, my career path seems meandering. I went after the work and positions that seemed right at the time, but there was no single theme to the motions except “Make Things Better.” Perhaps a more deliberate drive would have turned out better in some ways, but I really have no complaints.

Side Projects

In between jobs, I’ve never been not working on a side project — most of them never published. Sometimes I would find an open source project that was making my life easier in some way and start making the changes that I wanted. Other times I just worked on things I was interested in at the time. Sometimes it supported my job, sometimes not. Professional work is often about negotiating the trade-off between doing things well and doing them fast — with a lot of business pressure on fast. On the side I would often explore ways to do things well, and it usually worked out that the lessons learned could be applied to the job.

Working from Home

If you’re able to get work done without anyone looking over your shoulder, you’ll have no problem finding a company willing to let you work wherever you want. I’ve heard that remote work actually makes people more effective in some cases, but I’m not so sure. The corporate world seems to go back and forth on this. As nice an idea as it sounds, there are some complications.

The biggest one: isolation. I didn’t realize how much I got out of the daily office chatter until it was absent. There is no happy hour with the co-workers, and office events are much harder if not impossible to fit into the schedule. You’ll frequently find that you’re not aware of things that are happening in the company. Some regularly scheduled chat times might go a long way.

To make things worse, if you work and are a family man, you may find that 80 hours of your week are spoken for, so there’s little time to develop any kind of professional relationships in your area. I would recommend you find some relevant groups to interact with and make a point of doing it. I’ve found that there are valuable business relationships to be found among the regulars at coffee shops and breakfast joints.

Another problem: infrastructure. Residential power and communications aren’t as reliable as commercial, I’ve found. I’m usually dealing with 2 multi-hour power outages per year. It’s manageable, but annoying. Communications outages are similar. The answer is: redundancy, but it’s extra headache that you typically wouldn’t have to deal with in an office.

Things I Might Do Differently If Starting Over

I realize that things have changed a bit since I went through school, and I think there might now be better ways to do it. For someone starting today, I would recommend Python as a starting language. It’s relatively simple and there’s a lot of online help for getting started.

I might also suggest a hard look at the online learning resources. There is an advantage to having a group of peers trying to learn the same thing you are: it brings out the useful questions. However, college tuition is getting expensive, the colleges are usually not where you are, and communications technologies are
constantly improving. If you can find a small group of locals interested in the same online course and maybe someone more knowledgeable to guide the group, you’re set.

If I were starting again today, I would put more focus into freelance work sooner. Freelance gives you the freedom to look for interesting work in a way much less restrained than an employer would typically allow. Full-time employment provides income security (but be cautious). Full-time employment is great when you don’t know what you’re doing, but after a while it can feel constraining. If you can get someone to pay you to do exactly what you want to do, there’s nothing better.

I would publish more hobbies. You may not think they’re valuable or clean enough to present to the world, but others may disagree. If no one can ever see it, you’ll never know what something is worth to the world. I’m improving this as I write.