
Don’t offer co-workers help unless asked - denzil_correa
https://msutoday.msu.edu/news/2018/keep-to-yourself-dont-offer-co-workers-help-unless-asked/
======
meuk
The article doesn't really distinguish between _offering_ help, and _pushing
your help_. I work in a large team, and I often work on some obscure feature,
and it's not always clear who has experience with it. If someone notifies me
"hey, I have experience with that part of the codebase, I'm here if you need
help", that's what I call _offering_ help, and _that_ is very useful. It's
still up to me to decide if I need help or not.

~~~
atomical
If it's a large team how much time are they spending knowing what everyone
else is working on?

~~~
yitchelle
This is when a team leader is helpful. He would say "Frank, I see that the bug
that you are working is in the datafile handler. I know that Jill has has some
experience in this area. Frank, could Jill provide some assistance here?"

------
LandR
What if they are doing it wrong and I notice?

Do I wait until they are finished, and then fixing it will take so much
longer... Or I can offer help earlier on and get it back on track sooner.

We have an issue here that someone will work on something for days or weeks
and are producing complete garbage. But then when they've finished and they
show the pile of crap they produced you can't tell them that's crap. As
they've spent too many hours on it to redo it.

So if I see something like this happen, I'd rather "offer help" early on and
try and get it onto a sane track and save a lot of headaches down the road.

~~~
levosmetalo
> So if I see something like this happen, I'd rather "offer help" early on and
> try and get it onto a sane track and save a lot of headaches down the road.

If you work in a kind of company where someone can work for weeks or months on
some feature without any code review, design and architecture review, merging
to mainline and testing processes, it's quite possible that the "complete
crap" that "kinda works" is completely acceptable solution.

And it's like that in most of the enterprises.

~~~
LandR
It doesn't work though. The stuff that is made is often garbage performance
wise, falls over a lot and ends up people spending hours trying to keep it
running / restarting it.

We also have no testing process, no code review process. I find out about
stuff when I have to fix a bug in it. That is often the first time I will see
something that is deployed to production.

Also deploy is basically the drev works on something, which like I said is
often garbage with no thought put into it, then just copies it to a live
server.

I then get told it's not working and can I have a look, see that it looks like
it's been writen by someone that suffered blunt force trauma to the head
before they started and die a little inside.

Every. Godamn. Time.

I need a new job.

An example:

A database update that was taking 9 minutes to insert a few thousand rows.
Why? Because it was a nested foreach loop with a sql call in the middle...

