5 ms·

Agreed. One thing Juniors don't get (and some seniors) is when to test. I see them writing tests on business logic and have to correct them regularly. I've had

Agreed. One thing Juniors don't get (and some seniors) is when to test. I see them writing tests on business logic and have to correct them regularly. I've had to sit down and explain to 3rd party technical resources that they're foolishly asking for more technical debt by asking for certain tests. The other thing Juniors don't get is prototyping. I regularly build something quickly to get the problem set into my head. If it's good enough, I'll leave it. If it's got issues, I'll throw it away and start fresh now that I know what I'm solving. Juniors don't work fast enough or effective enough to do things like that without putting timelines at risk. Plus, they frequently want to do some cargo cult methodology of the week like TDD.

nescioquid 4y ago
> I see them writing tests on business logic and have to correct them regularly. Are you saying you have to tell the developers not to test business logic, or that you have to fix the tests they write?
- iratewizard 4y ago
  The former. Business logic changes regularly. New phases of projects frequently require changes that break the unnecessary business logic test code. Test code should fail when an important underlying mechanism regresses. If it always fails on the next phase of the project because some hapless idiot needed to cover every line, the signal to noise ratio gets weaker and the purpose of the test code is lost.
  - nescioquid 4y ago
    Thanks for the clarification -- that's what I suspected, but thought I must be misreading or misunderstanding, but I also don't know your situation and trust you're making the right set of trade-offs here. If your system is today a cuttlefish, yesterday a cow, and tomorrow a crab, cow tests don't do you much good. That sounds like a crazy environment, and I'd maybe have a care that those hapless idiots are sane people in an insane place.
    - iratewizard 4y ago
      You sound like you're in that category if you can't differentiate and think that it's surprising for software to have a flexible business logic layer.
BlargMcLarg 4y ago
Counterpoint, I've not seen seniority affect these outcomes at all. Most of the time I see some management type or CTO heavily push the "code coverage / test everything" narrative which then rolls down the hill. Strategy did not seem at all correlated with seniority. Same goes for prototyping. I don't see much of a correlation between willingness to prototype and seniority, either.
- icedchai 4y ago
  I worked at a place that had a "increase test coverage" dogma. If you ran out of real work, which was common due to poor management, you'd wind up with an awful "increase test coverage to 80%" ticket to keep you busy. This resulted in at least one guy quitting because he said it was a useless waste of time.
- iratewizard 4y ago
  > Same goes for prototyping. I don't see much of a correlation between willingness to prototype and seniority, either. Willingness is one thing, but getting yelled at for learning and doing your best is another. I never treat my Juniors like that, and encourage a 75/25 working/improving split. Still, several frequently get anxiety about how long it's taking them to clear tickets.
- hynek 4y ago
  I can assure you that it is possible and meaningful to have full code coverage in certain contexts (for instance for important projects that get only rarely touched) and doesn’t inevitably lead to bad test suites. Railing against code coverage is at this point just as dogma as insisting on it.
  - BlargMcLarg 4y ago
    Not sure why you're highlighting this in a sub-thread regarding the importance of context. Surely this was already implied? What I'm railing against is the idea that seniority is a prime indicator to the effective strategy parent comment insists on, which simply doesn't mirror my experiences. What I see is juniors picking up the habits of their superiors. They're learning this dogmatism from somewhere.

nescioquid 4y ago

> I see them writing tests on business logic and have to correct them regularly. Are you saying you have to tell the developers not to test business logic, or that you have to fix the tests they write?

iratewizard 4y ago
The former. Business logic changes regularly. New phases of projects frequently require changes that break the unnecessary business logic test code. Test code should fail when an important underlying mechanism regresses. If it always fails on the next phase of the project because some hapless idiot needed to cover every line, the signal to noise ratio gets weaker and the purpose of the test code is lost.
- nescioquid 4y ago
  Thanks for the clarification -- that's what I suspected, but thought I must be misreading or misunderstanding, but I also don't know your situation and trust you're making the right set of trade-offs here. If your system is today a cuttlefish, yesterday a cow, and tomorrow a crab, cow tests don't do you much good. That sounds like a crazy environment, and I'd maybe have a care that those hapless idiots are sane people in an insane place.
  - iratewizard 4y ago
    You sound like you're in that category if you can't differentiate and think that it's surprising for software to have a flexible business logic layer.

BlargMcLarg 4y ago

Counterpoint, I've not seen seniority affect these outcomes at all. Most of the time I see some management type or CTO heavily push the "code coverage / test everything" narrative which then rolls down the hill. Strategy did not seem at all correlated with seniority. Same goes for prototyping. I don't see much of a correlation between willingness to prototype and seniority, either.

icedchai 4y ago
I worked at a place that had a "increase test coverage" dogma. If you ran out of real work, which was common due to poor management, you'd wind up with an awful "increase test coverage to 80%" ticket to keep you busy. This resulted in at least one guy quitting because he said it was a useless waste of time.
iratewizard 4y ago
> Same goes for prototyping. I don't see much of a correlation between willingness to prototype and seniority, either. Willingness is one thing, but getting yelled at for learning and doing your best is another. I never treat my Juniors like that, and encourage a 75/25 working/improving split. Still, several frequently get anxiety about how long it's taking them to clear tickets.
hynek 4y ago
I can assure you that it is possible and meaningful to have full code coverage in certain contexts (for instance for important projects that get only rarely touched) and doesn’t inevitably lead to bad test suites. Railing against code coverage is at this point just as dogma as insisting on it.
- BlargMcLarg 4y ago
  Not sure why you're highlighting this in a sub-thread regarding the importance of context. Surely this was already implied? What I'm railing against is the idea that seniority is a prime indicator to the effective strategy parent comment insists on, which simply doesn't mirror my experiences. What I see is juniors picking up the habits of their superiors. They're learning this dogmatism from somewhere.