Hacker News Reader

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".

> However, we have established ways of doing this

Also you need to explain why this way is the established 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.

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"

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.

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?"

> 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!"

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.

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

This is unproductive.

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!

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 :-)

"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.

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.

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.

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 ?