Hacker News Reader

Comment by phaemon | Hacker News Reader

When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.

I'm going to guess (at least I hope!) that you're inexperienced in the professional world. Well, in the adult world you will face criticism for what you produce constantly.

Some of that criticism will be fair and you'll be able to act on it - you can improve what you've done. Some will be fair but you can't act on it - you can't change it in time or on budget and that's not your fault. And some will be completely unfair - it's simply not accurate.

You need to develop a mature response to all these scenarios. But sticking your fingers in your ears and going, "lalala I can't hear you" is not one of them.

View on HN

Looks like this is the reason why that person was banned.

https://web.archive.org/web/20191223200601/https://christine...

This post pretends to be a security report, but it does not help anybody (there are no users who would be protected by disclosing this "vulnerability"), it is just disruption of people work, and nothing more.

People actively breaking things cannot be just ignored, they should be banned.

> When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.

According to this: https://christine.website/blog/series/v it was a year between first post and the last. It was more than enough time to make at least some contributions.

This timeline convinces me that Christine did not intend to contribute at all.

> Well, in the adult world you will face criticism for what you produce constantly.

Criticism is natural. Banning people who don't help, but distract and demotivate, is also natural.

> You need to develop a mature response to all these scenarios.

It's not that simple. Too much criticism can kill will even in strongest people. Sometimes the best response to non-constructive criticism is to just ban, and focus on what's important.

No, the best response, if the devs truly felt the criticism was non constructive, was to ignore it.

Having read the posts, it seems perfectly reasonable criticism, with enactable improvement. The dev response seems immature (at best) to me.

To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up.

> No, the best response, if the devs truly felt the criticism was non constructive, was to ignore it.

We don't know how exactly Christine communicated with project devs. We see the posts, but we don't see Telegram or Discord messages or GitHub issues or comments or whatever.

For example, there are people who just derail/flood group communications by raising non-important issues (like discussing syntax), or discussing completely unrelevant topics (like starting a conversation about political situations, human rights etc).

Anyway, I agree that the project author could do better. But I cannot blame him either. At least until either party provide some evidence.

> Having read the posts, it seems perfectly reasonable criticism, with enactable improvement

Calling a product vaporware is not a good way to start a constructive communication.

If I did that, I'd either start with apologising for calling the project vaporware, or did not attempt to join the community.

> To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up.

Developers in commercial products are paid for listening that feedback (constructive or not). But V is open source.

And in commercial companies, internal tensions are usually fixed very quickly, because teams cannot work efficiently when communication is bad.

We don't know the full story because the V devs deleted it. Experience tells me that people tend not to delete stories that paint them in the better light.

It's vaporware until it we exists. Perhaps it would be kinder to call it "conceptware" but who really cares?

Oh, and the vast majority of commercial software firms have absolutely terrible communication. And, yes, they do not work effectively.

I feel like I am destroying an optimistic world view here, which is the last thing I wanted. There are many excellent and exciting places to work. Don't let an old man's cynicism put you off!

>Perhaps it would be kinder to call it "conceptware" but who really cares?

I do. It is not vaporware, because it exists, can be used, works for the most part, and is improving every day.

Please do refrain from calling stuff, that you do not use yourself names.

> And in commercial companies, internal tensions are usually fixed very quickly

I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.

> I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.

Probably most companies deal with tensions more or less successfully. They have good instruments to manage these things: yearly bonuses and option to fire employees who do not cooperate.

Obviously these instruments are not available in open-source projects.

What companies, and what are those instruments?

I'm sincerely curious, I have worked in tech for 20 years, and while some companies are active in trying to make sure teams work well together, I've never seen one that had specific systems for keeping tensions in check - maybe it's because I've worked for <1000 people companies?

All successful companies, and these instruments are: 1) bonuses for successful work, which includes ability to resolve conflicts peacefully; 2) option to fire employees who don't work well, in particular, those who don't get along with the team and hire a replacement.

> I've never seen one that had specific systems for keeping tensions in check

It does not work perfectly, for sure. But in free-time opensource project, if you don't like something, you can always express this loudly, or just stop caring about this project, because leaving the opensource project is not a big deal.

Unlike employment, when if you quit or fired, you get a lot of stress, you are seriously motiviated to get conflict resolved.

Long time ago I read an interesting article about how hard is to be a manager in a terrorist organisation. You don't pay people money, at least not a lot, there's no contract, employees goal are likely very different from yours. They quit randomly, they do whatever they want, and it's hard to achieve some discipline. I think this is kind of similar environment as in open-source project (except, open-source contributers don't blow themselves up).

Again you’ve failed to provide a single example from your experience so I’m left to assume you have none.

Sorry, it sounds like you have idealized views that don’t match with actually working at tech companies. Please don’t proselytize things that you have no experience with - it can be massively distracting and confusing for people who are in situations where your advice seems like pure gaslighting.

Bonuses are not a way to ease interpersonal tension, in fact, they make them worse.

If I’ve misread this in any way, please let me know, but don’t further waste my time with bullshit.

Reply on news.ycombinator.com