> the author should realize that "passionate" as used in this context is effectively synonymous with "cares"

I think that largely depends on who is using the word. Personally, I'm sick of seeing the word "passionate" thrown around in job listings. It comes off as "we really need to use this buzzword", and 90% of the time feels disingenuous.

Much of the time I end up interpreting it as "someone who is willing to work a lot of uncompensated extra hours". I say this as a person who very much cares about their craft, and wants to do excellent work as much as it is within my power to do so. I also do spend a lot of my free time learning new things related to my profession.

I'm not saying everyone who uses that word is intending to take advantage of their future employees desire to excel. It just seems like most of the times I see it, the job listing ends up being one that I'm less likely to be interested in.

100% this. I don’t expect you to go crazy over programming, but the gulf between passionate programmers and just-collect-the-paycheck programmers is extreme. Just-collect-the-paycheck programmers are useful and necessary, but a team composed exclusively of uncaring engineers is pretty much doomed to fail.

Lightbulbs are flashing for me right now because I’ve never really thought about it like this, despite caring a lot about passion.

In the teams I’ve been on that have over-performed (aka released quality software on schedule), there was always at least one or two (sometimes the majority) engineers who actually cared. Cared enough to push back when we tried to skimp on standards compliance. Cared enough to upstream a fix to a library we use. Cared enough to notice patterns in problems we had and write internal articles about how to avoid those problems.

I’ve also been on teams of (primarily European, as the author points out, the culture is very different) engineers who really are just collecting a paycheck. As long as they keep working, it’s really not a big deal if the product ships on time, or a year late. It doesn’t really matter if the product meets customer needs well, because we know they will buy it anyway. It doesn’t really matter if your colleague knows enough to get their work done. And if I see a new problem the team encounters, I’m certainly not going to learn anything to solve it, or assist a colleague who does; job descriptions are there for a reason.

I guess a good test is the “job description” test. Does an engineer ever say “that’s not in my job description” and refuse to do needed work (note this is very different than pointing out there would be someone better equipped to do it, if that is the case) to the detriment of the team? Does an engineer not bristle when someone else brings up “the job description”? If so, that’s a pretty sure sign that they don’t care about their work, which means they don’t care about your team’s success.

> a team composed exclusively of uncaring engineers is pretty much doomed to fail

Yes, but not because of the lack of passionate programmers, but because most software companies are dysfunctional. A few passionate souls can make a project succeed in spite of all the underlying dysfunction, but it's cruel of the industry to continue leaning on those people.

Teams of uncaring developers would consistently deliver working software on time and on budget if they were both trained in the same level of skill and given the same level of respect that let uncaring civil engineers build stable bridges on time and on budget. And I would certainly hate living in a society where the only thing between me and a smoking hole at the bottom of a gorge is one passionate civil engineer.