[HN Gopher] When Should I Interrupt Someone?
___________________________________________________________________
When Should I Interrupt Someone?
Author : zwischenzug
Score : 20 points
Date : 2021-03-15 09:16 UTC (13 hours ago)
(HTM) web link (zwischenzugs.com)
(TXT) w3m dump (zwischenzugs.com)
| orobinson wrote:
| "When you seek advice, first write down everything you've tried."
|
| Remote working has made this super easy as often the way of
| reaching out to people is with a Slack message or equivalent. So
| many times over the past year I've answered my own question as I
| type out a lengthy Slack message explaining a problem to someone.
| afarrell wrote:
| I created 3 slack emojis to signal this more clearly:
|
| 1. I'm thinking harder about this thing but not blocked.
|
| 2. I'm still not blocked, but could really use a pair right now.
|
| 3. Actually stuck.
|
| They basically act like andon cords for my quality of
| understanding of a task.
| tresil wrote:
| This is interesting. We've arrived at a very similar set of
| guidelines on our team. One slight difference is that sometimes
| people want to reach out to a senior person not so much because
| they're "stuck" in the middle of something, but before they even
| start on some new feature or development story. They want help
| with design or help with even determining what approach to take.
| Similar to the author's suggestion to ask them what they've
| already tried, we ask for them to do their best to propose a
| solution, and then we go from there. That way they're still in
| the drivers seat, and we evaluate the pros and cons of their
| approach so they get meaningful feedback for improvement.
| TedDoesntTalk wrote:
| I read the headline and thought this was going to be about
| interrupting someone during conversation.
| hiddencache wrote:
| That's what I hoped it would be about...
| sideshowb wrote:
| I thought it would be about -
|
| ...sorry, should have let you finish. You were saying the same
| thing.
| bena wrote:
| Which would also be a helpful guide.
|
| Some people have a tendency to not so much converse as to
| pontificate. If you are seeking input from someone, you have to
| give them the chance to give that input.
|
| If you have an issue with a point someone made within their
| first two sentences, the rest of the speech doesn't matter, so
| it's almost rude to wait until they finish to tell them their
| original assumption was wrong. Or they go off on such a tangent
| that you both forget the original purpose of the conversation.
|
| Hypothetically, if someone is complaining that their back is
| sore from all the glass bottles they carry around to hammer
| nails with, waiting for them to get into the fine minutiae
| about the embroidery on their glass bottle bag is just wasted
| time. You need to ask the immediate question, "Why are you
| using glass bottles to hammer nails?"
| plank_time wrote:
| When I interrupt people, I make sure I have exhausted all avenues
| of finding the answer, and I tell them exactly what steps I
| tried. If they see that I've put in significant effort, then it
| usually assuages any issues with them being interrupted. In a
| similar way when people interrupt me, I like to see the same.
| mrgalaxy wrote:
| As the senior most developer on my team, I want you to interrupt
| me as soon as you need help. It is a far better use of everyone's
| time to get you on the correct track right away. I tell this to
| every developer on the team, and especially the junior
| developers. In a sense, since I helped designed and write many of
| the systems, I view it as my main job to assist other developers
| so they can do their job to the fullest extent.
| lumost wrote:
| TBH this is a double edge sword. It's easy to end up creating
| the illusion of value by helping many devs when they could have
| just tried N more things.
|
| As a curious counterpoint, try taking the opposite approach for
| a bit and only get involved when it is absolutely apparent that
| no one else can do the job/guide people through decisions. Have
| junior folks write down what they are about to do in a design,
| or what they've tried before to help build documentation,
| design, and debug muscle. You may find that people are more
| able to run the show than you give them credit for.
| mrgalaxy wrote:
| I feel like many in this thread misunderstand me. Our company
| follows pretty standard practices. Before anything is worked
| on, everyone has to write in pretty excruciating detail what
| is being done, from juniors all the way to our marketing
| department. Everyone works on the documentation including the
| juniors.
|
| 98% of the questions I get are not about the basics, they are
| very high-level problem solving questions coming from people
| that just need clarification or 2nd pair of eyes on
| something. I mean even I need that quite often and I am very
| grateful for the help.
| majkinetor wrote:
| Meh...
|
| IME, that way you are rising retards. One totally needs to try
| and experiment on its own before seeking advice. I wouldn't
| ever like a job like that. Its like baby sitting.
|
| Since you assisted and wrote many systems, its better to write
| good docs for it so juniors can self service.
| _Microft wrote:
| You two might only have different ideas of ,,needing help".
| It could easily mean that a team member ,,couldn't figure it
| out after trying X/Y/Z for N minutes".
| jpmoral wrote:
| Depends on how the team defines "as soon as you need help".
|
| Nothing in the grandparent post precludes writing good docs
| and allowing experimentation.
| mrgalaxy wrote:
| To be clear, I am not saying a company shouldn't maintain
| technical docs. In fact if I know something can be found in
| the docs, and I get a question about it, I am simply going to
| direct them to the docs.
|
| I also do not discourage a developer from trying something on
| their own if they feel inclined to do so. That, for me
| anyway, is most of the fun of programming: the problem
| solving.
|
| I think that asking a developer to "try it for an hour before
| asking" is just wasting another hour.
|
| There are many ways to solve a problem, I want to make sure
| my developers have the access to me that is necessary to
| develop the best solutions.
| bluefirebrand wrote:
| This approach works best if you do in fact course correct
| people and not just do the job for them.
|
| I've definitely seen junior devs get used to hand holding from
| senior devs, and learn nothing
| mrgalaxy wrote:
| Actually this is a great clarification yes. You want them to
| begin thinking about problems and understanding tools so they
| can eventually do tasks without asking for help.
| Gunax wrote:
| 'when should I ask for help' might be a better title.
|
| Each org I have seen is a bit different. Some projects just seem
| to be more geared towards gurus (aka, the software is wonky, no
| way anyone could know about that without asking).
___________________________________________________________________
(page generated 2021-03-15 23:01 UTC)