6 ms·

This article talks about learned helplessness in a learning context. I talked about it in a work context, and the two could be linked. I think social media is t

• 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.
• steveBK123 3y ago
  Yes, and I think some of the neediest juniors (or seniors who behave like juniors) have now substituted in ChatGPT for some of their nagging. The ones I see doing this most heavily are not really developing themselves and improving in any meaningful way. At least a stack overflow thread will be filled with alternative solutions, arguments, counterpoints and caveats. ChatGPT leaves the questioner with the illusion that they have received the 1 good answer.
• astura 3y ago
  This just has not been my experience at all. I've never had a problem with a junior asking too many questions. Never. I have, however, had issues with them not asking enough questions.
  • kdmccormick 3y ago
    I have had both problems. As it turns out, unsurprisingly, it varies from person to person. It can also vary within a single person. They might, for example, ask questions too quickly when stuck on a technical question that could be solved by reading docs, but ask questions too slowly when stuck on an ambiguous product requiment that can only be personally answered by the PM or UX person.
  • spenczar5 3y ago
    Right. I never got upset with a question. The only issue is getting the same question multiple times. Not necessarily the same question verbatim, by the way. When I answer a question, I am trying to “teach to fish,” and so there is some system that I am explaining. My hope is that the asker will show curiosity - ask follow-up questions - and then be able to generalize. “I learned there was a lambda for sending emails, in the sysops repo. Maybe there is a lambda for sending slack messages in there too?” Software systems are imperfect so the generalizations might break. In this case I want another question quickly, like “I couldn’t find a slack message sender like the email one. Does one exist?”
  • rincebrain 3y ago
    Asking questions quickly is optimal for resolving the immediate problem, but not necessarily for understanding the components involved in the answer, or the time of the person being asked. Even if you write off the latter as ~free, the former is a significant benefit to someone familiarizing themselves with a new environment, and even someone walking the junior person through the process of reasoning through how to get there probably won't cover the same benefits as they might have experienced doing it themselves because they likely don't think exactly the same way. Of course, it's an immediate versus long term tradeoff too, and a personal tradeoff for when to ask, and with how many people tend to just refuse to ask questions because they've been trained to think this makes them look bad, it probably makes sense to aggressively incentivize asking by default, but there are benefits to spending time on a problem yourself if you have enough tools to bootstrap your way into more understanding, and I have met enough people who never understood things more than just how to lookup the answer from someone knowledgable to think this isn't something to also be concerned about.
• spencerchubb 3y ago
  As a junior dev, sometimes I've been blocked for hours because I want to show that I can solve problems independently. But I've definitely had cases where I should've asked questions early. A question that takes 1 minute to answer could have saved hours. For instance, I was stuck on figuring out how to send an email through AWS. Turns out we have a lambda function that handles all the authentication and security things that are specific to our company. Once I asked my coworker and found out about this function, it was trivial.
  • ZephyrBlu 3y ago
    The distinction between trying to solve a problem yourself vs ask for help is: are you figuring out a new problem, or figuring out the system? If you're trying to figure out the system, you should probably ask for help ASAP and build up some knowledge. Over time you'll need to ask questions about the system less frequently. If you're trying to figure out a new problem related to your work, slogging away at it for a while is more ok because it's value-add and a good learning experience. The lines are a bit blurry, but that's how I tend to think about this.
    • smeej 3y ago
      I had a manager when I was a new hire who had no concept of this difference at all, and it led to his firing me in my 4th week because I "should have been coming in with more knowledge." He actually told me I should have just come in and started doing things whatever way seemed best to me, like he did, when he was the first employee in the company in the role. Never mind that it was a compliance-heavy role in risk analysis and I was the 5th person on a 5-person team. Sure, I knew plenty of ways to solve the problems. What I didn't know were what systems they had (or, in most cases, didn't have) in place to document investigations, which absolutely must be done. I know plenty about what I'm doing. What I need to know is how you want it recorded. And in fact he had reinvented the entire documentation system during my 2nd week, on a whim. Firing me that fast was the best gift that company could have given me, because things would not have improved between us.
  • eminence32 3y ago
• deleted 3y ago
  [deleted]
• shadowgovt 3y ago
  Flipping the script a bit: As a senior developer, avoid cultivating learned helplessness. You can push back on this in a couple ways: 1) Instead of answering questions, give a nudge to where the solution is documented ("Hey I'm swamped, but I'd recommend checking X for more info. If you haven't read through X yet, that's a good resource to skim"). Keep tabs on how much your junior team members are expected to know, nudge them harder if they aren't taking the time to ingest the gestalt of what's there (it feels like a waste of time to do so sometimes... Reading isn't getting code written. But knowing what's already there saves work in the long run). 2) When something isn't documented... review the docs a junior team member writes, don't write them yourself. This both encourages them to have ownership over the system and will probably generate better docs in the long run (everyone has a notion of what docs should look like, but communication is two-way: seeing what someone writes down clues you into what you missed is necessary to record. Can't tell you how many docs I've seen for cloud systems, for example, that assume the user is logged in with proper credentials when that step alone usually requires handshaking across three services and maybe an IT team). 3) Prefer mistakes to silence. Don't bash a team member for making a correctible mistake, even in production; use it as a learning opportunity both for them and for you (if that mistake was possible, you're missing a guardrail). Actively communicate to junior members that wrong code that exists is preferable to no code; wrong code can be talked about, no code is work yet to be done. And be aware that for a lot of junior devs, the reaction to making a visible error is like touching a hot stove; cultivate a soup-to-nuts environment that minimizes that hot-stove reflex.
  • tstrimple 3y ago
    I agree with all of this with one minor quibble. I'd never tell someone I'm in a position to mentor / coach / lead like this that I'm swamped. It's probably true, but that's my problem not theirs. I don't want them to avoiding talking to me because they think I'm too busy. I know that was in an example statement and not necessarily something you're endorsing, but I thought the point worth bringing up.
  • spenczar5 3y ago
    This is just all excellent. There are a lot of strange attitudes elsewhere in this comment section, ones that I don’t recognize from good senior engineers. Good ones realize that a lot of their job is improving the whole team. If junior engineers are constantly asking trivial questions, maybe they need to be taught to learn!