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