Programming as a Profession

Thomas, a friend of mine, recently posted an article on his experiences in programming in an enterprise environment. In particular, he talked about someone called the Career Programmer. Very minimally paraphrased, a Career Programmer is described as follows.

We’ve all seen them. The ones who never coded in school outside of assignments. These are the people who view programming as “just a job,” rather than as a profession. They lack the passion and drive necessary in order to excel at what they do. They don’t strive to refine their capabilities, nor do they maintain an interest in the advancements of their profession. They treat coding as if it were janitorial work. Their knowledge of software engineering and computer science is almost entirely limited to the problem domain that they work within, as they have no desire to venture out. They learn new things because they have to, not because they want to. They ignore established best practices within a language in favor of maintaining familiarity. They refuse to adopt new tools or processes aside from those imposed upon them. They’re just no fun to work with.

Many on the internet (especially Reddit) defended this kind of programmer and lifestyle with vigor.

Programming is a sort of odd career. It’s intellectual, yet, in some sense, labor-intensive. Young people with little actual experience can make a good amount of money after coming out of university and older people with lots of experience can make even more. Choosing programming as a career usually requires that one has some sort of academic background in STEM, though this is not always the case. Beyond that, however, there is usually more that one needs to know: a few programming languages, popular tools used in conjunction with development, libraries that are in vogue, and so on.

Programming, or slightly more generally, software engineering, is a young and rapidly growing field. I am not confident anyone has a solid idea about how things should be done, or even what metrics to use to measure that. The ideal way to program has changed decade after decade. For better or for worse, depending on who you ask, it’s a good thing we are no longer programming in assembly on mainframes, or programming in C for extremely large software projects. It’s better that we have source control, instead of haphazardly slopping files across networks or via disks. It’s better that we listen to compiler diagnostics—which used to not exist—than to ignore them.

The point is, there is no standard methodology or ideology that thoroughly encapsulates the proper way to engineer large software systems. (Contemporary functional programming techniques suggest we might not know the proper way to engineer small ones too!) This is in stark contrast with other fields and professions. There are tried and tested ways of, for example, managing the books of a small business, or doing carpentry, or even engineering physical product packaging. While occasionally new technology is developed in these fields, and paradigm shifts occur, usually it is sufficient to learn the set of skills relevant to a profession, and become proficient at those skills to get valuable work done.

The Career Programmer is typically one who views software engineering as a field like the aforementioned professions.

  1. Go to school, learn some computer science.
  2. Work a few jobs and become proficient in a language.
  3. Apply knowledge to all future jobs.

Very seldom do they take any initiative to learn new things. They’ve paid their dues in college and expect that they should be able to ride the rest of their career free of anymore intellectual busywork that was imposed on them in college.

There was one Career Programmer I worked with that I remember very clearly. He was a C programmer all his life and got his masters degree in the 70s or 80s. During the course of his career, it is as if he didn’t learn anything new. The code he wrote was just C code in disguise written in the way often small UNIX utilities are: global variables, lack of proper memory management, and no error handling. And we were using a truly multi-paradigm language with emphasis on object-oriented and functional patterns. He was a smart guy, but it was as if his mind had not changed since the 80s.

This person was an extreme case of being a Career Programmer, and it brought the entire team down. When a problem can be solved more succinctly, efficiently, and correctly with a one-line map and lambda, he resisted and wrote a loop with global variables to hold temporary state. In an effort to discuss these concepts with him, he would insist that he stick to “what works.” Indeed, in the short term, his code did work, but it imposed the all too common technical debt on the rest of the team.

Not once had he ever talked about a program he wrote on his own. Never did he discuss a cool new tool or technology that might improve the product. One might ask, “why should he?” Of course, he’s not required to, but the project at hand was highly collaborative, and it seemed a good team dynamic was necessary if we wanted to get this project out the door. Even worse, though, he dragged his feet in the dirt if any of us wanted to talk about something new we read which would make a current task a bunch easier. No effort to listen or understand, or a very defensive and without-base “that won’t work [but I won't tell you why].”

What he did talk about is why he can’t wait for his next paycheck.

Over time, it was evident he couldn’t competently do his job well, and he was fired.

I assert that the Anti-Career Programmer, let’s call him the Professional Programmer, has to be one that realizes his field is indeed changing, and that what one thinks is the best way to engineer a system now might significantly change a year from now. The easiest way to cope with that realization is to actually enjoy programming. At that point, keeping up with new technologies, learning new methodologies, and employing new paradigms no longer is a chore, but a motivated pursuit.

Enjoying programming does not necessarily mean one should always enjoy one’s job. While that is extremely ideal, there’s a certain amount of compromise that needs to be made. If tasked with creating the physics engine of the next generation, one should be equipped with the fortitude to sit through long hours writing parsers and serializers for novel data formats, or writing that high performance three-dimensional vector library tailor fit for your uses.

I might even make the somewhat audacious claim that even when presented with the most boring task to solve, the Professional Programmer will find a way to make it interesting or inspirational. (Though, especially in very strict environments, this might not be so easy.) I might also claim that if one looks hard enough, and has persistence, he or she will find something she enjoys most of the time.

The good news with all of this is that times seem to be changing. The traditional work mindset seems to be getting displaced by many younger startups, that seem to be actively screening for things on the personality and extra-professional facets of prospective employees. In a few places I’ve interviewed at recently, almost all of the programmers evidently, truly had a passion for what they do. Sometimes technical conversations would get derailed and move into the tangent space, talking about technologies or technical ideologies that aren’t directly relevant, but nonetheless are a good indicator of whether either party is willing to think out of the box.

In response to those who concluded that it would be best to give up the idea of working with interested and enthusiastic people in response to Thomas’s post, I advise you keep your chin up, and realize that things are capable of being better. If you see yourself as a Career Programmer, my suggestion is this: consider looking out for an alternative lifestyle and career. (If you made it as far to be a programmer, then surely you are capable of other careers. QA, DBA, analyst, …) Do something you enjoy. It’s not impossible. I realize it’s not a cakewalk for everyone; not everyone can find another job easily and not everyone is mobile.

If you decide to stay in the industry, don’t let your cynicism escape you to the detriment of your team, and be open to learning new things.

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you post, please prove you are sentient.

What is 8 * 5?