Why a career in computer programming DOESN’T suck

This is another blog post in my series “Developers need to stop whining and start working.”  Okay it’s not really a series, but it should be.  Heck, it could be an entire blog.

I stumbled across a blog that was arguing a “career in computer porgramming sucks.” At first blush, I assumed the title would be a way to get a lot of people to read it but basically boil down to “it’s a lot of hard work, but pays off in the end.”  However, that’s not what it was at all.  I’d suggest you first head over and read (or at least skim) the blog.

Permanent Knowledge Capital

The author argues that one reason that one reason why programming sucks as a career is that it dwells in the area of “temporary knowledge capital.” It’s an argument I’ve heard numerous times.  Put bluntly, the world of programming is changing at a rapid pace and it’s hard (or impossible) for a developer to stay on top of things. As a result, the knowledge that we learn is temporary at best.

I’d concede that if the knowledge of programming was all temporary, that would suck. However, I don’t believe that’s the case. Before we look at programming, however, let’s take a look at electrical engineering.  It was where I was fomrally trained, and my dad before me as well.  From the time that my dad entered university until now a lot has changed.  He was one of the last classes to learn both vacuum tubes and semi-conductors.  By the time I graduated I not only learned semi-conductors, but also digital signal processing and digitial design.  And yet, there were a few things that remained constant throughout my studies.  For example, Kirchhoff’s voltage law, Ohm’s law etc have never changed. There are chips that exist today that never existed when my dad was doing circuit design.  But can he use them? Absolutely.  Why? Because he learned the theory, the laws of how electricity work, and not just the inputs and outputs of a particular chip.

So how does that apply to development?  We’ve come a long way from malloc’ing in our C routines, or jump’ing in our assembly programs.  I write primarily in .NET and have not worried about memory management for quite a while. (That does NOT mean I write bloated routines, but rather, I don’t worry about explicitly cleaning up my memory footprint.)

Much like the author of the original blog post, I started out using BASIC (QBasic for me, then VB3 and 4.)  Most of the syntax that I used in those days has long since been forgotten (and my coworkers are very thankful) but I learned some lessons in those days.  For example, I learned that if I want to write a game using a series of If/Else statements I’m going to be in trouble.

But there’s lessons learned even more recently.  From 2001-2007 I wrote MFC C++.  I’d be lucky to do much more than a Hello World in C++ at this point.  However, there is a lot that I learned on those projects that stick with me to this day.  Some of it has to do with how I approach writing software, and some of it has to do with how I debug problems.

However, there is one constant in all of software: Users. I have yet to write a piece of software with no users. (Ok, I’m sure I wrote some stuff that was never really used, but the desire was always to have users.)  One difference I’ve seen from young developers and more mature developers is that more mature developers tend to have a better understanding of how users will operate and will help mitigate issues before they arise.  They have wisdom and that certainly isn’t “temporary knowledge capital.”

Prestige is What You Make It

The next reason that programming supposedly sucks is that it’s a low prestige job. The author cites some annecdotal examples that state that people from higher classes don’t go into programming.  But that’s really besides the point.  In my very brief (12 year) career of being a software developer I’ve worked in the following settings:

• In a cube
• In a cube with 1-3 other people
• In an office
• At my home “office”
• In a bull-pen setting.

I received my patent while working in a cubicle with 3 other people.  I wrote some really bad code a lone in my office.

Point is, different companies work in different ways. For example, Fog Creek software sets their ideal of each developer having a private office. Other companies, take advantage of developers and lump them all in one big open room with no structure.  But then again, it’s up to you to not go work at places that you feel are taking advantage of you.

Globalization of Computer Programming

The next point is that it’s easy to ship programming off-shore. As a result it’s causing a “foreignization” of development.  This is an argument that I’ve heard several times, but in my experience I haven’t run in to.

The author is absolutely right, we can’t outsource law jobs, or doctors, but we also can’t outsource trashmen, so I’m not sure that not being able to outsource means the job is prestigious.

Further, with the globalization of computer programming, each developer is tasked with being competitive.  When I left my full-time job to attend seminary, I worked remotely for my company.  They used me as a test-bed.  They wanted to out-source some testing work to a place in India.  They tried, and failed.  Yet for almost 4 years, I was able to work out of my house, 600 miles away (and it really might as well have been in India.)  Why? Was I cheaper? Not even close.  But I was producing a better product. I was writing better code, better documentation, and working hard to prove it.

There is a chance that someone will hire an overseas company to write their application for them, but at the same time those are going to be the people that you wouldn’t want to work for anywhere, because they’re always looking at the lowest cost.

One way, I believe, to stop or slow this down is to be more professional here in the United States.  I can offer you something as a software developer that someone in another company can’t.  I understand your culture and your customers.  I can write high quality software, and swing by your office on a few minutes notice.

If I can’t distinguish myself from a faceless void in another country, I should resign right now.

Panacea of Law?

When I first read the section on good professions, I was reminded of an internship I did back in 1997. I had just finished my first year at University Missouri Rolla, and was working for a company in Kansas City.  I was hired to install software, wire cabinets, and just do grunt work that the real engineers didn’t want to do.  But during that time I was talking to one of the engineers, he told me I should drop out of engineering and get an MBA.  I asked him why.  His response? “How many millionaires have an engineering degree, and how many have an MBA?”

To be fair, there were a lot fewer engineer millionaires pre-dot-com.  However, my response to him was “How many MBA’s don’t make 40k a year?”  The thing with MBAs is that they’re not really worth anything.  The people that get the degree are what make it valuable. And let’s be honest, that’s true with engineering as well.  I’m not worth more because I have a BSEE.

Additionally, I found it interesting that the author mentioned law as a better career to enter.  In part because I’m convinced there is a “temporary knowledge capital” in law as well as programming.  The law is constantly changing.  Take the Tax law, for example.  Why is there a new version of TurboTax for sale every year?  It’s because there are new deductions, new credits, and old loopholes closed.  Each and every year there are changes to the tax code.  That’s just one segment of law.

The changing laws would be a lot like programming syntax for a developer.  No CPA is getting a job for being an expert on the tax code from 2003.  But if someone understands the fundamentals of tax law, they’ll be relevant in 2003 and 2013 and 2023.  So too with developing.  If you truly understand the fundamentals, you’ll be valuable regardless of the syntax you use.

So What is a Good Profession?

Fall 1996.  I’m sitting in the civil engineering lecture hall on the campus of University Missouri Rolla.  It was my Freshman Engineering class.  The professor did the old “Look to the left, look to the right, chances are these guys will not be with you when you graduate.”  He then went on several times to implore the students that if you didn’t enjoy engineering, to drop out now while you could easily transfer to another programming.

At that time, the average starting salary for a graduate of my university was around 40k.  Petroleum engineers typically started around 50k and civil engineers started around 35 or so.  It was good money, and depending on your field, it was really good money.  But the point was always there, it is too much work just for the pay check.  At the time, I assumed he meant the physics classes, the circuits work, the derivations in Electromagnetic Fields and Waves.  But now I realize that professor meant that working for 35-40 years in a field you don’t like isn’t worth it.

The author is right, to a degree. Programming does suck.  I spend long hours working on problems.  Sometimes I work until I’m past sleepy.  I get stressed.  I get bored when things are going slow.  But I wouldn’t do anything else.  And that’s why it’s the right career.

People that go into patent law because there’s prestige, no “foreignization”, offices not cubicles or whatever else, are going to be writing about how patent law sucks.