[DanielStraight]

Patrick's essay had nothing to do with titles. It was about describing what you do in terms of the benefit you provide to your customers/employers rather than in terms of the skills or tools you use to provide that benefit.

I could tell people I can program Excel interop in .NET, or I could tell them I saved my company dozens of hours a week by automating an administrative process. To non-programmers, only one of these descriptions sounds interesting. A programmer can hear "Excel interop in .NET" and infer automating administrative tasks. A business person, generally, cannot.

Patrick's essay was about being explicit about the value you provide, not about picking a fancier name for yourself.

[TheCapn]

I feel that is the wrong way to approach things. Your job as a programmer was to provide that deliverable as set out by your position. You programmed it and it went along. The outcome of that deliverable was the improvement but your job was to construct it.

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.

[mechanical_fish]

It is hard for those of us who know how to tinker to appreciate that there really are folks who don't tinker.

You assign them to pull the levers, and they pull the levers. If the machine they're running is manifestly inefficient, they don't notice, or they pretend not to notice.

(Or – if they're good – they adapt themselves, adopting a complex series of difficult physical and mental moves to compensate for the machine's brokenness. Sometimes those physical moves are such that, after four years on the job, they'll be in the hospital. But they do them anyway, because, hey, making the inefficient machine work is their job.)

If the machine next to theirs is broken in a way such that it messes up half of the work coming out of their machine, they just keep going -- hey, it's their job to run this machine, not that machine. If the machine they're running breaks down, they call for help and then sit there unmoving until help arrives. ("I didn't want to break anything.")

You tell them to RTFM, and they do, all of it, and then they come back to you: "I read the whole manual; now what do you want me to do?"

They may have even memorized the manual. It's not that these people aren't smart and eager to please. Indeed – and this is the thing I have trouble getting my head around – sometimes, within their area of expertise, they may know how to tinker like mad, they know the freaking serial numbers of every part of their machine and which ones can substitute for each other in an emergency. And yet, beyond their area, there's this strange paralysis. You hand them the duct tape and gesture encouragingly at a neighboring machine and... nothing happens.

If you give such a person a room full of miscellaneous broken things and ask them to fix everything they will proceed at a rate of (1 + epsilon) hour of progress per hour you spend telling them what to do. On the flip side, if you give them a room full of ten thousand widgets to finagle and they have a certification in Widget Finagling, those widgets will get finagled. They might even work overtime to please you. And when the widgets are done they'll go home, even if the rest of the factory is on fire, because there's nothing left for them to do.

When hiring someone to solve our problems we desperately need to know whether or not we're getting a hacker, or a technician. Both have their roles, but they can't substitute for each other.

[pnathan]

This is true. I know someone who has bluntly me told me they don't want to think at their job.

[jarek]

> When hiring someone to solve our problems we desperately need to know whether or not we're getting a hacker, or a technician.

So you base this on whether someone calls themselves a programmer or not?

[tomcreighton]

I think you're missing the point - saying "I'm a programmer" essentially means jack and squat to most people.

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.

[TheCapn]

I agree with you completely. I'm just being pissy and saying "I wish things were different" and I really don't have a productive solution to the problem... My wish is that programmers would take pride in the title and call themselves programmers who were able to accomplish X and Y for company Z and not the other way around where they hide the programmer bit.

[jarek]

Do you think CNC operators give a damn whether most people know what a CNC operator does?

This "make people understand what exactly I do and how much value I provide and how precious I am" is yet another manifestation of insecurity of software developers.

[tomcreighton]

No, unless they work or want to work directly with CNC operators and need to know what they're actually capable of instead of just what they're called.

This is exactly what you don't put out a 'I need a dozen programmers' ad - people aren't a fungible commodity. You do actually need to know how much value they can provide.

[DanielStraight]

"Make people understand what exactly I do" is exactly the attitude I think Patrick is arguing against. That's why you don't call yourself a programmer or talk about what technologies you use. Because it doesn't matter to non-software companies. What matters is whether you can save the company money or increase their revenue.

Calling yourself a programmer is telling what you do. Describing how many hours of work you can save is telling how you can provide value.

When presented with a bunch of employees manually copying information from spreadsheet into a database, you can tell them, "I know Excel interop and SQL," or you can tell them, "I can make it so you never have to manually copy this information again." Only one of these statements is interesting to a non-programmer. The first implies the second to us, but not to a non-programmer, so you need to be explicit. You can't expect them to make the inference and present you with a spec for a spreadsheet-parsing, database-updating program.

The reason programmers have to learn this and not CNC operators is that the benefit of a CNC operator is much better understood in their sphere (manufacturing) than the benefit of a programmer is understood in their sphere (almost anywhere computers are used extensively). Most people who can benefit from a CNC operator know it and know how. Most people (outside of the software industry) who can benefit from a programmer don't know it and even if they did, wouldn't know how.

Programming is by no means the only field in which this applies though. It also applies in design, copy-writing, SEO, ergonomics, preventative medicine, and many other fields. Anywhere where the people who can benefit from a field's work don't understand the field's work, but do understand impact to their bottom line.

If you pitch a business with, "I increased productivity at another business by 10%," you'll have better results (at least this is the conjecture at hand) than if you pitch with, "I'm an ergonomics expert," even though the actual work being offered is the same. Either way, the business owners will probably never understand that ergonomics is more than adjusting desk height. But they don't, and shouldn't, need to. They just need to appreciate how it helps their bottom line and trust the experts to apply the expertise where it should be applied.

Trying to make people understand what you do is exactly the problem. Programmers naturally seem to want people to understand how computers work and what they can do. We want people to understand what code is, why it's important that it's written well, and so many other things that business owners simply shouldn't need to care about. That's why we tell people we're programmers, or that we know certain languages or frameworks. These things are only relevant to other programmers though. Business owners care about making money, so tell them how you can do that.