4 ms·

The real trick is balancing the two. Help enough to build that reputation for being a team player. When you can't fully help, don't just say no, give them some

The real trick is balancing the two. Help enough to build that reputation for being a team player. When you can't fully help, don't just say no, give them some starting pointers and offer to review, or assist more if they get stuck, so even then you are still being supportive. Help people to help themselves. Don't just do something for them, guide them in how to do it themselves so next time they don't even have to disturb you. Listen out for opportunities to use your skills to help people when they don't even realise they need help. I've lost count of the number off little scripts, tools or reports that I've knocked out in a couple of hours just because someone absent mindly moaned about something they found annoying. These things build your reputation far more than just plain helping, and if you're observant they are often simple and quick to do. But also, make time to progress your big goals too, which does mean you have to say no sometimes. Get help in return from those you have helped to move your goals forward faster than you can on your own.

kodah 6y ago
Generally when I engage with people I'm looking for opportunities to teach them in a way that they won't need me anymore. More simply, I treat "help" like issue triage. a. If the help is production impacting or blocking an issue that is due soon then they'll get more direct feedback but I'll continue on with (b) as well. b. Send the person in the direction of resources that aid self-learning. Habitual help seekers Some people are habitual in their search for help. I don't run into this as much as I used to, but when I figure out that someone is placing me much higher up on the help tier than my time allows me to be I will generally start continually referring them to (b). If things are bad enough then I'll generally talk to their mentor about refining their learning process. I usually find this where folks haven't "learned how to learn" yet; although software engineers do have a good reputation for learning things outside their domains, there's no shortage of folks who just know how to string code together.
- bluGill 6y ago
  If the question should be in a document, then I respond by opening the documentation and checking to be sure the documentation is right, and then fixing it as needed. That done I tell them to read the documentation and let me know if anything is hard to understand so I can fix it. When writing it is very easy to skip steps that are obvious. So when "asks too many questions about the obvious" can figure it out from the documentation I know the documentation is finally good enough for everybody - including the person who doesn't ask enough questions.
  - kodah 6y ago
    That's an interesting approach. Generally speaking, my organization doesn't maintain large document repositories because they go stale quickly and our products are too vast to document in such a way. For some context on my reply: - We maintain one design document per project. This document references everything from the application specifications to the automation that puts it in production. - Most documentation is written in line with code. Finding documentation is about as complicated as finding the right repository. This is also why peer review (in our org) isn't limited by level. Ideally we'd get feedback across the experience spectrum to make sure not only code but comments make sense to everyone.
    - bluGill 6y ago
      That is why step one is review the documentation. If documentation isn't reviewed regularly utility is useless. By using questions as opportunity to review it I can keep it useful.
- bitwise-and 6y ago
  This comment resonates with me as I'm currently the one habitually asking for help! Coming to the realization and accepting the issue has been tough but I'm actively working on it these days.
npsimons 6y ago
> The real trick is balancing the two. The way I've found to do this is just do stuff, then have people think it's awesome, then teach them about it. At least that's been my experience, but then I've been a computer nerd so long it's basically become my path to a niche sort of mastery.

kodah 6y ago

Generally when I engage with people I'm looking for opportunities to teach them in a way that they won't need me anymore. More simply, I treat "help" like issue triage. a. If the help is production impacting or blocking an issue that is due soon then they'll get more direct feedback but I'll continue on with (b) as well. b. Send the person in the direction of resources that aid self-learning. Habitual help seekers Some people are habitual in their search for help. I don't run into this as much as I used to, but when I figure out that someone is placing me much higher up on the help tier than my time allows me to be I will generally start continually referring them to (b). If things are bad enough then I'll generally talk to their mentor about refining their learning process. I usually find this where folks haven't "learned how to learn" yet; although software engineers do have a good reputation for learning things outside their domains, there's no shortage of folks who just know how to string code together.

bluGill 6y ago
If the question should be in a document, then I respond by opening the documentation and checking to be sure the documentation is right, and then fixing it as needed. That done I tell them to read the documentation and let me know if anything is hard to understand so I can fix it. When writing it is very easy to skip steps that are obvious. So when "asks too many questions about the obvious" can figure it out from the documentation I know the documentation is finally good enough for everybody - including the person who doesn't ask enough questions.
- kodah 6y ago
  That's an interesting approach. Generally speaking, my organization doesn't maintain large document repositories because they go stale quickly and our products are too vast to document in such a way. For some context on my reply: - We maintain one design document per project. This document references everything from the application specifications to the automation that puts it in production. - Most documentation is written in line with code. Finding documentation is about as complicated as finding the right repository. This is also why peer review (in our org) isn't limited by level. Ideally we'd get feedback across the experience spectrum to make sure not only code but comments make sense to everyone.
  - bluGill 6y ago
    That is why step one is review the documentation. If documentation isn't reviewed regularly utility is useless. By using questions as opportunity to review it I can keep it useful.
bitwise-and 6y ago
This comment resonates with me as I'm currently the one habitually asking for help! Coming to the realization and accepting the issue has been tough but I'm actively working on it these days.

npsimons 6y ago

> The real trick is balancing the two. The way I've found to do this is just do stuff, then have people think it's awesome, then teach them about it. At least that's been my experience, but then I've been a computer nerd so long it's basically become my path to a niche sort of mastery.