Hacker News Reader

Comment by vitus | Hacker News Reader

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question".

Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an answer in 5 minutes. Sometimes, I didn't even know who the right person to ask was, but if I had just asked my tech lead, he would have been able to point me in the right direction.

Claiming that it reduces your overall time from several hours to < 5 minutes is maybe a bit exaggerated, since it also takes time to figure out what question you want to ask in the first place. But it's still worthwhile even if you end up investigating for 30 minutes instead of 3 hours.

View on HN

On the other hand, though, I really wish people would take at least ten minutes to do that digging through the code or reading through the documentation before asking.

One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general.

Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're getting self-sufficient.

Three, you'll have a lot more context for me, which will make it easier for me to give you the answer. "Hey, how come this function doesn't return what I expected" is a much harder question to answer than "This function says it returns a list of items a user has accessed in a given workspace, but it's returning an empty list; I've checked my local database and it has a good set of seed data I think, and from looking at the function there's nothing obviously filtering out users, so what's going on?"

At my first job, at a consulting company, they had a good rule, which was basically "show initiative when asking questions". What this boils down to is if you ask how to do X, you should first research and think about it, and then you can say "I think Y is how I do X, am I on the right track?"

A lot of the time, you'll answer your own question getting to Y. If not, it will save the person you're asking a bit of legwork, and show you are not trying to have them do your job for them and have respect for their time.

Or, even, "I see X Y Z is happening, that doesn't seem in line with the question, can we discuss it further ? "

Agreed, now that I'm the person getting these questions, it's hard to reconcile "it would have saved me a ton of time when I was new to this codebase" with "why can't you do even a basic amount of due diligence to even figure out what you're trying to do". (As I mentioned -- it's still important to figure out what the right question is!)

It's hard to find the right balance, and I agree with the author's framing of it as a spectrum, but I also agree that I at least (and most junior engineers, in my experience) leaned way too far on the side of being, um, self-motivated.

I certainly do notice myself getting frustrated by people asking questions when IMO they should know better, and I'm never sure whether I should be more lenient there or if I should tell them off for not putting in that tiny bit of effort.

It can go both ways. The most common one I've seen is definitely taking too long to ask about something. The other is asking too many trivial questions about things you can look up in minutes or ought to know given your job.

I think the problem is knowing when to ask is like many things a skill that gets better with experience. It isn't obvious especially to newer people. I also think if you're a senior you should be much more forgiving of juniors when it comes to this stuff. We were all there once.

I think asking too slowly tends to be caught more easily in things like standup before it snowballs. Asking too quickly tends to be habitual and seems to do more damage since it's harder to notice when managing projects, and often under the vague auspices of "pairing."

Reply on news.ycombinator.com