3 ms·

As a tech lead I would rather see a team member ask me questions early than never. Nudging them in the right direction before they waste 3 days going down a pat

by Swizec 3y ago

As a tech lead I would rather see a team member ask me questions early than never. Nudging them in the right direction before they waste 3 days going down a path that’s never going to work is at least half my job. But it’s important that they’ve done enough research to formulate the question. A little struggle helps the learning stick.

arcbyte 3y ago
Agree. I think about 4 hours is a good rule of thumb for how long you should be stuck before getting help.
steveBK123 3y ago
My problem is I see this most frequently with debugging. It's like no one knows how to debug anymore. Read a runbook, google an error, try a few things.. no, just pester a senior. When I find myself responding to juniors/mids with the same list of rote, problem agnostic, runbook responses .. and it actually helps them, it's unnerving. It's like the socratic method of debugging without them actually learning anything from the experience.
freedomben 3y ago
I agree, but in practice now I've come to see that this is an extremely difficult point to discern. As the vast majority of findings flow in as a trickle, there often isn't a large enough delta to identify as a launching point for asking for help. For example, if one continues to search, they will keep finding breadcrumbs leading them to the solution. It is painful to me when someone spends 3 days looking for a solution to a problem that is very custom and unique to our system (so they're not gonna find the answer anywhere on the internet), and one I could solve in 5 minutes, but you don't know what you don't know, so as a new person learning it is almost never clear at what point it is ideal to ask for help. Compounding all of this is that many personalities don't like to be bothersome to other people, and that can cause them to hesitate to ask for help, which further sends them on the search between small deltas. It's a very hard problem.
- tomjakubowski 3y ago
  The sort of problem that is often best solved by hanging out around the water cooler, mixing and kvetching with random coworkers, ones you might not see at your regular meetings.
- esafak 3y ago
  You need to socialize the problem; to broadcast that you are trying to solve something. Some sort of internal discussion board could work. It serves the same purposes as the water cooler. If anyone can think of a way to make software better serve this end I'd love to hear.
  - mncharity 3y ago
    > think of a way An app was recently mentioned in hn comments, for "live blogging" as PIM - a texting-like personal record of your questions and findings as they go by - research notebook meets chat UI. With a trace like that, or even just a browser trace, an AI might, without interrupting, summarize "what's Joe working on" and perhaps "how's that going?", or even "Hey Bob, maybe come chat with Joe?". And it could be nice to have a PIM that helped you maintain distilled clarity of objectives and state of play. Less nice the vision of a micromanager mesmerized by the dashboarded real-time state of his team. A physics peer-instruction app, in support of "instructor puts up a question; everyone individually commits an answer; discussion with a neighbor; answer again", told students which neighbor to talk with, optimizing for fruitful discussions, knowing seating and the (mis)understandings implied by answers. LLMs open a lot of possibilities for the old dream of computer-supported cooperative work. When github was band new, I'd hopped it would grow far more social/meetup/hackathony than it ended up. Wander by, see who's around and what people were banging on; stop by the beginner tables and see if anyone was stuck or struggling; maybe join a push; maybe pair or group; interest profiles, matchmaking (eg round-robin pairing, or "oh! a category-theoretic type system in-the-style-of-a-conference-bar discussion!"). Like a team or small community discord with bots, but scaled. Perhaps AI can make something like that more tractable.
meindnoch 3y ago
Cool! I'll send them to you then :-)
evnc 3y ago
Yeah, it's a balance. I love being able to help, and I am generally in favor of asking questions early, but not ones of the form "hey so I ran this code and it errored. Help?" "... did you read the stack trace? Did you look at the code referenced by the stack trace?" This is where I've learned responding with "Sure! What have you tried so far?" is relevant.

by Swizec 3y ago

arcbyte 3y ago

Agree. I think about 4 hours is a good rule of thumb for how long you should be stuck before getting help.

steveBK123 3y ago

My problem is I see this most frequently with debugging. It's like no one knows how to debug anymore. Read a runbook, google an error, try a few things.. no, just pester a senior. When I find myself responding to juniors/mids with the same list of rote, problem agnostic, runbook responses .. and it actually helps them, it's unnerving. It's like the socratic method of debugging without them actually learning anything from the experience.

freedomben 3y ago

I agree, but in practice now I've come to see that this is an extremely difficult point to discern. As the vast majority of findings flow in as a trickle, there often isn't a large enough delta to identify as a launching point for asking for help. For example, if one continues to search, they will keep finding breadcrumbs leading them to the solution. It is painful to me when someone spends 3 days looking for a solution to a problem that is very custom and unique to our system (so they're not gonna find the answer anywhere on the internet), and one I could solve in 5 minutes, but you don't know what you don't know, so as a new person learning it is almost never clear at what point it is ideal to ask for help. Compounding all of this is that many personalities don't like to be bothersome to other people, and that can cause them to hesitate to ask for help, which further sends them on the search between small deltas. It's a very hard problem.

tomjakubowski 3y ago
The sort of problem that is often best solved by hanging out around the water cooler, mixing and kvetching with random coworkers, ones you might not see at your regular meetings.
esafak 3y ago
You need to socialize the problem; to broadcast that you are trying to solve something. Some sort of internal discussion board could work. It serves the same purposes as the water cooler. If anyone can think of a way to make software better serve this end I'd love to hear.
- mncharity 3y ago
  > think of a way An app was recently mentioned in hn comments, for "live blogging" as PIM - a texting-like personal record of your questions and findings as they go by - research notebook meets chat UI. With a trace like that, or even just a browser trace, an AI might, without interrupting, summarize "what's Joe working on" and perhaps "how's that going?", or even "Hey Bob, maybe come chat with Joe?". And it could be nice to have a PIM that helped you maintain distilled clarity of objectives and state of play. Less nice the vision of a micromanager mesmerized by the dashboarded real-time state of his team. A physics peer-instruction app, in support of "instructor puts up a question; everyone individually commits an answer; discussion with a neighbor; answer again", told students which neighbor to talk with, optimizing for fruitful discussions, knowing seating and the (mis)understandings implied by answers. LLMs open a lot of possibilities for the old dream of computer-supported cooperative work. When github was band new, I'd hopped it would grow far more social/meetup/hackathony than it ended up. Wander by, see who's around and what people were banging on; stop by the beginner tables and see if anyone was stuck or struggling; maybe join a push; maybe pair or group; interest profiles, matchmaking (eg round-robin pairing, or "oh! a category-theoretic type system in-the-style-of-a-conference-bar discussion!"). Like a team or small community discord with bots, but scaled. Perhaps AI can make something like that more tractable.

meindnoch 3y ago

Cool! I'll send them to you then :-)

evnc 3y ago

Yeah, it's a balance. I love being able to help, and I am generally in favor of asking questions early, but not ones of the form "hey so I ran this code and it errored. Help?" "... did you read the stack trace? Did you look at the code referenced by the stack trace?" This is where I've learned responding with "Sure! What have you tried so far?" is relevant.