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