Or when they had an array (in C#) but they didn't know how big it was going to
have to be. There solution was to make it way bigger than it needed to be, _by
a lot_ , add to it. Then have a loop where they started at the end and resized
the array by one item at a time until they had no more nulls... At least they
left a comment in that saying someone needs to rewrite this as it was bad
performance wise... I guess that's something.

~~~
CydeWeys
Good christ, why would you use primitive arrays in C# like that?! How would
someone not know about the _List_ class? It sounds like suffering from
premature optimization, and then completely failing at knowing how to do the
optimization part.

~~~
LandR
There are still some devs today that have years of experience that avoid
List<T> because they don't understand generics.

Yes, honestly.

Or even better (worse), we have a database table that stores the state things.
State can be one of a small collection of states, e.g. Foo, bar, Quax. It's
enumerable.

How do we store it in the database table? as an nvarchar

Id = 1, State="Set State to Foo"

So any query was having to do a string parse to get the state out by grabbing
the string after "Set State to "

Which was killing the database as the table has millions of rows and is used
all the time.

I have so many examples like this.

~~~
CydeWeys
The last time I ran into something this bad was ten years and two jobs ago
when, in front-end JS, someone needed a lookup map, but instead of just using
a JS object, he implemented an array where the even entities represented keys
and the odd entities represented values, and for lookup he used a for loop
over the even indices of the array to iterate through keys until he found a
match. Yes, it was terrible. He came from IBM too.

I haven't run into anything that bad since; even my interns know a lot better.
I'd suggest that if this is a routine problem for you, you might want to go
find a team or job that has better programmers.

------
akuji1993
> Johnson surveyed 54 employees between the ages of 21 and 60 who worked full-
> time jobs across a variety of industries, including manufacturing,
> government, health care and education. He collected data over 10 days for a
> collective 232 daily observations to assess daily helping, receipt of
> gratitude, perceived positive social impact and work engagement.

So a way too small base to gather any helpful information from.

~~~
allrightyeo
I agree, it was as well seasonal. Does not consider the types of task, the
working dynamics, maturity of HR processes, distribution of tasks, how
recently the employee was hired, overloaded professionals versus professionals
with new tasks that needed to be learned. well at least the news did not
present us with these data. this behavior study should have been placed in a
bigger time frame, 1-2 years?

~~~
akuji1993
Also they should've limited the field of research. Pick one department, survey
everyone in there for at least a year and see how that works out. I don't like
these "quick results" studies because in the end, you have multiple faulty
methods in there.

You will alter the study based on your assumption on what is going to be the
result. If people know they are surveyed, they will act differently for at
least a few weeks. If you have too many different departments, your results
will vary so much, you cannot make any assumptions about the result. And on
and on and on.

------
CydeWeys
And yet, the biggest team productivity issue I've seen is when people get
stuck over their head and suffer in silence for days if not weeks on end,
unable to make progress, while not asking for help. Just a tiny bit of help
would go a long way, and looking to see when people aren't making progress and
then proactively giving some pointers can save a huge amount of time. In older
more complicated code bases it's often the case that there's some tricks or
gotchas that only take 5 minutes to explain, but that could take weeks to
figure out on your own without guidance.

~~~
ncphillips
This is huge.

My rule of thumb is that if you feel "stuck" for more than an hour you need
to: (1) stop what you're doing, (2) go for a walk, and (3) let ~everyone know
you're stuck.

If nobody can help because they don't understand what you're working on, then
that's a huge red flag. You definitely should talk to them. The more people
that understand that problem the better.

~~~
thrower123
An hour is not enough time. That's barely long enough to have started thinking
and researching a problem. Of course, it would probably make more sense to
scale the timeout with the difficulty of the thing being done; if you're
stonewalled on something trivial vs pondering architectural issues.

~~~
CydeWeys
It depends on the scale of the problem. An hour is entirely too long to waste
on trying to figure out which API method to accomplish a given task, but not
nearly enough to spend on properly architecting a new system.

------
presscast
The comments here are far less insightful than I've come to expect from HN. It
seems like this article has touched a (several?) nerve.

Can we just get the following out of the way?

1\. Sometimes it's good/necessary to offer help to inexperienced colleagues

2\. Sometimes that which is _called_ help is actually counter-productive or
manipulative

The above are simultaneously true.

With that out of the way, a more fertile topic of debate might be how to
distinguish the two scenarios. Here's a good start:
[https://news.ycombinator.com/item?id=18290901](https://news.ycombinator.com/item?id=18290901)

------
ncphillips
The abilities of offering and receiving help are like any other: they are
skills that can be developed over time.

This is the topic of personal communication, and it is much more complicated
then it is being given credit by the article. Furthermore, none of the
experiences described match my own at Forestryio.

For example:

> Johnson explained that there are two basic kinds of help one can offer –
> proactive and reactive help.

This is a pretty coarse simplification. Further, it does not describe how help
is given at Forestry.

First, if I have no work queued then I will offer help to the team. This may
be a specific offer, but I will state "I have nothing to do right now" and
then I will ask either:

* Does anyone (needs help/want to pair/need some eyes, etc.) * What is the most important thing I could help with?

I am _proactively offering_ help, but I'm not forcing my way into their
problem space. In a sense, I am proactively making it known that you're not
going to fuck up my flow by asking me a question now.

Second, we really try to make it clear that if you're stuck on a problem for
more than a couple hours. You should look for help–someone has problem been
down this road before. Working in isolation increases the likelihood you're
going to go down a rabbit hole and waste a bunch of time.

> What we found was that on the helper side, when people engage in proactive
> help, they often don’t have a clear understanding of recipients’ problems
> and issues, thus they receive less gratitude for it,

This just isn't the case at Forestryio. The team takes responsibility of the
problems and issues, not the individual. If I offer to help and I don't
understand the problem, then they will be explained to me. Having two people
understand the problem is important. If they can't explain to me what the
problem is (or admit that you're not sure) then why are they working on
solving that problem?

> On the recipient side, if people are constantly coming up to me at work and
> asking if I want their help, it could have an impact on my esteem and become
> frustrating.

This is an ego problem. Grow the fuck up. Learning to _accept_ other people's
help is a must if you want to work on a great team.

------
Kaveren
I don't have an opinion on the findings, but can you really draw results from
a single study with only 54 subjects? Specifically when something like this
could differ across industries and those 54 are spread out among them.

~~~
Double_a_92
The conclusions seem reasonable though. I.e. wouldn't you find it
condescending if somebody offered you help when you didn't even hint that you
could need some?

------
unwind
From a quick reading, it seemed this was mostly about people's feelings. In
other words, the survey indicated that people feel better if they're not
offered help, but instead get help only when they ask for it.

This seems reasonable, but it also seems a bit short-sighted; not _all_ that
happens at work is about people's feelings, surely?

Sometimes making mistakes can lead to problems later, so stopping someone from
doing The Wrong Thing(TM) ahead of time can actually help make them feel
better in the long run, even if the immediate response is one of discomfort.

------
EZ-E
Related opinion : sometimes it's best to let the worst performing coworkers
fail (if you don't have high vested stakes in the company)

~~~
Insanity
but it becomes hard to rate performance. If they get stuck on a certain
problem, they might be the 'worst performing' on that part, but they might
have other strengths.

Judging who is performing bad across a large team is not (always) an easy
things to do.

------
redhale
> when people engage in proactive help [...] they receive less gratitude for
> it

OK, but what if maximizing gratitude is not my primary objective?

------
molly0
We had this problem that developers didn't ask for help.

So we decided that if someone was stuck for more than 1h thinking about a
solution to some problem it was against best practice not to ask for help.

Enforcing this policy didn't result in people asking more questions but
instead problems being broken down to smaller sub problems. It was kind of a
good thing.

------
alkonaut
When I offer "help" it's usually because I noticed someone screwed up and my
options are telling them to fix it, offering "help" in fixing it, or fixing it
myself.

And if I'm offering that kind of "help" it's because it's not realistic to
wait until I'm asked.

------
agentPrefect
Co-workers who have a tendency to "shepherd" newbies are downright annoying.
Other than the initial on-boarding, there is no reason to be involved in
solving someone's "new comer experience".

~~~
Jacq5
Not in all the cases IMHO. Sometimes a newbie is lacking experience and be
might not be aware of that. He might get overconfident and cause troubles for
other and himself. This is where "shepherd" would have helped. I had few
mentors that just knew when to help out and what questions are on my mind and
that helped a lot.

~~~
agentPrefect
But this is exactly what the article talks about - and what I agree with - let
them ask for help. To each his own, I agree that some people need that
intervention, but for the rest of us, don't assume it.

~~~
Insanity
I agree - but make sure you do let them know that it's okay to ask questions.
Sometimes newbies might feel bad to ask for help.

I've had someone who recently graduated work in my team, who'd ask help and
always apologize a ton of times for disturbing me whilst I had 'more important
things to do'. Even though I made it clear quite frequently that I'd rather
get disturbed rather than have him be stuck for hours on end.

Sometimes asking for help can make a new employee feel bad or judged and in my
opinion, it is part of our responsibility to make sure this is not the case.

(Again, this does not mean to push your help, but just making it clear you are
available in case they need you)

~~~
C1sc0cat
And some cultures may not feel they can ask for help.

------
thiagooffm
I don't give a f. I'll do whatever I think is right rather than optimizing
myself over some study.

~~~
MaxBarraclough
Do you believe the study to be methodologically flawed? Or just inapplicable
to you specifically?

~~~
nmstoker
I believe it's not quite as simple or black and white as they say. Things
generally don't fit into the help others or help yourself category so neatly
in real life. Typically if you're in a team, the other team members will be
doing things that impact you directly or soon will do.

And focusing on others vs self misses a more reasonable split: brief targeted
help and more involved help.

Often in companies, people reinvent the wheel and struggle with problems with
well established solutions - provided you can briefly give a pointer and do it
with sufficient tact as to not offend then this kind of thing is almost always
worth helping with.

------
therein
Sample size way too small to conclude anything meaningful.

