Hacker News Reader

Comment by chasing | Hacker News Reader

Most of these I read and am, like: "I wonder how the other person would've described the situation?"

For example:

> One of our servers needed to be rebuilt, so trying to be a team player and help, I started installing some basic packages. The senior dev on the team turned to me, straight faced and enunciated in a deep and cold voice: “don’t touch anything on it, this is my server!“

Is this because you're a junior-junior developer with an established history of fucking things up? Who has something else they should be working on? Then stay away from the guy's server.

Anyway, let me join the chorus of wondering what, exactly, is so terrible about most of these little stories. Especially when they're so vague as to be nearly useless...

I've been a developer for twenty years. I can tell you some actual stories of developers being treated poorly. They're generally a little deeper than, "Someone said something uncouth in my general direction."

View on HN

Hi,

Author here. Indeed I was the junior dev at the time.

I now regret not making a lot of the points clearer. In this case, I know I would definitely NOT treat my junior devs this way. In my view, using either aggressive tones, or public shaming, is not the right way to resolve things. I wish that senior dev at the time would've talked to me in a way that did not make me feel like I was worthless and intentionally fuck things up - at the end of day, most people try to do good things for their organisation, right? :)

So lets pretend you're the older developer in this case. You've been tasked with setting up this server and you have a way you like servers to be set up. You and your team will be working on it, you want it set up just so.

One morning before you arrive at work, junior dev Fred -- a nice kid, but definitely junior -- gets ahold of the server and starts monkeying around. It's not his job. It's not his server. And now you're either going to have to wipe the server and start fresh or get a debrief about what he has and has not done. And Fred's junior, as noted, so he doesn't always know the best way to do things (although, like many junior developers, he sure thinks he does!). So now you, senior dev, have this wild card that you just don't want to deal with because you're busy and doesn't Fred have other tasks on his plate? Why is he jumping all over your damned server?

So you snap at Fred. "Get away from that -- it's mine, not yours. Please do your job and leave me to mine."

Doesn't seem out of line to me.

It doesn't seem out of line, but there's definitely a better way to handle this. As a senior member of the team, you need to swallow hard, take emotion and ego out of the equation, and handle the situation in a positive way.

While "snapping" isn't unreasonable, the better response is more level-headed.

"I like the fact that you took initiative on something that needs doing. However, we have established ways of doing this. There may also be other things you should be doing with your time instead. If you don't, here, sit behind me and let's set it up together. And in the future, check with me before you jump into something like this."

That's the balance. Firm. Corrective. Accretive. And at the end of the process, you now have a junior dev you can trust to set up servers "your way".

It's not necessary to always treat someone as a child. Nor should it be necessary to deconstruct everything.

Quick to the point explanations. No need to dance and coddle.

The junior dev has the right attitude (wanting to help) but if he thinks tweaking a server some else has set up is a way to help without having gotten some okay shows how green they are and have not yet attained necessary decision making skills.

I like the enthusiasm but I don't like the lack of awareness.

> I like the enthusiasm but I don't like the lack of awareness.

Why not communicate that? Otherwise you're shutting down everything, enthusiasm included. Some of this is style: my example response is pretty middle-of-the-road IMO. But there's a difference between a "quick to the point explanation" that helps the green dev develop necessary decision-making (and other) skills, and something that's the equivalent of "Hssss! My precious!"

You're doing it again. You are using hyperbolic rude language, calling an adult a "child" -- that is being childish.

And you are ignoring the reality that people all have different levels of knowledge and experience -- there is no binary flip between child and adult.

People will extrapolate from their limited interactions with you, because communication is lossy. When you snap "don't touch that" they will obey "stay away from me as much as possible"

Someone says "don't touch that" (with cause) and an individual goes on to parse that as "stay away from me until the end of time" then they brought some baggage into the conversation. It's more than questionable to expect others to be aware of said baggage much less expect them to be extra-super-careful to not tip over the emotional apple cart. Far enough down that continuum and you've arrived at emotional hostage-taking. Much simpler to parse what was said at face value and go on with your day.

Let's break down the terse response: "Get away from that -- it's mine, not yours. Please do your job and leave me to mine."

