"When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong."

I think addresses that point quite nicely?

Sort of, but imagine this scenario:

I very rarely have issues in problem space A, but I don't really test for A. Maybe a few here or there but it's a small minority of my tests and the coverage is probably just incidental. I test heavily in problem space B for whatever reason.

I get hit by a bus, and you're my replacement.

You have no experience with problem space A, so there are few if any tests around that space. All of a sudden the coverage is misleading because we might have 100% coverage or close to it, but the thoroughness isn't there and suddenly releases are less reliable and support ticket volumes increase.

Not necessarily. In many firms the turnover rate is significant enough that you have no idea who will be working on your code in six months or so. Unless you are on the sort of team that never changes, you can't really use your past experience as a guide for a future team's strengths/weaknesses.

If your goal is to test every possible scenario now or future I think you'll eventually find it's not realistic.

Sorry, my thoughts stopped short. It does in part.

But the collective mistakes of a team aren't a predictor of potential future members of the team. For example, we started hiring "junior" programmers, which increases the skill gap.

It does if team and their strengths/weaknesses stays the same for the life of the codebase. If it changes, then that property goes away to some degree with missing coverage against someone's weaknesses. Better to have QA cover correctness against whatever would undermine it.

Also: how long do you maintain it.

Even if I'm alone in my team, When I refactor code after say 10 or 15 years I could just as well have been another person. I don't remember. I don't have the same skill set.

And the thing is: when you first write the code you usually don't know how many years you will maintain it. That might be a reason to postpone some test writing a while initially (if the code is scrapped in 2 months what whas the point of effort for maintainability?)

However there are upfront benefits with writing at least some tests for everything, in that it (usually) helps design a less coupled system.

I aim to test for the version of myself that's having a bad day (tired, rushed, wrong caffeine level). That's a better target market than the idealized version of myself that makes only expert-level errors.

That seems to cover the team element, too. Even if I'm not having a bad day, someone else messing around in my code might be.

> That's a better target market than the idealized version of myself that makes only expert-level errors.

Not only that, but you have to be able to test against yourself a month from now or a year from now, when you've completely forgotten some aspects of the design and might overlook something doing a modification. I write a lot of report generators at my job, so there's quite often a bug or a new feature in a report I haven't touched for months at a time.

To be fair, the person quoted by the author does reference this in the article. He says he changes his frame for how much he tests based on his team's historical challenges.

That was my favorite line in the article, and one of the most resonant thoughts about programming I've seen in a while. It's a big part of the reasons I choose to mostly work alone, except when I really need the money. There's a mode of thinking and working that's both joyful and effective, and a lot of it is which particular things are actually concerns/strengths/weaknesses for me. Every time I work on a team, I have to contend with the union of everyone's concerns: the juniors, the seniors, the managers, their managers.... That mode is stress and misery.

Quite.

There does seem to be a lot of resistance to the idea of handing problems to solo programmers right now though. Any hints as to how you've made this work?

Literally addressed two sentences later.