Hacker News Reader

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.

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.

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.

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.

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.

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.

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

Beware the opposite trap: once you get a reputation for being a team player willing to do work that nobody else will, people will appreciate you but also throw more of this kind of work your way. After a few years you may wonder why you are not being promoted and find out that your reputation is now of someone who cannot handle a large project. Fighting my way out of this particular pit right now and learning how to say no a lot more often.

The killer concept here is to ask. Just ask your boss, people are requesting help on X, should I help them, or stay focused on your goal? People get so mad that their bosses can't read their minds and tell them the answers to questions they were never asked.

It is very rare for a company to not pivot in some way over the course of the year. Those interruptions as often as not are not only taking you away from your tasks, they are also your notice that your tasks need to change.

Note that I used the word "tasks" not "goals"! They are NOT the same and I suspect you have mixed them up. Tasks are what you do to meet your goals, and can be interrupted. Goals are where you want to be, not the tasks you do to accomplish them. Goals can be accomplished in many different ways, and often take years.

I have a goal to help people out. I have another goal to see if we can port some of our software to a cheaper/slower CPU. The second goal might or might not be worth doing this year - CPU prices are coming down (as always), and there is a cost to inventory of the slower parts so I need to always keep my ear open to the possibility I should give up on the second goal because it no longer makes sense. However helping out other people in my company is generally good, so it is the more important goal in general even if the cheaper CPU might - if it works out - be what it takes to stay ahead of competition.

I have a co-worker who does this, and everyone likes him, especially the boss, since he will jump on anything and get it done. He also seems to work really long hours and weekends, even though he has a family. He also does not seem to want to negotiate for a raise. I've chosen to not be likey coworker and so far I've been promoted, gotten 10 and 15 percent raises, etc. I do tend to rub coworkers and leadership the wrong way sometimes, but that's a trade-off I am fine with. I would rather be happy with my work hours and well paid than well liked.

There's a Middle Way.

- drop what you are doing and focus on the person. In a face-to-face situation, body language matters.

- figure out if it's something you can do quickly. Because you've already lost your focus on whatever you were doing, it's efficient to just go ahead and knock out small tasks.

- if you can't do it quickly, either because it's a lot of work or it takes time to explain what the problem is, you must negotiate and schedule the task for later, or have a meeting. Interpersonal skills are important: be sure the person goes away feeling like you care as much about their problem as they do.

- follow up with your scheduling.

Yes, frequent interruptions are bad for focus. Part of becoming the sort of person people feel comfortable going to is to help people know when it's OK to interrupt you and when they should wait for another time, or communicate in a way that is less disruptive. There will always be that sort of person who doesn't "get" it, and will interrupt you when they want to.

I would say help as advisor, but let the asking party do the "legwork", i.e. all the obvious stuff.

Just be careful not to be the guy who isn't helpful because of all the work you have to do before you can prove you are worthy to ask a question.

Great point. Yes, over the years I have come to hate the question that's awkwardly worded, or fails to provide even the most basic information needed, I've made peace with the fact that people are, well, people.

I don't really miss the days when asking a question "the wrong way" on a forum would risk an avalanche of insults.

I feel like there is a middle ground. At a previous job, a common compliment during my quarterly review was that people thought I was very helpful and a joy to have around the office.

I am the type of person who is helpful to a fault though, and I sometimes end up neglecting myself and my responsibilities in order to help others and make sure they are happy. Later on in that job this tendency to always help others lead to burnout as I tried taking on too many responsibilities at once and spread myself too thin.

Nowadays I still try to be as helpful as possible, but I make sure to not spread myself too thin and take into account my own responsibilities and mental health when deciding to help someone. Even then the answer wont always be a solid no, but sometimes just asking if the issue can wait until I'm at a point in my current work where I can stop and help out.

To some extent, you just need to look at the hard data: promotions and raises. See who's getting them. Whatever they're doing is what's actually rewarded.

It sounds cynical but I learned too late that a company's success is only incidental to your own success as someone who works there. If you think this is too negative, I'll just say I've seen a lot of "executives" run companies into the ground, then get great, high-paying jobs at acquirers, because they managed the politics well. It sucks but it's life.

Most tech management, especially young founders of VC-backed startups (vs. larger companies or owner-operated companies where the owners have a lot of skin in the game) is frankly pretty bad. It's just not celebrated or taken seriously the way it is in other industries, or fields (e.g. the military). I'm not saying this pessimistically, quite the opposite--I've seen a lot of bad management and I think there's better out there, but it does seem to be vanishingly rare.

It sounds like the boss should have publicized a primary goal of helping others and prioritized that over whatever you were assigned to do, if that matches the primary metric of those reviews.

Alternatively, the goals should be set with the understanding that some portion of your time will be allocated to helping others.

Work is hell. And hell is other people. Work is people. People are hell.

You can always work for Amazon Mechanical Turk.

:) Wanted to say this comment made me smile. You are not alone. Sending you good vibes

Hell is other peoples code

Hell is the code I used to write.

I don't think this means you shouldn't say no. It just means that you need to understand how to decide what to say no to. If your boss is the one who decides your performance, and they would rather you dropped everything to help others than do what you're "supposed" to be doing, then you need to say no to what you're "supposed" to be doing.

There is a bigger picture version of "saying no" in play here as well, though: is a company where your boss doesn't even seem to care about what you're "supposed" to be doing one that you want to work at? Will it make the best use of your talents?

This is why we end up working on our assigned "tasks" outside of work hours. It's one reason I like work from home, less work place distraction.

I love solving problems for other people! If you know how to help, they are really happy, which will make you happy too. And if you don't know how to help, it's somebody else's problem!

This is spot on with my experiences as well. I've never told any coworker that I didn't have time or wouldn't try. Same exact experiences with management being very happy.