Popular posts

"...so it's a loss of productivity in the now to try to reduce the probabillity of a loss in the future."

Exactly right. I argue that "loss" now is usually a penny-cost of prevention vs. the potential pound-cost of cure in the future.

"But I don't need an echochamber debate..."

Almost nobody smart, competent, and self-secure ever does.

Richard Uie I don't know about the ecconomics of pennies sometimes I review code for 1 - 2 hours but yes the ratio seems benefitial.

I wouldn't go for smart, competent and self secure. I go for one of the quotes of mills:

He who knows only his own side of the case knows little of that. His reasons may be good, and no one may have been able to refute them. But if he is equally unable to refute the reasons on the opposite side, if he does not so much as know what they are, he has no ground for preferring either opinion... Nor is it enough that he should hear the opinions of adversaries from his own teachers, presented as they state them, and accompanied by what they offer as refutations. He must be able to hear them from persons who actually believe them...he must know them in their most plausible and persuasive form.

I really believe that there’s a semantic thing here. Many people see this as a "loss" and we need to convince them as a value. We need to talk about it as an "investment". Like any investment, there’s an initial cost. Then it will pay off. How much it will pay, and when is the big question, but at least it’s not a pure loss, it’s an investment to get some value back later. (I know you guys are convinced about it. My point here is that the word we use to explain it to others often convey a lot of meaning, and semantics are important to convince people)

Sébastien Portebois well the yes short-term thinking vs long-term thinking. I am a pragmatist not an evangelist. This is a value discussion in the end.

It's loss of productivity and a win in risk reduction. And you easily get companies with risk reduction and the bus factor usually. The loss is also mainly temporary and there are a lot of good reasons.

But the main reasons that works for business seems to be risk reduction and stable productivity.

For a developer you need other reasons than risk reduction, shared ownership, improvement of readability. But for us the set of implications are way bigger and we have a lot of things to establish before just randomly code review and have discussions where in the end the HiPPO's rule kicks in.

It's a grassroots-movement where we believe it makes us better and helps us get more productive. And we need to sit down and establish what our team code values are and research what our core value is, otherwise it can get unproductive.

I waste hour arguing with certain devs just because they have another oppinion and can not argue them logical to me.

Anyhow it's a complex topic to me with a lot of implications .... I tend to spend years on it and I did it in multiple companies, everyone defines things differently .... :D

long story short. I agree to some degree ;D ...