As the junior dev, what am I taking away from this? The core message ("I shouldn't have done that thing I did.") is crystal clear. But WHY. Did I configure it wrong? Is there some process I'm not aware of? Is Senior Dev even right, or is he just a possessive jerk? Are there other rules I don't know about that I'm going to suddenly trip over?

You can play the "figure it out" card and not "coddle" them. That's an approach, but it's not a very effective one. At the very least, tell them what to do, not what not to do.

I'm having a hard time deciding if this is a troll. In a teaching position I'd agree wholeheartedly, but that's not what's being discussed. You're at work. By definition this means you're supposed to have at least some grasp of what your job duties are and it's a given that stuff outside of your job description is to be left to others unless you're given the go ahead before proceeding. Working a drive-thru, framing houses, industrial fabrication, structural steel work, tech support, professional development, they all have that in common. I certainly should not have to have the conversational equivalent of emailing a team member their job description to remind them to stay on their patch.

Not a troll. I'm playing a little bit of devil's advocate, but I also think this talk of dogs and dinner bowls is rediculous.

There's a line here. I've had "busybody" team members who make life difficult for everyone else no matter what you tell them. And my patience quickly wears thin if I have to tell you more than once.

But conversely, someone who's going to twiddle their thumbs and not help because "it's not in my job description"... I don't have time for that attitude either, and I won't stand for my team making it the cultural norm.

As a senior member of a team, one of your jobs is to develop the more junior people. It is a teaching position: always. If you can't do that, or you think snapping at them "teaches a lesson", it's time to have a conversation about the "senior" in your title.

At the end of the day, we're talking about a hypothetical situation. There are exceptions to every rule, but my starting point is, "How can we make this person better?"

Actually, I don’t think he was doing that (calling an adult a child). I believe when he said “it's not necessary to always treat someone as a child”, he was referring to this part of the parent comment:

“"I like the fact that you took initiative on something that needs doing. However, we have established ways of doing this. There may also be other things you should be doing with your time instead. If you don't, here, sit behind me and let's set it up together. And in the future, check with me before you jump into something like this."”

Frankly, that does seem like the sort of response a parent might give their child when they do something wrong.

> Frankly, that does seem like the sort of response a parent might give their child when they do something wrong.

To me, it sounds like normal, human communication.

I'm not surprised it's also used in parenting.

I'd rather work in an environment where this style of communication is encouraged (as opposed to the response the author got) - wouldn't you?

> I'd rather work in an environment where this style of communication is encouraged (as opposed to the response the author got) - wouldn't you?

no.

> However, we have established ways of doing this

Also you need to explain why this way is the established way.

Indeed. Hopping onto a server unasked and installing packages is not being a "team player." It's being a busybody. In this situation being a team player would've been approaching the person actually tasked with the job, asking if there's anything you can do to help, and taking yes or no as an answer.

Exactly. A small difference in the server config from what you expect can mean hours and hours of debugging...

You are confusing "not a team player" with "being a noob"

Actually seems in line to me as a learning moment for the junior dev. It's much like when I get a new puppy who wanders over to the the older dogs food bowl. The older dog gives a slight growl and the puppy has learned not to do that again, and one hopes in the general case (not all dogs are quite that nice).

Hopefully as a junior dev this person learned a couple things here. First, that they do not know everything and second think how their actions will impact the team.

Teaching new devs to stay away from teammates is not a good lesson. Humans have more complex relationships than dogs.

Actually it is teaching the opposite. Engage your teammates and ask first before thinking you know it all and start doing someone else's job.

Hi,

Author here. This is going to attract a few more downvotes for me, but I have to respectfully disagree. Partially because the scenario wasn't quite what had happened, but more importantly, even in situation exactly like what you have just described, I would not have just lashed out on my junior colleague - to me no matter how junior they are, they are still my colleagues and they still add value. There is no reason why I need to be aggressive to them when they made mistakes.

If someone started installing packages on my server willy nilly I would be very angry. Servers are a personal thing. Furthermore, it is downright unprofessional to be tinkering with other people's servers if they did not ask you for help!

Are we talking professional or personal here? You seem to be jumping between the two.

A server purchased for your work is not _your_ server. It is a company asset. If you buy a server for yourself and your little brother messes with it, go ahead and get mad and lash out. If your business has procured a new asset, you are tasked with managing it and someone else gets in your way (junior or not), deal with it like a professional.

"Servers are a personal thing."

If you are paying for the servers out of your own personal funds, sure.

But if it belongs to the company employing you, no, it's not a personal thing, it's a corporate thing.

I suppose "personal" might not have been the best word to describe this. What I meant to convey is that Servers are a fragile highly configured entity. It doesn't matter if the server in question is in a corporate environment or if it's your "personal" server - you don't want junior people editing configurations.

To me, concerns oriented toward authorization and general security would offer a more objective and policy based framework for the discussion. The zeitgeist is servers are cattle not pets and that deploying chaos monkeys helps insure robust infrastructure.

Yes, I never make dumb mistakes, I am a living walking integration resiliency test :-)

I think he was talking about a work system that the senior dev was mostly responsible for, not the senior dev's personal server.

I completely disagree with the idea that a work box should ever "belong" to someone.

Cattle not pets, man.

https://medium.com/@leahbent/overcoming-special-snowflake-sy...

This is unproductive.

So, the assumption that someone adds value because they are a colleague is false...there's a concept called "Net Negative Producer" See here: http://pyxisinc.com/NNPP_Article.pdf

Hi author, I think you need toughen up. The real world does not need to coddle your feelings and won't. Some of your fellow devs are going to be rude, but surprise! that's not going to get them fired. What counts is job performance.

Sorry if this sounds tough, but that's the way it is.

> So you snap at Fred. "Get away from that -- it's mine, not yours. Please do your job and leave me to mine." > Doesn't seem out of line to me.

Do you snap at your customers or bosses if they don't behave the way you want? If not: Why do you snap on your juniors?

You can easily judge the character of a man by how he treats those who can do nothing for him.[1]

[1]Various possible sources

But what about Freds feelings ?

Hi Fred,

This is a challenging post, you seem to be getting knocked around with it quite a bit here. Hang in there. As you point out in your since published comment, treat this (and all your vignettes) as a learning experience. To help start you on your path for this post, I'll offer my 2 cents.

First, try to write posts with positive messages (this one has an overwhelmingly negative tone despite your intentions). Perhaps recast the examples as learning experience. Think long and hard about the situations you describe and try to learn something. Then write a post on what you learned. Life's hard. Help others learn from your interactions (and learn yourself).

Second, keep your issues to the real ones. It's okay to make a long list like this in a brainstorming session while a post is in the early draft stage, but try to trim down the stories to a handful of substantive ones (each with a lesson and reason for being there).

In general, it seems you've been in some stressful situations (for yourself and others). People (even the most vaulted professionals) get cranky when things aren't going well - by whatever definition of well is for the context).

You do seem to believe that transparency is a fundamental right. Its not. Noble, sure, but not ubiquitous or even always a good thing. Many times management will shield their reports from the disaster unfolding above them. Some times this is a good thing. It might be very distracting if everyone had perfect knowledge. I find its very important to have a good working relationship with your manager. Understand what motivates them and deliver on the tasks you are asked to (things can get messy when you "help" others (especially at the expense of your assigned tasks)).

Much more to say, but I need to go deliver on some of my tasks now. Hang in there. Good luck. Write a second post with a positive spin on the major things you learned from this one.

Hi bsaunder, thank you so much for the advice and encouragement!

Yep I can see why the negative tone is very off-putting to many people. Had I have a chance to do over I'd definitely do what you've suggested here and tackle it from the positive / lessons-learnt point of view. :)

Many thanks! :)

> You do seem to believe that transparency is a fundamental right. Its not.

I wouldn't frame the issue in terms of rights, but management that hides relevant information is fundamentally dishonest and disrespectful. I wouldn't call it criminally fraudulent necessarily, but it's in the same spirit, though perhaps in a more grey area.

You offer valid criticisms, but I would say over all this post generated a lot of impassioned discussion and seems to have struck a nerve with a lot of developers, whether they agree or disagree.

Which is not necessarily a bad outcome for a piece of writing.

Heat and light are both energy, but not equally valuable in every situation. Whipping people into a frenzy is highly effective for some end, but not worthy.

True, but I personally believe this discussion has been largely constructive and useful. Communicating while being accurate, authoritative, professional, and not unnecessarily combative or personal is a hugely important skill for developers, and the examples presented were a great springboard for discussing the topic.

