Skip to main content

What is Programming?

I was thinking about what I'd talk about if I ever gave a presentation at a conference and then I thought: "Hey, that's what blogs are for."  So here's the basics of what I'd talk about.

What is Programming?

A lot of people get into programming without really ever asking this question.  Honestly, most people just assume I'm some sort of computer version of a magician, or worse, a computer version of a factory worker.  I like to think of myself as a techno-mage, but to each his own I suppose.

The sad truth is that I've met programmers who couldn't correctly answer this simple question.  I've met people who've been programming for decades who couldn't answer it.  That disturbs me a little.  I mean, sure, it's not like the people you would explain it to would care anyway.  To them you're often just tech support.  But it matters to me.  When I meet another programmer who can't give me the correct answer to this question, it tells me what company I don't want to work for.

Ok, that's all a little harsh, so let's go over my own perspective here, and maybe my feelings will become clearer.  Let's start with a more traditional concept of programming.  If you wish to be a programmer, colleges will tell you to get a Computer Science degree.  So maybe programming is a science.
While I'd say it's similar to science, I know there are many of you out there who would be offended at the idea of programming being considered a science.  In fact, often times programmers aren't even aware of the scientific model.  Too often do we spend time architecting and engineering solutions, rather than simply researching and experimenting, so science is an imperfect term for programming.  Well, I just listed two others.  The argument for architect is defeated by the argument we just made, but let's look at engineering.
Engineering is fairly close to what we do as programmers.  I mean, we design and manufacture programs, but there's a lot more to our job than that.  There are plenty of programmers out there who's job it is to answer Stack Overflow questions every day.  That's hardly engineering.  A great deal of our time as programmers is spent studying and researching.  While that can be important to any profession, it can't be distinctly attached to any particular one, except maybe academia.
While this should go without saying, there are plenty of abrasive work environments for programmers that demonstrate quite clearly that it is not purely an academic pursuit.  There are times when quality, reviews, and even accuracy are thrown out the window to meet arbitrary deadlines.  Programming is not Academics.
Now let's talk about the proverbial elephant in the room.  There are a number of programmers, far and wide that will argue very adamantly for the term I just crossed out.  There are probably people ready to scream at their monitors for me having done it, but it's true.  Programming is not art.  For the same reasons it's not Academics, and it's not Science it is so obviously not art.  There are certainly aspects that are artistic, just as there are aspects that are scientific, but there's more to programming than art.  That much should be obvious.

So I've shot down a lot of concepts and spoken pretty adamantly about what programming isn't, but let's discuss what programming is, at least to me.  To me, programming includes all of the things listed in one form or another, but all of these are tied together by one thing.
Science and academics are so clearly about learning that I don't need to explain, but the aspects that we miss in terms of Engineering and Art are the pieces that make them possible.  Programming isn't about staring at a wall of code you don't understand until magically it works.  It's about interpreting that code, understanding it, and changing it until it does something new.  Every day we research new technologies, programmers invent new libraries, and generate hundreds of thousands of new lines of code that other programmers will eventually have to read, and learn.  Programming is truly only about learning to me.

If you're not learning, you're not programming, you're just a code monkey, regurgitating the same crap to a new boss.  You're not becoming a better programmer if you're not learning, so you're not even really a programmer anymore.  You're stagnating--waiting to become obsolete.  There are plenty of IT departments, hundreds, sometimes thousands of people who can be replaced by a halfway decent programming team of less than a dozen, and companies are finding this out more and more every day.  If you don't think that programming is all about learning, then be careful.  You'll be coded out of business sooner than you think.  You may think you've got some brilliant tactic with code obfuscation or encryption, but there's guys out there today who can read that, who can write tests to exercise that code. Before you know it, if you're not learning, you won't be programming.


  1. Interesting read. I always wondered what it wad you did. I always picture that 90s movie hackers when I think about your job.


Post a Comment

Popular posts from this blog

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He w…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…

Managing Developers is HARD

I've been a software dev for a long time.  I've also been running my own software company for a few years now.  This is important information because of why I do these things.  I am a sofware developer because I love learning.  I slack off when doing a job that bores me, and software development always has something new to experience which keeps me excited and interested.  Why start a software company then?  That puts me in the role of manager rather than developer.  The truth is simple.  I've worked for a lot of companies, and I don't see any of them doing a great job of managing their software development.  That's not to say none of them have done a good job, but no one out there seems to be doing a great job.

How are they different?
A lot of companies get this part right.  Software developers are different from other employees.  The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction…