4 ms·

> "If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it." But for those of us who work on a tea

> "If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it." But for those of us who work on a team, it's far more complicated than that, and you have no idea who might be touching your code in the future.

jkire 10y ago
"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?
- mikegerwitz 10y ago
  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.
- pc86 10y ago
  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.
- camelNotation 10y ago
  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.
  - emodendroket 10y ago
    If your goal is to test every possible scenario now or future I think you'll eventually find it's not realistic.
- nickpsecurity 10y ago
  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.
mipmap04 10y ago
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.
sowbug 10y ago
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.
- problems 10y ago
  > 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.
emodendroket 10y ago
Literally addressed two sentences later.
alkonaut 10y ago
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.
psyc 10y ago
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.
- dasmoth 10y ago
  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?

jkire 10y ago

"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?

mikegerwitz 10y ago
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.
pc86 10y ago
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.
camelNotation 10y ago
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.
- emodendroket 10y ago
  If your goal is to test every possible scenario now or future I think you'll eventually find it's not realistic.
nickpsecurity 10y ago
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.

mipmap04 10y ago

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.

sowbug 10y ago

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.

problems 10y ago
> 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.

emodendroket 10y ago

Literally addressed two sentences later.

alkonaut 10y ago

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.

psyc 10y ago

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.

dasmoth 10y ago
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?