> Feels sorta pedantic.

Absolutely not. A Nascar driver isn't hired to drive to the grocery store. Or to run errands. Their not hired to drive leisurely. They're not hired to be the safest driver. They're not hired to drive the absolute highest speed either (and crash). Their hired to win races. And it's important to understand that.

The difference is that in Nascar it's very visible to everyone when a Nascar driver is driving in a way other than what they were hired for, it's not as clear for a programmer. Not to mention success as a programmer also means doing many things other than programming, including knowing when to say "we shouldn't build this".

Here's a less pedantic version:

An academic researcher isn't hired to do research, but publish papers.

Similar to TFA, I think the issue is more about alignment than anything. Goodhart's Law creeps up slowly and can destroy any business or industry. Both can also stay off alignment for an uncomfortable amount of time. In our research example, I think it is clear we want our researcher to actually be doing research and that paper publication is a (measurable) natural result of that work, but it should be a bit more obvious to see that there are ways to increase your publication rate without increasing your research rate (or even increase your publication rate at the cost of your research rate). (Obviously I disagree with TFA's point)

The driver helps create revenue the car owner (often in the form of ad dollars). They may do this by driving well or they may do this by dating a country superstar or starting fights with other drivers.

Sure at the end of the day driving is a big part of it, but it’s not the only thing.

There’s what, 40 cars in the Daytona 500 and 39 of them lose. Are those 39 bad at their jobs?

I don't think it's pedantic at all. Your NASCAR driver is hired to win races, not to drive. If they drive on the highway, or down to the shops, or at the track when there isn't a race (or qualifying, or testing, etc.) on, or they drive a different team's car, or their own personal car, then they might be driving but they're not doing their job. Their job is to drive that particular team's car in such a way as to (directly or indirectly) win races.

In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.

More in the manner a foreman is hired to deliver cars to end customers.

A nascar driver seems like overkill, competent drivers that can deliver cars without speeding, truck drivers that can load up and move 10 cars at a time, managing a team of subcontractors who can drive on demand as needed, etc. all seem like better options.