I agree with the premise that making is harder than commenting, and this can be frustrating. But I don't think that telling people not to comment is the right solution.
There can be a lot of value in comments, even ones that have not been thought through very deeply. In fact, casual, uninformed comments are often the most valuable as they're representative of how someone new to your product or project will perceive it.
I've found that the keys to getting value out of comments without getting discouraged are:
1. Not to take comments too personally or get defensive about it. They're not attacking you. In fact they're not attacking anything. They're just making an observation. (On rare occasions, you may get a comment from an asshole who really is attacking you personally, but it's pretty easy to tell when this is the case and ignore them).
2. Take a more statistical view on comments. If one person mentions something, maybe they're just an outlier. But if 10 people mention the same thing, they're probably on to something.
Comments are probably have positive usefulness expected value in a probabilistic sense. Unfortunately extracting that value, separating the insights from the dross, is work and requires effort. Effort that perhaps the person doing the original work being commented on shouldn't necessarily be expected to take up.
Additionally, human nature makes it hard to receive legitimate criticism dispassionately, let alone when it comes in a big pile of stuff that also contains pointless abuse.
There is value in comments, but depending on a project's circumstances it may or may not be economical to extract it.
> Effort that perhaps the person doing the original work being commented on shouldn't necessarily be expected to take up.
It doesn't apply to all situations, but sometimes you end up with less net effort by listening thoughtfully more. I expect this is especially the case when you want or need to optimize for some form of popularity. If you're just making things for the joy of creation, sure, just ignore everyone as that's certainly more work than pleasing only yourself.
The article also brings up the difference between two types of comments, the "let me know how I can be helpful" comment versus "I will connect you to five potential customers tomorrow" which is the more helpful one. Commentary can be valuable if it's been thought out more, or if it the commenter invests something themselves, both of which this example shows.
Academic advising is also extremely valuable even though it fits the definition of commentary, because they have put reputation and funding on the line, and spend long periods of time thinking about the work. It's not always just because the advising comes from an "expert" in the field, but just that they have invested in the work.
The type of commentary that I find less useful, is the vague notions of "there is a serious problem here" comments that I hear sometimes on Hacker News. Like "I find this problematic, [and then some outrage]" or "I have some concerns about the security/privacy of this" or "I am concerned about HIPAA here..." It demands a response, and usually the maker has already thought through this in more specific terms, but can't rebut because the comment is vague.
> The type of commentary that I find less useful, is the vague notions of "there is a serious problem here" comments that I hear sometimes on Hacker News.
In creative writing workshops, a common quip about the feedback of non-writers (eg, friends and family) is:
"If they don't like something, they're probably right. But when they tell you how to fix it, ignore them."
Which is to say, in this context of this thread, vague complaints usually are a reliable indicator of something wrong. But knowing exactly what is wrong and how to fix it is a much bigger ask, and even if they spent the time and effort most people wouldn't be able to help you here.
But that doesn't mean the signal they're giving you isn't useful.
> but can't rebut because the comment is vague.
Don't rebut it. Don't take it personally. Just take it as a data point and say thanks, or don't respond.
When you get someone who’s willing to offer up a lot of information, it’s great. And when you don’t, then really honestly try to understand them and their frustration. When you get to the bottom of it, you’ll come away with something useful and they’ll know that you care enough to try to make it better.
I recently jumped on a call with some people from Miro. One of them had left a calendar booking link in a forum for something else and I tenaciously scheduled myself in. When I spoke to them I said “here are my frustrations and I want to give them to you know before I just get into the product and learn to live with them and can’t articulate them anymore”. To their credit they took the call and listened. They got something and I was happy.
+1 for the statistical view. One or two data points can be ignored, but 3+ different people who report a the same bug/problem and you need to listen up.
Your first point reminded me of the post the other day by Daniel Stenberg about the feedback the he receives for his work on curl. [0] Making things in public absolutely does open you up to personal attacks. Ignoring them is easier said than done.
I am sorry to tell you that comments have never been helpful for me to meet a deadline. They have ever been a signal that the commenter was not willing to engage intensely enough so that his contribution would have been of immediate value. Instead it remained on a meta-level, expecting me to carry half-baked and barely understandable thoughts out.
But guess what? Bosses comment, workers write. That's the fate. Don't know why. Some is to attribute to Peter principle but not all.
A simple rule for dealing with comments is « no feedback on feedback ».
Obviously works best if the person commenting doesn’t have any power in the situation. That being the case, avoiding a big discussion and extracting whatever useful information is contained in the comment is a net win.
Roosevelt’s Man in the Area quote sums this up well.
> "It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."
It's also a useful metric for deciding who to follow on social media. Is the person showing off their work or are they just commenting on the work of others? If the work/comment ratio drops too low, I stop following them.
Roosevelt’s Man in the Area quote sums this up well.
Roosevelt said, wrote, and did a lot of important and poignant things. I'm particularly fond of his speech about how we must stop being hyphenated Americans, and be just Americans. (He was railing against how the nation was balkanizing into "Italian-Americans" and "German-Americans" and "Irish-Americans.")
Sadly, he wasn't perfect. And modern-day internet revisionists who understand neither history, nor context, and expect perfection are rapidly erasing him, his words, and his deeds from history.
I like this Roosevelt quote, and Brené Brown gets a lot of mileage from it, but it always struck as me as a veering a little too close (for my comfort) to a possible rationalization of why it was okay for me to fuck a bunch of stuff up and maybe stomp over a few cold and timid souls because at least I was doing things.
I would say "the credit belongs to the person actually in the arena, who is also able to step outside the arena and consider their failures from an outsider's point of view" but that is obviously not very catchy.
Hannah Arendt has a bunch of interesting things to say on the actor/spectator tension, though I am unable to currently find a better reference than https://plato.stanford.edu/entries/arendt/.
Is there a good book on Theodore Roosevelt anyone can recommend? He seems like the kind of man and leader that has completely disappeared in this century
Great men with great passions are rarely the ultra-careful, calculating people that are allowed to succeed today. Teddy Roosevelt was smart and brave but also brash and crude. He LIVED, in the way Nietzsche would approve of. People like him would today be shunned/passed-over/cancelled for something they said, some joke they made, some unconventional opinion they dared utter, if they ever got close to power. One major leader captured some of that energy lately, though he lacked Teddy's intelligence and confidence, and his people rejected him for it. We live in a different time. Teddy's traits would be called toxic masculinity.
It’s very interesting. No one seems to actually like politicians these days. I’m not sure if someone who was truly brave and principled would be shunned by the general population. Elites - of course they would shun any challenger. Trump is not a good comparison as he had none of Teddys positive traits.
The River of Doubt. It is not a biography but about his journey into the Amazon. Roosevelt did so much that you could pick any 3 year period in his life and write an interesting book about it.
> Is the person showing off their work or are they just commenting on the work of others?
You are being reductionist. Comments don’t have to be negative, they can be positive - I.e just pointing out “new good stuff” and this allows one to discover content faster. The content here is the speed of distribution of new “worthy”.
It’s what negative reinforcement vs positive reinforcement is.
Not sure that last bit is correct, negative/positive in a reinforcement/punishment context refers to removing or adding, not a value judgement.
So negative reinforcement is taking something bad away to reinforce a behaviour you want to see more of. e.g. umbrella and rain, eating and hunger, etc.
So negative reinforcement here is the negative opinion about someone so that they would stop doing something. Taking away their “credibility” so that they would do something else.
Positive reinforcement is giving credibility to people who are doing something worthy.
Negative reinforcement is defined by taking away an adverse stimulus. A positive attribute (like credibility) does not count as adverse.
Taking something good away is negative punishment. You are removing something they want, to reduce (punish) the behaviour (not reinforce it). Classic case is taking a kid's toys away when he won't behave.
Of course, these things are mixed. If receiving bad comments online is hurtful, then that is positive punishment. The removal of credibility is an added sting.
Positive reinforcement is correct in that example yes.
I've been involved in dog training where some people are really into this, while others twist the concepts to suit them, so getting it right is a bit of a personal peeve.
Yeah, that's great that you have pointed that out, but it doesn't take away from the main point I was making unfortunately. You could argue definitions, but if you truly know that I am making this mistake, then you should explain the mistake of vocabulary rather then then essence of the point being made.
What you're doing instead is diverging the conversation towards a topic that is unrelated to the subject; while in the process satisfying your own ego.
And yes, I meant "negative punishment" vs "negative reinforcement".
The article is so vague that people can read anything they want into it, and judging from the comments here, they are. My question is, who is the target of the article, who is supposed to avoid commenting? Your coworkers? Your boss? Your paying customers? Your non-paying users? The media? Twitter/HN randos? All of the above?
If you're a maker, then you're making things for someone. If you're only making things for yourself, then of course nobody else has a right to comment. But if you're making things for other people, then it seems to me that those other people have the right, perhaps even the obligation, to comment on the product, right? The article verges on the parodic idea that no maker should ever be subject to any criticism. If that's not the author's intention, then the author ought to be clearer what is intended.
It seems clear to me those commenters are also in a position to do the work themselves. Maybe coworkers. That is very different from a programmer-user relationship that a lot of people are talking about here. Almost the opposite - complaints are valuable and fixes aren't.
Hmm, I got the notion that makers are welcome to comment on the works of other makers, but if you're _only commenting_ knock it off and go make something. It's different when you have experience making (or writing) something, and that experience makes feedback more useful and more actionable.
Who is a "maker" and who isn't? This seems like a false dichotomy. An enormous number of people on Earth are engaged in making things. And every maker of things is also a consumer of things.
Or is it that only makers of this particular thing are qualified to comment? But that would be a strange principle, because again, who are you making things for?
For example, you could comment on someone starting a garden without having tried to start one yourself. Or you could start a garden yourself and have lots of interesting takeaways and constructive feedback to share. Lots of people make things, sure, but just because I make a boat does not make me qualified to comment on bridge building, or garden making. So I would think someone who has relevant experience in making whatever the thing is would be a "maker" and other people would not. I don't think the audience of "who you're making things for" is nearly as relevant, because sometimes you make things for yourself, or your partner, or your friends, and sometimes those things are useful and more people want them. Discovering product demand is an iterative process. On the other hand, there are people who do not make things for themselves or anyone in need, or to address any need, so although they might have a lot to say it might not be all that helpful or relevant if they have not tried to build whatever it is the maker built, or something close to that.
Can we not pretend that we're talking about gardens and bridges, or that the article author is just making things for himself, his partner, and his friends? I really don't think these are useful analogies.
Who is commenting on gardens? Who is commenting on bridges? I mean, if a bridge collapses, then a lot of people will comment on it, deservedly so. "Yes, people died, but don't criticize, go off and make your own bridge!"
Yes but the article is not about crises and disasters... it's about people sharing their work with the world, and the observation that it's much easier to comment and criticize on something without knowing the difficulties in building or creating it than it is to actually set off and attempt to build the thing. What I got from the article was that if you have actually given it a shot your feedback is more valuable and you probably ought comment because you'll have something to say that will help the builder. Maybe we are looking at different uses of the term "comment." Yes, naturally anything anyone says in response or as a reaction is a "comment," but I think the author was coming from a place of sharing one's work on the internet, he pretty much said as much in the article.
> I think the author was coming from a place of sharing one's work on the internet, he pretty much said as much in the article.
Did he?
"I’ve mostly stopped sharing unsolicited “helpful” just-a-thoughts and comments at work. I save them for Twitter"
This is why I said it's not even clear what exactly the author is talking about. I actually have no idea, but everyone else seems to think they know, despite the fact that they have very different interpretations of what it is.
I've got at best mixed feelings about Nassim Taleb but his thoughts on "skin in the game" which I believe is exactly the same concept as what is being discussed here is really profound in my mind.
And the basic idea is that all ideas need to be weighted relative to the "skin in the game" of the person throwing out the idea. If people are not willing to take a consequence on their idea being wrong then they basically get a weighting of zero or near zero on the importance of their idea because they have no incentive to care about the quality of their ideas and are likely instead to be much more focused on the signal they send by projecting the idea itself. Whereas if someone is willing to take on personal risk on the outcome of the idea they are proposing, the idea should be taken much more seriously.
And the key point, is this isn't about moralizing that the person with skin in the game is more moral or righteous because of their skin in the game. It's a game theory proposition about signaling the likelihood of validity of their idea.
Can't +1 this enough. Stated another way, I always think back to this slide [1] from one of Holman's old decks ("Drive-by opinions are less valuable").
For whatever reason, this is a very common phenomena in tech, and there's a positive reason explanation for it and a negative one. The positive one is that people really are engaged and enthusiastic and want to help make the product better. That's great, and far better than the alternative.
The negative one is the same as the classic mid-level manager who arranges an unnecessary meeting with shaky pretext that everyone knows is just so that they can have their ideas heard for 60 minutes. It makes them look engaged and increases their visibility in the corporate hierarchy. Now, while that was a literal meeting back in the 90s, but 2020s version of it is littering smart-sounding comments all over as many key Google Docs as you can, all of which have your picture next to them, and which you know others will see.
Too many ideas aren't necessarily a problem, but it can add a lot of overhead to a project, and the end result is often only incrementally better. I've worked on smaller projects where it took us 2x to 3x longer to ship by addressing tiny feedback from a large number of people, and the final product was like 5% better. That't not to say that no feedback is valuable, as a lot of it clearly was, but there's a happy compromise somewhere between taking too little and taking too much.
In the end, the article author's advice rings very true:
> “So, what are we going to do about it?”
(With the emphasis on "we".)
Give ideas/feedback, but make sure you're willing to engage with the work.
> “Cool! Yes, but there’s 12 other things we thought should come first. You’re welcome to go and do it. We’ve got a big tent and a lot of shit to clean underneath.”
> “Actually, can’t help, gotta take my dog to therapy, bye!”
This part especially is so familiar. It tends to get emotionally pretty exhausting, when you've put in countless hours to make so many things good, only to get constantly reminded that the not-as-important problems that were scoped out for the time being, are bad.
In software under active development there is never a shortage of things that could be improved, especially wrt developer experience. It is very hard not to take personally the whining – especially when it typically comes with very, very little actual effort to make it better.
Because I know this pain so well, I only make these kinds of "suggestions" when I know I can commit the hours to make at least a PoC of what I'm suggesting.
For me, it’s actually pretty obvious who is whom. When there was that disease model that was flawed, everyone on HN remarked on how it was awful. John Carmack just contributed.
Talkers always think they’re contributing, because they usually upvote each other. It’s therefore easy to think you’re a doer when you see the upvotes roll in.
It took me years but “talk is cheap, show me the code” is more true now than ever before. GitHub even has a “suggestion” feature.
I don't think that's a particularly good example. People were rightly highlighting how terrible the code quality was, and therefore that there was a pretty large chance that there was a fatal mistake in it (and it's really difficult to verify predictive models).
I think this guy is more talking about "you shouldn't have used Electron" type comments.
Other people have talked about skin in the game or whether you’re ignoring valid criticism. I think the thing that’s been bothering me recently is the asymmetry of some ‘commenters’. My job is hard, we’re under water in terms of critical things to do vs people who can do them. Which is a point at which someone who has no expertise coming in and going “oh well what about this” becomes toxic. It is incredibly frustrating to have to explain to a dilletante the 20 different things going into a decision and eventually bring them to the same conclusion you already made because it’s actually your job.
That’s not every situation - some times people really do have experience and know better or have tips or suggestions. The likelihood is though- if it’s my job, I’ve probably spent more time thinking about it than the person just coming in.
In case anyone misses the comment by "MicaiahC" at the bottom of the page (not mine, but I clicked their link and found it very interesting), the ethics interpretation that is referenced in footnote 4 is the Copenhagen Interpretation of Ethics, with a really interesting explanation here [1].
It seems to primarily have arisen as a parable of the observer effect in quantum physics, where interacting with a particle (or a problem) changes it, and therefore makes the observer partially responsible for the nature of thing past that point.
Thank you for resharing this - this post puts clear words to a feeling I've felt for a long time. I'm in agreement with the author that noticing bad things does not make you bad unless you can solve the problem in totality. In fact, following that line of reasoning leads to a lot of what I consider "immorality dressed up as morality" today.
Having been the one complaining instead of swallowing the bullshit that is my pride and starting amends, I apologize. I just try to remain cognizant of it at all times when working with others.
Also, as someone “making” completely on my own for the first time, hot damn is it so. much. work. I love doing it though, but it’s not at all for the faint of heart or the quick to lose attention.
A group of high-performers draws non-maker hangers-on like moths to a flame. I would tell them that "Around here, the squeaky wheel greases itself." You have to be careful about using this on the A-listers though. They'll divert from whatever they were doing and de-squeak the wheel PDQ, which may not have been what you were hoping for.
I can really connect to this problem. We used a 3rd party tool chain for a game (compiling obj-c to android) and some devs loved to complain about the state of the tools and that everything is buggy yadayadayada. The whole toolchain was open for us to inspect and fix. In this case it was a matter of responsibility for the other devs. They said it’s not my toolchain I’m not getting paid to do this. But in the end we needed to ship a product. So more often than not a different developer and I looked under the hood and debugged issues and proposed fixes to the vendor. Sure we were not officially getting paid to fix their product but this at least got stuff done and that was in the end what matters.
There is at the moment only one community were I don’t bother to open issues PRs etc. That is the Jenkins ecosystem. It is so darn complicated to get anything pushed up. I proposed a bug fix for some plugin (I think it was the docker plugin) and it stayed in limbo because I did not provide proper tests. I told them that I have no clue how to setup and test the issue. I only know what the cause is and what fixes it. The PR never got merged and I moved on and used a different solution to workaround it (that being not using it on macOS agents which is saner in any case)
This happens in PRs pretty often. Sometimes I meet reviewers who are very nitpicky. It takes like 5-6 iterations before they approve.
I was one of them. A junior engineer on team mentioned that I made them feel they weren’t competent. I didn’t realize how every comment I made tore their morale.
It was a defining moment for me to approach every PR with understanding that even a couple of lines of code has hours of work of a human with feelings and ambitions behind it. I try to praise good work when I see it, stay away from NITs and put all my feedback in single review within ~4hrs. If they address feedback, then it’s approved. I avoid multi iterations if I can.
If there are bigger concerns then I’d meet them in person to explain the why and philosophy behind my suggestions. Most people really appreciate “critique in private, praise in public” methodology.
Also linters and formatters are great. If a thing is NIT-ed a couple of times, create a rule for it (auto fixable rule is even better).
I wrote so many custom eslint rules at Mixpanel. Coding is a lot more fun when the IDE fixes little NITs automatically on save.
Where I work, our code-review system allows anyone to push changes to any PR (provided they have permissions for the repo). It’s a great solution for people who have strong opinions on nit-picky things: they can just make trivial reasonable changes (eg rename a variable called x) instead of leaving a comment asking the author to make them. There’s obviously some middle ground like “I didn’t understand this function so I tried rewriting it: ... <new code> ... what do you think?” And it doesn’t work if you can’t have a good interaction with colleagues or if someone is too nitpicky. So it basically still works fine.
One funny issue I had was when two reviews each attempted to make what appeared to be a trivial change only to have the code fail to compile. We added a comment the second time.
I've been thinking a lot about Roosevelt's Man in the Arena quote this year as I've attempted some things I previously (and still) feel very unqualified for. This attitude has helped me move past those feelings and keep doing.
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."
I don't know what the author makes, but in his article he is commenting quite a lot....
Also it seems like he got into a position with responsibility and now kind of feels superior. (The article is pretty vague, but it's how I interpret it)
I get that it's frustrating when there are a lot of dumb comments in the internet, but this doesn't mean all commenting is bad.
This seems to be the norm on software teams these days. For every one hands on keyboard maker there is at least one architect, security analyst, agile coach, tester etc. In reality it is one person doing the work and 10 commenting on it.
Yeah, I would also prefer if the developer would do the testing (or just create an automated test suite so we can be confident when we deploy the code), do the penetration testing and also create the full network, db and CI and CD infrastructure, not to mention the disaster recovery and budgeting for the project your are working on. Ahh and yes, ship all those features.
I consider the roles you mention hands on fwiw. I'm talking about the self sustaining paperwork roles that once they reach a critical percentage of a project start creating their own "gravity". I'm not a feature Dev.
The fact that someone is willing to cover the salaries of all of those hangers-on (of which i am one) indicates that, despite all of the friction and frustration they create, there might be value in what they do.
The challenge is for the hangers-on to become waymakers and facilitators, to develop some empathy for the folks that are trying to actually innovate and iterate within the confines they have created.
Reminds me of one of Larry Page's rules for management: "Don't get in the way if you're not adding value. Let the people actually doing the work talk to each other while you go do something else."
One thing I always wished for was a comment to visually show how much work/though/research/effort the commenter put into it, as described here: https://news.ycombinator.com/item?id=23078161
Drive-by commentary by a non-expert, non-stakeholders can safely be ignored, but you should listen to comments based on experience and or tech research (as in I-made-a-prototype-and-it-works backed comments).
I've always valued making over "commenting," but that's in the way that it was written in that piece.
I worked for a Japanese company, and one of the classic Japanese aphorisms was "Don't complain, unless you have a solution."
Sounds good, huh?
Until you start to see some of the "solutions" proposed by folks bereft of Clue. As the representative "maker," I was expected to become a wizard, and magick a whole bunch of miracles on the spot. Since there were often "Make it so, Numbah One" types in the audience, I was sometimes directed to "make it so," even if the laws of physics said otherwise.
Luckily, the Japanese managers were generally engineers, and knew the issues, but not so, the Americans.
Sometimes, a complaint is quite valid; especially if you are a stakeholder. It can also be extremely valuable to makers. I often say that kudos feel great, but negative feedback is required to improve. A steady diet of negativity stinks, but nothing changes, if no one is aware of the problem. Challenging people to "shut up until you come up with a solution," when they want to tell you that the system is returning wrong data, is a very, very bad idea. I wonder if any Citibank employees had complained about that transfer screen, and were told to "shut up, unless you have a better idea"?
Speaking of commenting, I've found that a great way to get correct information, is to confidently state some incorrect information in technical forums.
> if you work in media, or you’re a coach or teacher or similar, you’re making something by pontificating, so I still respect you :)
The commentariat writing opinion articles and drive-by tweets is a major contributor to the misapprehension that pointing out problems is as useful as doing something. So, this footnote that excuses those working in the media doesn't make sense to me.
(There is no way to write a comment about this article without feeling a sense of irony)
I think it's more important that comments be specific, actionable, and timely than it is that they be associated with some commitment from the commenter. "Let me know how I can help" is not bad because it lacks commitment. It's bad because it's not specific. It puts the burden on the person receiving it to fill in the blanks. Similarly, "have you thought of X" is often (not always) bad because it's not actionable and/or timely. It might be literally impossible. It might be infeasible in light of available resources. It might have been a good idea before the last five choices were made, or it might just have too little effect too late to do any good. But none of this has anything to do with whether the person offering the comment has any skin in the game.
I've been helped immensely by people around me who have given me their own ideas, or others' ideas wrapped up in a paper, which I could then apply myself immediately and to good effect. I like to think I've done the same for others a time or two. That's not "making" but it's still genuinely helpful.
That's not exactly the point TFA is making but I want to point out that I vastly prefer when people tell me "X is broken/bad/doesn't work/weird/..." rather than "maybe you should change it to do Y instead". Mainly because the vast majority of the time "Y" is worthless garbage, and then I have to spend time explaining why I'm not going to do "Y" because I don't want you to think I'm just not valuing your output.
For a simple but very common example, take videogames. Players will readily tell you when some aspect of your game is broken, when it's too easy or too grindy or too random or too unfair etc... That's valuable feedback. On the other hand when you read gaming forums and see the "fixes" the player propose, a vast majority of the time it's completely missing the mark. Either because they're not developers so they don't realize the complexity of what they're proposing, or they're simply not game designers and they don't realize all the new problems their solution would create, or they're hardcore players and their tweaks would make the game unplayable for the 99% of casual base etc...
In my experience this is almost always true. I always listen to the feedback I get for my software, but I tend to immediately dismiss the "maybe you could do Y instead" part. I know the entirety of the problem space, the user doesn't. The user has a specific use case in mind but I know that there are hundreds of other clients who don't use the program exactly the way this one person does.
So unless you're actually going to write some code for me I'd much rather you'd give me precise criticisms and feedback on your experiences than trying to explain how you think it should be done.
You have access to an army of pedantic jerks. Treat it like a super power. Use it or don't use it.
Don't ever wish the pedantic jerks were better because that never happens. You just become a part of the other ever-present group that's complaining about the pedantic jerks.
Part of the issue too is folks are often “rewarded” for commenting / criticizing far more than providing real empathetic help — often those pot shots are what shoot to the top of Twitter or Hackernews and give that reinforcement of the behavior.
Another way to distinguish them is reality vs perception. Making directly alters reality, but comments only alter perception - the underlying thing is unchanged. A good analogy is that comments are potential energy - they can help us more accurately understand the underlying thing for future revisions. To activate it and truly make things better in the real world though, you have to make.
I tried to fix something at my work once, it was a small bug but any bugs in a large system take time. When I fixed the bug and submitted it, I was scolded for working outside of my sprint task. I tried to defend myself that it was time-sensitive, but it didn't help.
That's a bummer. I'm always doing work outside my sprint/scope/team, probably as much as 20-40% of my time— my company has no issue with it, and I think it's especially valuable for building cross-team empathy, technical understanding, and so on.
Now, I'm quite senior at my org and I also have a track record of my "side bets" turning out to be tremendously valuable on multiple past occasions. But I don't think there's a special policy just for me— this is a company-wide culture thing.
I understand how being scolded for doing the right thing would have felt, but I'd encourage you to find ways to influence the culture of allowing these types of development, instead of swapping to become an ally of those who scolded you in the first place.
Yes and no. You can't blame individuals for culture issues. If independent thinking and action is discouraged (or even punished) then it's not going to happen. In fact, without recognition and reward most positive behaviours will fade away.
While it is harder to make than to comment, the sort of attitude that leads to environments where one can't "criticize without having an alternative" is unbelievably counterproductive.
I'm more of a maker myself and I hate that there are some things that I can't just do but that need to be decided by someone else (which in my company is usually taking forever)
...missing point - multiply comment by the weight of the commenter. Weight may be respect (personal, community, based on their history/work/karma ie. on github/whatever).
I prefer to evaluate comments on inherent merit. If I get a "I'm concerned bought _" I'll follow up with why/where? If it's a feeling they can't detail in any way I might do the x weight or if I agree and investigate a bit to see if it warrants anything more.
> Simply try to do something about a problem, and many people will think you are responsible for the problem’s existence.
Depends on which side of the argument you're taking when attempting "to do something about" the problem. If you're adding to it or give the perception that you are then maybe you need to revise the way you're "helping".
> people who are drowning will attempt to climb on top of their rescuers, killing both
It's gaslighting to compare commenters to a live or die situation, most problems are not as extreme as the image you paint so perhaps you taking it there in the first place is the reason people react to your comments frantically and with more hostility.
I agree with your general sentiment but please don't you use "gaslighting" when you just mean "exaggarating". Gaslighting is a very specific process of denying reality to abuse someone, it's not just any bad faith argument
Another form of this debate is whether the onus of understanding is on the speaker or the listener. I've seen people manipulate this debate back and forth, both have good points and bad points. People will always flip flop depending on what situation they're in because it benefits them, plain and simple.
I view this article in much the same light. Telling users they can't comment without thinking up a possible solution is incredibly dismissive. Usually I've seen this done because teams have shifting priorities or when a lot of effort was dispensed to solve a problem that doesn't solve a problem for everybody.
The fact is that people live in their own worlds. When you develop a tool that tool becomes part of their world and to some degree they depend on that tool. When the tool has lots of influence from people who use the tool differently, obviously strong disagreements will occur. I've seen this with internal tools I've developed before where priority was given to automation features and not UX features or vice versa.
To me, the problem isn't the speaker or the listener, the reporter or the maintainer. It's just discourse.
- If you feel some type of way about a comment then let another team mate tackle it. Maybe the way you feel is justified, but in the grand scheme of things, if you go try to explain your justification to the commenter they're just going to see some powerful maintainer telling them how to feel about a problem with a tool that they chose to make a part of their world.
- Use data and process engineering to tackle your problems. Overusing empathy to design and develop software leads to exhaustion and a lack of caring. Not everyone will suffer from this problem, but many people who overuse empathy cannot stop at just identifying with a problem. They feel the problem. Instead, separate yourself from the problem, quantify it, and build a case for how to work on it. Let empathy motivate you but don't let it rule your judgement or consume you. This data driven approach accomplishes the same thing as the former does but leaves your emotions and well-being intact.
- If you're a naturally curious person: on comments which lack solutions probe the commenter for more information. Make them be useful to you. Sure, it takes more time and it's inconvenient but welcome to software; not everyone has a war on time like Software Engineers do. Sometimes observational style comments I will wrap up and store in Obsidian for a later date. I may not do anything about them now, but if I see repetition then I'll start digging.
This is typical of a certain kind of whininess in the "maker" contingent that is unappealing. Yes, people will criticize you, after all the hard work you did, and yes, people may not understand the exact context of your decisions.
But that doesn't meant that you're not a bonehead, or that the hundreds of people pointing the fact out to you are wrong. The good Lord, in his infinite wisdom, has made just as many industrious fools as lazy ones.
No special virtue attaches to doing something rather than critiquing it. Both can be done with thought and care, or without it, and that's the axis we should judge on.
There can be a lot of value in comments, even ones that have not been thought through very deeply. In fact, casual, uninformed comments are often the most valuable as they're representative of how someone new to your product or project will perceive it.
I've found that the keys to getting value out of comments without getting discouraged are:
1. Not to take comments too personally or get defensive about it. They're not attacking you. In fact they're not attacking anything. They're just making an observation. (On rare occasions, you may get a comment from an asshole who really is attacking you personally, but it's pretty easy to tell when this is the case and ignore them).
2. Take a more statistical view on comments. If one person mentions something, maybe they're just an outlier. But if 10 people mention the same thing, they're probably on to something.