[johnyzee]

The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in. If I go to interview for an engineer position, it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth. All they want to know is how long I've been coding Blub, which frameworks I use and why did I quit my last job? If all is well I will start on Monday with checking out the SVN repo and start getting to know the code. Should I start trying to analyze the company's business processes that would be an awkward conversation indeed with the department manager.

I think that is the reality most developers find themselves in. I doubt it's been any different for Patrick until the consultancy spinoffs he can now pull on account of his personal brand.

So I kind of agree with Jacques here, with the exception that I don't call myself a programmer in conversation with people outside the field, since it sounds a bit like "punch card operator". That doesn't change the fact that I really am a programmer first and foremost.

[mechanical_fish]

a situation that hardly any developer ever finds himself in

"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.

[mgkimsal]

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.

Well, often the 'problem' as such is "lack of programmers". The business value/problem has already defined by other people, and a solution decided on, and you need to code it. At least, that's the position I'd been in in the past. I might have come up with a clever algorithm that solved a particular internal problem on that project, but the overarching project being worked on wasn't really solving the original business problem that was presented. However, as lowly-coder-#17, no one really cares what your views are - the problem you're solving is manpower to implement someone else's vision, right or wrong.

[brlewis]

Patrick's essay is for people who want more pay, recognition, and authority in a company that is not primarily a software company. If you aren't facing that particular problem, you don't need his solution. Hopefully you found it interesting anyway.

[rdtsc]

> ... it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth.

Exactly, if he came to our shop to interview for an engineering position but would rather talk about making 'dreams come true' instead of algorithms or systems design, we would kindly show him towards the door.

Engineering shops don't like bullshit. If you are interviewing with HR sure, use business-speak all you want.

But perhaps the fact that there is even an HR dept. that will digest business speak like that, is a sign that you are interviewing at the wrong company.

[tel]

The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in.

I think he was attempting to stress that the fact that developers don't find themselves in that situation is a little tragic. His essay suggests that in the right industries with somewhat more optimistic marketing the programmer's skillset is almost akin to magic. You take more responsibility for understanding how computers can solve problems, but by doing that become something irreplaceable.

The "reality" is context-limited, as are Patrick's suggestions. If you're willing to market more, though, Patrick's reality is pretty compelling.

[Androsynth]

You did not understand Patrick's essay.

He did not say give yourself a ridiculously fancy sounding title. He said tell them what you've done in the past and give yourself a title that engenders respect from your non-hacker friends. For example, if you tell people you are a software architect and you designed the system that made your company X million dollars, you will get respect.

If you don't spend at least some time thinking of your companies business processes then your just a non-thinking cog. Challenging these types of things is not only how you get ahead, but it's how you differentiate yourself from the non-thinking cogs.

[piccadilly]

It only gets respect because it's a kind of lie. You aren't an architect. You aren't an engineer. You write code, making up programs.

A secretary is a secretary. If people decided that's a bad thing to be, that's a shame. But it doesn't help to change the word to 'administrator,' which means something different.