I am a programmer

I actually had my company change my official job title at one point in my career to "Software Developer". I have an undergraduate degree in engineering (partially because I wanted to rebel against my parent's wishes for me to do CS). Software cannot be engineered like a bridge. Structural engineering is very narrowly scoped. You have a design load, comprised of live loads like wind and moving cars and static loads from the weight of the structure itself. There are entire "cookbooks" of formulas used to compute the theoretical, accepted thickness of the support beams and bolts. There is standardized everything, from the project management terminology to the thread count on the bolts. After graduating, if you gain four years (in some states, less) of practical engineering experience, you can take the Professional Engineer (PE) exam. In some cases, to prove your experience, you need to submit three inches thick of paper calculations you have done while working. The PE exam is rigorous and graded on a curve. But once you pass, you get the pride and responsibility of having a seal that you can use to emboss blueprints. That says you take responsibility for the work. Software development is not engineering, and I have strong philosophical discussions with those programmers who insist on that term.

Software development is creative problem solving. You do not have much creativity in structural engineering.

  > It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff.

  > I'm not afraid to tell others that I'm a programmer. I 
  > think most people understand what that is by now. I write 
  > programs for computers. 

I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it. All the unit tests and properly factored code won't mean anything if you don't. You'll write unnecessary features, or miss writing necessary ones.

Patrick's point as far as I understood it was that we all understand this but we're not billing ourselves that way. If I'm in an interview, or discussing my work with a non-technical associate, I emphasize my ability to understand business needs and write software to meet them. When I talk to technical folks, I emphasize that I unit- and integration-test all of my code and that I understand why DRY code is great.

  > The problem I had with Patrick's essay is how derogatory 
  > it is to what we do.

I don't pretend that my past jobs were "automating IPTV interface interactions" or "enabling alternative business transaction venues"... I was programming what was needed. Its a white lie the industry has gotten comfortable with and I think we'd be better off if this path was never went down in the first place. People prettying up their titles have essentially "robbed" honest ones ("I'm a f*king programmer") from being treated in the same regard.

"To a worm in horseradish, the world is horseradish."

(Sorry, have actual work to do today, so I'm going to reply mainly in epigrams where I can. ;)

pass myself off as... a business problem solver

Nobody is suggesting that. You don't pretend to solve problems for your business. At least, the business doesn't think so. They pay you. They don't pay people just for fun. They obviously think you're solving some kind of problem, right now.

Even within the seventh layer of a nine-layer bureaucracy, your peers have a problem that they are paying you to solve. Figure out what it is and learn to talk about that.

This needn't be self-aggrandizement, either. "I am one of ten interchangeable members of the QA team that keeps our customers happily renewing their subscriptions by finding bugs before they even see them" is fine. You needn't claim to walk on water all by yourself. People like loyal team players.

If you find that you can't talk about your problem without feeling dirty: That's a data point. If part of the job is "follow orders without thinking like a good little interchangeable part", that's a data point. If you discover that the problem you're solving is "win our division's internal war against the Other Division, customers be damned", you have a data point. If you come to the conclusion that you are in fact paid to cause problems, but the company can't figure that out because the intervening tangle of bureaucracy is disguising the fact, that's a data point. Try to keep doing your job well, but as the data points accumulate, and depending on your personality, you may find that other jobs are calling.

Saying what you did, and better, what that actually accomplished in real world terms isn't a lie at all, it's what people actually care about.