The transparency part is dangerous thinking. Management isn't perfect, low-ranked people are not clueless cogs, and sunlight is a great disinfected. Trust matters, and secrecy hurts trust.

Of course. There are some general lessons about communication that you can learn from these examples. But nobody will do the right thing in every social situation 100% of the time.

It's not that you don't have valid complaints here. It's that you've taken a huge number of examples that range from the simply ungraceful to outright exploitative, and combined them in one huge file that makes it look like you're seeking reasons for your grudges.

A good workplace isn't one that avoids mistakes and conflict. It's one where the team feels invested and supported in working through that conflict in pursuit of their bigger goal. That goal doesn't have to be some world-changing potential; it can just be doing good work, getting paid, and taking care of yourselves.

Yeah, I dunno, I think you missed the point. The majority of what I read there was pretty basic. This is how masculine (note, I didn't say male) professionals generally talk to each other. Is it the most optimal way? Probably not, but there is way way way worse.

Like, you know, yelling at someone in a meeting, swearing aggressively, etc etc.

> This is how masculine (note, I didn't say male) professionals generally talk to each other. ... Like, you know, yelling at someone in a meeting, swearing aggressively, etc etc.

This behavior will eventually get you fired. It's unprofessional, demoralizes employees, and opens you up to legal embarrassment if one of the people you berated ever sues your company. I will agree that the people who engage in yelling/swearing at employees are generally male, but it's absolutely not true that this is how masculine professionals "generally"* conduct themselves at most companies.

* If you're referring to startups in particular, where a founder cult-of-personality can have a totalizing effect on employees, they are the exception and not the rule.

I think your reply just confirmed that OP has a point. "Boys will be boys" is no justification for rudeness

Masculine professions: fireman, wall street stock trader, police officer, navy seal... and software developer?

No, this still doesn't make sense. Professionals can and should be courteous to one another. Software developers can, too.

"Masculine professionals" are people, and should always be prefaced with a qualifier like "some" or "many." The original statement is certainly overly general in saying that all masculine professionals (I read it as all "real men" <ha!>) act the same way when women and children aren't in the room.

"Masculine professions" are things that people do, and we can definitely challenge almost all generalizations here. Unfortunately, the person you're replying to never mentioned professions.

I guess I misread it. Although the long paren and line break don't help.

> wall street stock trader

???

Guess someone likes to watch Wall Street.

I think what's missing is some resolution and reflection to each of the anecdotes. For many of them it's not clear to me what the point of the story was, or whether or not you thought you did anything wrong or not, or whether you understood the point of view of the (apparent) antagonist in each story. Context is lacking, too. When did these take place in the progression of your career? Has your perspective changed since the time the event happened?

Life is not roses, and people should learn to have thick skins.

That said, saying "Don't touch my server!" is not at all abusive, especially if there's a history of people messing things up they have no business touching.

I can accept that laying rules like 'Don't touch my server' before people start writing over each other's work does not seem abusive.

It makes me wonder: in case the senior dev did not disclose this policy to the junior dev prior to the meeting, what was the senior dev expecting? If no rules were communicated, it falls to the senior dev to lay them out. At the point that a junior dev does not follow a previously undisclosed procedure, why would that make the senior dev angry? The senior dev can note that the server is on his list and ask why did not the junior dev check who is responsible for the server?

> what was the senior dev expecting?

Ask for permission. Failing that, ask for forgiveness. It's rude to mess with other people's stuff, or even shared property.

Imagine it wasn't a server but a conference room he decided to apply his vigilante justice to. The result may have been a positive surprise but being a junior there's also a good chance he was ignorant of the requirements and have made things worse for others.

In an ideal workplace every requirement is documented and every policy is written down and laid out to every team member. In the real world it's better to expect not to know everything -- and that's a fairly valuable lesson to take away in a junior role.

That said, the response may be blunt but it should never be angry, especially not beyond the scope of the actual intervention itself. If you're about to cause significant damage, it's okay to put that in drastic terms to make sure you stop right there. But it shouldn't be personal and it should be considered a learning experience by everyone involved.

Everyone should be allowed to make mistakes. They should just be expected to learn from them and avoid making the same mistakes in the future.

Does there really need to be a rule for that?

If somebody is working on a server, and you know it, it's common sense not to mess with it.

From the context in the blog, it is not communicated clearly who was assigned to rebuild the server and whether the senior dev communicated that he is working on it.

The rule can be a morning stand-up or Jira note, saying that the work is assigned to this person. At the time, developers (probably) were not accustomed to have either.

You also need to be more situationally aware and/or humble. I'm a junior dev, I probably should ask for permission or guidance before mucking around. That's life.

Yea and then you get points off for not being a "self-starter" haha.

Yeah if it was properly structured as a business you would never have had access to those resources to begin with. This kind of negative behavior is a relection of poor structure.

Basically, we could all learn to mind our manners. Right?

"what, exactly, is so terrible about most of these little stories."

That's exactly the point. Everyone hears this sort of thing and mistakenly infuses it with some significant meaning when really, it's just developers talking to developers.

Whether that was the original OP intention, I dunno, but it's the best lesson here.

Hi,

Author here. I'm glad there are people like you who share the same view. :)

I do admit that I haven't explained things well in my blog post, but some comments here that suggest being aggressive/rude is okay and/or justifiable as long as there's another side of the story is really an eye opener for me and I'm somewhat shocked... Is being kind and decent to another fellow coworker (and a human being for that matter) too much to ask? :\

I've worked in environments that turned toxic and what you posted is all too familiar. I learnt from it too and the signs that things are perhaps wrong are evident much quicker now. I also learnt a lot about how not to manage/lead from similar incidents.

> Is being kind and decent to another fellow coworker (and a human being for that matter) too much to ask? :\

Provided your comment is currently grey, I suppose it is, for some people...

I mean, regardless of the justification, this is not a very professional way to talk to a fellow colleague. Something like, "it's important that this server is configured correctly, so I think it would be better if I took care of it myself, if that's ok with you" would have been a lot better.

> Something like, "it's important that this server is configured correctly, so I think it would be better if I took care of it myself, if that's ok with you"

This is worlds better than being rude. In my experience it errs a little in the other direction because it leaves the situation a little ambiguous (and thus invites more conflict) by implying that it is debatable. Especially the "if that is ok with you part"

I might try something like: "it's important that this server is configured correctly, so it would be better if I took care of it myself, I Appreciate the effort though!"

Yes, however, depending on the situation, it might be better to try to figure out why they want to do it themselves and offer an alternative, if possible. For example, if they want to do it because they want to gain experience configuring servers, you could tell them something like "I think I should really do this myself, but how about configuring $NEXT_TEST_ENVIRONMENT_SERVER next week?" or "Ok, then how about us doing it together?".

I find it interesting that both of these revisions include an assumption of incompetence by the junior, while the original was more ambiguous in that regard.

He clarified somewhere in the comments that he was a junior that the time.

honestly this is not correct from a communication perspective. Literally this is a team lead educating a junior developer who completely oversteps his bounds and does not even understand why this is an issue.

In dissecting your statement, "it's important that this server is configured correctly, so I think it would be better if I took care of it myself, if that's ok with you"

clause one is ok, but does not provide a 'why'. clause two leaves too much leeway as to whether the junior developer action is acceptable going forward. clause three is actively negative as it opens up debate for something that is not up for debate.

a proper communication would have been to take the junior somewhere away from anyone else, made sure that the tone of voice was unagressive but authorative, and stated something along the lines that, this is not a major issue but we need to have an important quick conversation, first explain that number 1 what the issue is, explain number two the underlying why, and explain what will happen go forward, make sure he understands this is not a debate, this is you giving him direction on what will occur going forward, i would give him an oppurtunity to meaningfully contribute in the future if it made sense, finally make sure he understands.

being to flimsy or wishy washy is NOT good communication

I get your point, but I think your management style is very different from mine. People overstepping their bounds getting reprimanded in an authoritative voice away from anyone else is simply not the kind of work environment I want to foster.

If this is a recurring problem and previous, friendlier attempts have failed already then it's necessary to rephrase the message in a clear, authoritative manner but in my experience this is very rarely, if ever needed.

I am going to respectfully highlight why I think this is a mistake.

The original communication does not actually communicate the underlying issue in this particular case. Its not a 'friendly' vs 'unfriendly' communication issue. Its an issue that the communication is NOT actually communicating what the intent of the message is.

The intent of the message is 'this is not your responsibility, although you intend to help you are actually making more work for others not less, do not do this or similar things again, without consulting the person who's responsibility it is beforehand' thats the message.

the way its phrased if the person is a senior he is going to understand what you are 'really' telling him in nice words. if the person is a junior he is going to think you are really entering a debate about how this should be approached, and that you need to reach consensus with him about the approach, and that although you didnt accept his contribution this time, next time or next situation this may be a reasonable way to contribute to the team.

you have communicated the wrong thing to your target audience. its bad communication. its not 'unfriendlier' to communicate directly what you actually mean and to provide clear guidance and correction to a junior.

Unfortunately I can very much understand the original snap. I know I've said things like this and I'm sure a lot of people here have, too, even if they don't remember. I'm willing to assume that the original speaker was in some way overstressed, overworked and had just lost patience at that moment. It's easy to know what the better thing to say is in retrospect but usually people just want to get their message across.

Sure you can't prevent snapping. But you can be mature and self-reflect and apologize afterward, which often motivated self reflection and apology from others as well, leading to improved behavior all around in future.

Agreed, but if you don't get that, you shouldn't take it personally. Which I hope is what the OP is trying to say.

Honestly, if we shouldn't take personal interactions personally, then what exactly should be taken personally?

I hope you recognize that your argument is a strawman.

It's absurd to never take any personal interactions personally. It's equally absurd to take every personal interaction personally.

Your argument is basically the twitter problem: stop judging people by individual statements or interactions, understand that there's an entire separate being on the other end of every conversation with concerns and experiences of their own.

Yeah, and on this end is me. Therefore a conversation is personal. This is flabbergasting. Under what conditions am I allowed to judge a personal interaction based on how it affects me?

> It's equally absurd to take every personal interaction personally.

Ok, which personal interactions should not be taken personally? Do you understand how ridiculous that sounds definitionally?

> Ok, which personal interactions should not be taken personally? Do you understand how ridiculous that sounds definitionally?

If you honestly don't understand how to apply this kind of nuance that is concerning and could indicate an undiagnosed psychological condition (e.g. autism spectrum) -- consider talking to a professional. But I'll try to elaborate:

Try giving people the benefit of doubt. The vast majority of people are not intentionally being obnoxious. There is a multitude of reasons someone might come across as hostile without it being something you should take personal, for example:

* sleep deprivation

* hunger (e.g. skipped a meal)

* bad posture (causing discomfort they may not even be aware of)

* physical illness (e.g. a simple cold)

* physical conditions (e.g. menstruation, indigestion)

* stress (e.g. close deadlines, financial problems, relationship issues)

* other psychological conditions (e.g. grief)

* mental disorders (e.g. depression)

* bad social skills (some people genuinely can't communicate well)

* non-native speakers (may be unaware of subtleties in tone and voice)

* language disabilities (e.g. stuttering may make them anxious when they have to talk)

Instead of judging people by singular interactions, try to recognize patterns in their behaviour.

> If you honestly don't understand how to apply this kind of nuance that is concerning and could indicate an undiagnosed psychological condition (e.g. autism spectrum) -- consider talking to a professional.

This kind of passive aggressive, ableist bullshit is completely unacceptable.

Either you're trolling or you should take my advice to heart.

You can't delineate a set of criteria for when to take a statement said to you "personally". For one thing, taking something personally isn't a binary attribute, it is far more complicated than that.

Use your best judgment and try to give people the benefit of the doubt (this requires practicing empathy, which is difficult). Realize most people are usually not thinking about you, because they are too busy thinking about themselves. I find it beneficial to try to act in a way that leaves the most people feeling positively (including myself).

This is still ridiculous. Because someone else is being inconsiderate of how their actions affect me, i should ignore how their actions affect me. I have to admit i am being somewhat coy by taking issue with the post i replied to, which, by the way, makes a general prescription of what not to take personally without knowing any context. I understand the attitude of ignoring things that cause personal discomfort or harm based on intended effect.

I think it's ridiculous, and more often than not people prescribe such behavior for others but are quite comfortable taking personally that which... personally affects them. Silent forgiveness for the inconsiderate instead of numerous means of improving one's relationship with them. Telling someone that they are treating you in an unacceptable manner is, by definition, taking it personally. And being passive and avoiding such conversations is exactly how unpleasant social interactions persist and grow into a climate of alienation and dysfunction.

> You can't delineate a set of criteria for when to take a statement said to you "personally".

Sure i can. When it affects you, personally. People who disagree with me can't come up with a set of criteria. Without such a criteria, there is no justification of the attitude.

> For one thing, taking something personally isn't a binary attribute, it is far more complicated than that.

Taking something personally is binary in this way: you either ignore the personal effects a relationship has on you or you signal/take action based on those personal effects. All of the complication lies in how one proceeds based on their feelings. Mediation and conflict resolution are complicated yes. But you can't resolve a conflict without signaling that it exists and that you have a personal stake in it. That is exactly what taking something personally means.

There are large-scale social implications. People who are lower in status are told to not take it personally more often than people of higher status. When a boss is emotionally abusive, people are far more likely to excuse such behavior than if an underling is being emotionally abusive. In other words, prescribing to people to passively accept uncomfortable or harmful social interactions without protest becomes a mechanism of power. The effects are alienation, depersonalization, stress, and social dysfunction. That shit infests our society.

To be clear, I never said things should never be taken personally. I tried to imply that is impractical to try to come up with super specific criteria when you take it personally, and when you should let it go. It's going to a fuzzy thing that depends on specific circumstances. Sure, you can have some general principles, but I don't see how one can try to formalize it.

I also didn't say you should ignore your feelings. Personally, I make an effort to be aware of my visceral reactions when things happen, and to not let my automatic, gut reaction run away with itself. But I do want to my understand my feelings, not just stifle them.

However, I also try to emulate the mental space of the person who said the thing, and the wider impact of me speaking up, and only say something if I feel it will be received in a productive fashion and will be generally beneficial. Highly personal criticism (even when constructive) usually loses effectiveness if it is overgiven, and is also a socially expensive thing, as it often feels negative for the recipient in the initial instant. It also carries less weight when coming from someone you don't know that well or haven't built up trust with, which makes the expensive interaction to give feedback often times a waste, with little ROI.

I think most people are reading that example and imagining a one-off harsh interaction with someone who doesn't usually snap like that, while the way you describe it:

> how unpleasant social interactions persist and grow into a climate of alienation and dysfunction

is more like someone you expect to be rude to you all the time unless you tell them not to be. If that's not going to happen, then just letting it go could be a reasonable response. There's also the fact that this is being recounted after the fact, which implies not just hurt feelings in the moment but a lasting grudge held over something most people wouldn't be bothered by, which can also be toxic to relationships.

> > You can't delineate a set of criteria for when to take a statement said to you "personally".

> Sure i can. When it affects you, personally. People who disagree with me can't come up with a set of criteria.

Fair enough. Everyone takes offense at different things. But if your threshold is set so low that interactions that most people wouldn't find "uncomfortable or harmful" are "unacceptable" to you, then any interaction with you becomes difficult, and that difficulty will drive people away and alienate you.

That's how you're coming across here, and that's why people are suggesting you try to change yourself, change the way you view these interactions, instead of just insisting that everyone else change to accommodate you. "Don't take it personally" doesn't mean "don't react to things that bother you", it means "don't let it bother you". For things that have no ill intent and don't bother most people (even when it's directed at them), that's good advice.

Don't invest the weight of your entire consciousness into each individual sentence as a standalone universe. Build a greater context over all the interactions.

Intention.

Intentions don't change how an interaction affects me. Your definition of what to take personally is exactly that part of an interaction that is not me. That's absurd.

I try to balance my gut instinct and my empathy and theory of mind.

If someone does something that offends me, but I know after a few seconds' thought that they didn't intend to, for example they were busy or look upset for some reason, then it would be foolish to take offence.

If someone does something that is extra polite and friendly and massages my ego, but I know that they hate me and are being two-faced (for whatever reason) I might take offence.

Of course, everyone's different, but most people's theory of mind is developed to this point past past a certain age. I don't think it's absurd to take some responsibility for your own thoughts. I think it's how society hangs together.

I think a lot depends on team culture and perhaps that's where these kinds of anecdotes fall down - without the context of the team and personalities behind them, they are just snippets with three sides to every story.

From your comments and reaction to the post I can see why you have been in the same position for 20 years.

Reply on news.ycombinator.com