Programming is fucking boring

There, I said it. It's true. It has to be said. Programming is boring.

What follows is an ill-conceived and poorly-executed rant.

What I really mean, perhaps, is that programming for money is boring. Being a programmer working for a large company is sorta like being a writer working for a company that writes camera manuals.

I propose a brief hierarchy of writing jobs, and the corresponding programming jobs:

Writing jobs	Programming jobs
Novelist	Free programmer
Writer of ad copy	Commercial systems programmer
Writer of camera manuals	Commercial 'enterprise' programmer

A "Free programmer" is a programmer who gets to work on whatever they think is coolest -- a game, something for a startup, grad school work, whatever.

A commercial 'systems' programmer is someone who writes real things.

A commercial 'enterprise' programmer is someone who glues libraries together.

I made this chart in order to make a point: programming isn't boring because it's commercial.  I can live with having a job.  I don't have to be an ahtist.  Programming is boring because it's enterprise.

Some guy named "Mike Taylor" puts it really well:

A huge part of my job these days seems to be impedence-matching between big opaque chunks of library software that sort of do most of what my program is meant to achieve, but don’t quite work right together so I have to, I don’t know, translate USMARC records into Dublin Core or something. Is thatprogramming? Really? Yes, it takes taste and discernment and experience to do well; but it doesn’t require brilliance and it doesn’t excite.

But let me put it more strongly.  Enterprise programming -- impedance matching -- is terribly boring.  I don't know how people do it.  Well, yes I do, because I do it.

Another quote from the same guy:

Especially, I have learned that anything that has “Enterprise” in its name is so incredibly boring that the people who use it had to shove the name of the Star Trek ship into its title just to keep themselves awake.  (I am convinced that this is the case.) 

I work for Google, which is routinely described as one of the best places to work.  There's a lot of non-enterprise programming there, but I happen to do enterprise programming.  The people I work with are not enraged about it, but I think they do think it could be more exciting.


Enterprise programming is terribly boring.  It's a waste of time.  It's a waste of money.  It's a waste of programmer talent.  It consists mostly of the following line of code:


putFieldThing(fieldName, thingObject.getThingField(thingThing));


That line of code, and variations on it, and support for that line of code.


Let me tell you how you can tell that this is terrible stuff.


In enterprise programming, there is something called "business logic".  Business logic consists of the rules that define the procedures that you run your business with.  Here is an example of business logic: "When you put money into the receiver's account, make sure you remove it from the sender's account."  Or "when you mark an employee as 'quit', remove their email account".


That's what business software does.  Code that does that sort of thing is called "business logic".  It used to be called "programming".  Why did the name change?


It changed because a new kind of programming appeared: enterprise programming.  Enterprise programming (called it "EP") is the support system surrounding the business logic.   Like a ten-pound tumor attached to a tiny gland, EP grows and grows without bound.  It takes over the programming.  It takes over the programmer, and the programming effort, and the programming schedule, and the programming resources.  Now, EP is most of the programming, and the real stuff gets relegated to a new category, business logic.  (Call it BL.)


EP doesn't do anything, in the sense that it takes one step forward and at least one step back.  There are new enterprise programming systems all the time, each one designed to make it easier, to take away the drudgery, to let you deploy applications quickly and easily.  To re-use code.  To adapt to a changing environment.  Etc etc.  EP systems can promise anything, because they don't really deliver anything.


I live in NYC, where, I suspect, a larger portion of programming jobs concerns EP.  There's so much of it here, it's outrageous.


I look at resumes of Java programmers, and about half of them have written the same program: delivering real-time financial market data to analysts.  Why are these people writing the same program over and over again?  Because it's EP.  It consists of gluing together pre-made modules and working out the annoying little problems with the glue (impedance matching).  Each company, each team has slightly different needs, so it needs its own software to do a slightly different thing.  And so there is a job market for a stream of computer science / IT majors to get sucked into.


You have to understand: EP is a black hole.  EP is a vague, endless task that everyone is trying to solve, and everyone is on the verge of finally solving it, and yet no one is ever solving it.  It's sisyphean.  The EP industry creates problems, and then provides solutions.  The solutions don't quite work, but soon enough there are twice as many programming magazines with twice as many ads that are telling you about twice as many systems you can buy, or philosophies you can adopt, to really solve your problem.


I have used several EP systems that make everything harder, and nothing easier.  I can't imagine how this could be considered an advantage.  I have used EP systems where adding a single field to a database table requires you edit 6 files and wait several days.  In the same amount of time, I could have made the same change in a system based on pencils, erasers, and index cards.


EP is make-work.  It fills all available time.