Being Slow to Criticise

thoughts > filter > communication > thoughts

With grown ups it should work like:

thoughts > communication > filter > thoughts

You want the full spectrum of gradients of terribility. If I wrote a "steaming pile of crap" I don't want to hear "it is not very good". "not very good" is reserved for things that are "not very good".

food half frozen != under cooked

The alternative is teaching people not to give you feedback because you are emotional unstable and might take it the wrong way.

Just because someone is a dick doesn't mean they are wrong. You have to adjust for their lack of social skills. You want to own the filter, don't require others to maintain it for you. That is a terrible idea! To them the trash talk is treasure.

You may want to self-analyze your need to criticize. What is criticizing satisfying in you? It must be something otherwise you wouldn't have the urge to do it.

It varies from person to person, but for a lot of academic (and perhaps tech) folks, there is a strong history in their training to be correct (in both research and classes) - therefore they are hyperaware of things that seem off.

In the work environment, though, the focus is on being useful, which has overlap with correctness, but the two occasionally differ. A lot of times such people tend to be correct but not useful. Pointing out a flaw in something where there would be no significant impact were the flaw absent is the opposite of being useful.

Unfortunately, people in the audience often get fooled by this and give the comment more weight than it deserves.

When someone calls my work garbage, but isn't willing to sit and discuss what is garbage about it, nor willing to discuss the cost of fixing it, I will ignore him/her.

Talk is cheap. It's trivial for someone to come up with a surface reason to complain. It's harder to take all factors into account.

I was once doing a project where I was solving something in a brute force, inefficient way, but it was simple to code and we had the computer time available. One developer kept loudly complaining in meetings about how crappy and dumb my method was. I finally set up a meeting with him and asked him how we would do it. His solution was far more efficient, but would also take up to a week to implement. I asked "Given our deadline, do you think it is worth losing a week of computer time to implement your method?" He thought about it and said "No, my method won't make up for the time lost."

If you're not willing to sit in the trenches with me, your feedback will have lower weight. I'm in the business of solving problems, not in the business of perfection. At some level, my software is always going to be garbage. You want it not to be? You better have a stake in the outcome, then.

I don't see how either statement is of any use for you?

Yes. But what happens when that code is there, live, working, and the originator is no longer available, and you need to enhance it. You come across a complex section and you can't really see why it's written like that. It feels like you're suggesting that one should just replace it with the simpler version you think will do the job just as well, and see what breaks.

Due to my usual context, that approach fills me with horror. I've seen it go wrong too many times ever to be comfortable with it. Admittedly, if you're producing simple web sites then usually it won't be a problem, but when there are potentially millions of dollars of revenue at risk when a condition happens that you didn't anticipate and which was part of the reason the original code was so hairy, you become a little more wary of the "move fast and break things, then fix them" approach.

> If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time.

And if you are brave and decisive and cut code, and it turns out that the complexity was there for a reason you didn't understand, then that can be a company-terminating move.

Again, our contexts are different, and yes, I do understand the need for controlling complexity in code, and simplifying where possible.

Properly understanding and analysing the risks is something I rarely see.

I suspect we'd actually agree in a given context, I'm just horrified to watch people unthinkingly advocating the approach in places where it doesn't apply. I'm not claiming you're one of them, quite possibly you'd do the risk analysis and understand the context, but I've seen it too often to take for granted that otherwise clever people won't do it.

"We'll just re-write it, it won't take long, how hard could it be?"