On Expertise
I used to order just one drink at Starbucks: a grande, 4-shot, long americano. I ordered it every day, twice a day, for about 4 years. Once in the morning and once in the evening. I know this drink. I know how long it takes to make, I know what it tastes like, and I know how much it costs. After all, I’ve ordered it over 2400 times. I am an expert on these aspects of this drink: the grande 4 shot long americano as prepared by Starbucks in Canada.
Starbucks employees make many many thousands of drinks a year and they are experts at their trade, but in this respect I have an advantage on them. While they make thousands of combinations of espresso drinks and need to know the composition and pricing of all of them, I only need to remember one.
Thus when a baristo charges me for a venti americano in a grande cup and claims that it costs the same (since their venti naturally has 4 shots), and I claim that he is wrong, he should not be surprised. Contrary to the baristo’s belief, although they are experts in many coffee drinks, they cannot beat my knowledge of this particular issue: I’ve compared the prices and the grande-4-shot option is cheaper (at least it was last year when I last ordered it).
Now, the customer is not always right. I take my intimate knowledge of this drink to Whistler, BC, and it’s no longer valid. They charge more for coffee there; Starbucks puts a tourist tax on their products just as many other stores do there (in fact they do the same in Airports, reflecting the higher cost of doing business I suppose).
The skill is in recognizing what you are in expert in, and how this related to other’s expertise.
For the contrary example, I used to write a piece of software called LifeForms. While I was not the original developer, over several years I modified and understood most of the program, to the point where I could be considered an expert in most aspects of it; the animation engine, the rendering engine, the data storage and file formats. I knew that program and how it worked intimately.
However, I am not an animator. I did not use the program, not the way animators and dancers do. I was regularly surprised, and sometimes even shocked at what artists were able to achieve with this relatively simple software. They took the features I wrote and made art with them. Their expertise at using the tool I wrote was of a completely different nature to the expertise I needed to write the tool.
The same story has cropped up again and again during my career as a software engineer: when writing a video game I could not play the game as well as a real gamer. When writing facial recognition software I did not know how to book a criminal into jail. And now, writing emergency management software, I am not an emergency manager.
When people tritely say that everyone is good at something, I think of this; expertise is a difficult thing to understand. You have to understand what you’re an expert in, and where that knowledge extends and where it stops.
The terrifying aspect of this for many software developers is they end up designing software they don't use.
Of course, I assure you it's far more terrifying to be the end user of many of these not-used-by-the-developer pieces of software.
There's a challenging element there that can only be solved by some combination of the development team becoming subject-matter experts in the user's field, and having articulate users who can test the software, and provide feedback, ideally as an intimate member of the dev team.
You mean you weren't an expert in eating your own weapon trails?