Don’t offer co-workers help unless asked | Hacker News Reader

Don’t offer co-workers help unless asked

msutoday.msu.edu

54 pointsdenzil_correa57 comments

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.

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

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

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.

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

That's the main issue. As a company, you must be able to make the decision to throw away stuff you've built, IF it's complete garbage from an objective point of view (the last bit is important: Just because you think it's complete garbage doesn't make it garbage.)

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

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.

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.

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.

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.

I feel your pain.

The worst part is that, when you push for some basic SE practices, the senior devs/researchera/PMs say (1) but we don't have the time to do planning/reviews/testing/mentoring, just look at the schedule, and (2) they don't want their own code to be subjected to review.

I slid sideways away from that endless crunch / hero 10x coder / code solo project, but I need a proper new job too.

There is no wrong, just different approaches! \s

I think the biggest issue is not the offering of help (or requesting it ftm), but just timing and approach. I've notice, so this completely anecdotal, that if you make an appointment, albeit a 'hey, i noticed you are working on X, had some ideas, have some time to discuss/update me on that' or 'hey, i'm working on Y, could I run a few thing by you', ppl are much more open to a constructive dialogue.

> What if they are doing it wrong and I notice?

Then offer to help. Even if this study was anything like statistically significant, all it would show is that you'd get less gratitude than if they asked for help. It doesn't look into outcomes other than gratitude.

So, unless you're helping because you want praise, this study is irrelevant to you.

Let people fail. This is an opportunity for growth.

Just having suppressed a giant rant myself, let me ask you: how you would deal with people that don't seem all that interested in personal growth?

I'd wager someone eager to improve their skills will often happily share their progress and code and be open for input. I don't think that's the kind of dev that triggered GP's rant :-)

That’s a tough situation. Let them fail and they should be put on a PIP. If an org fails to identify poor performers it’s difficult for me to trust their promotion criteria as well.

>>What if they are doing it wrong and I notice?

You still do nothing.

In these days of 'personal spaces' and talks of 'discomfort' and 'creepy behaviour'. Nothing is worth meddling with anything unless explicitly asked. Even then I would keep huge distance, even in emails and chat.

This is also called 'Consent'.

However, in non-silo non-enterprise situations, you're usually the guy who has to deal with the result without ever having given consent yourself...

I don't think I myself would be greatly bothered by "crap" if I didn't have to deal with it constantly.

That's easy to solve.

You assign a task to someone, then say:

You come back to me, as soon as you find it hard to move forward, ok?

They screw up

You should have come to me for help, like I advised you. Nevertheless, lets look at how you can solve your problem now

> You should have come to me for help, like I advised you. Nevertheless, lets look at how you can solve your problem now

So in the end you _still_ have to deal with the mess they made? And you further enable their behaviour by both making it your problem to solve and fixing it?

This approach only works if the other person is interested in improving - and if they were, they would ask for help in the first place.

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

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?

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.

and, did they employees know that they were monitored and what for?

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.

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.

I used to like to walk to the nearest pub for lunch and have a pint and couple of pinball games and mentally review the problem whilst playing.

This. Teams can become so much more effective when lack of experience with certain parts of the code is communicated.

It's a big step for a lot of people at first, because they are afraid of showing that they are actually stuck (“I'm afraid others will think I'm incompetent”).

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.

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.

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

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.

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.

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?

> could differ across industries

Not to mention countries and cultures.

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.

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

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.

You do have to find noncritical work to silo those who have proven themselves useless or actively harmful into, if you can't remedy their deficiencies or get rid of them.

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

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

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.

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.

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

I agree, randomly helping out in the first few days is perhaps acceptable but after that, they should be treated as any other employee.

so treat the new employee the same as the employees who have been in the company for a few years and have written a lot of the systems and have internalised the business domain/company setup/system architecture & troubleshooting?

unless a company is rewriting the same 10 input form over & over again, I don't think that will work out great for anyone.

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.

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.

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)

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

Why I recall one intern in a large intern in a very large company who blotted his copybook in a very very public way over 20 years ago.

That still has effects today as I was asked by an agent about a job at a company where he now has a senior role and I had to stifle a laugh and turn them down.

They could have done with some advice at the time.

TIL: "blot one's copybook": to spoil one's reputation by making a mistake, offending against social customs, etc.

By the way I definitely wouldn't hold it against an intern 20 years later, so I'm surprised that you do. An intern by definition is going to make mistakes, even huge ones.

Oh it was "that bad" trust me.

Hmmmm. It's hard for me to imagine a scenario that's so bad, but still the fault of the intern alone and not actually the company's fault for lacking proper controls, code review process, and backups and so on. i.e. an intern accidentally deletes the production database, or writes code so bad that it takes down critical software. Whoops. Pretty bad, but if it's a larger software company or larger IT team then they should've had processes against big mistakes.

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

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

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.

Sample size way too small to conclude anything meaningful.

Reply on news.ycombinator.com