Hacker News Reader

Hate to bang the same drum over and over, however this very much sounds like a culture problem, based on

> if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)

Sounds like the company lacks good culture, process and guidelines on expected patterns of communication and behavior. There should be an onboarding buddy when things are implemented well.

Its not your fault, at all. Its the company. Its not inherent to remote work though

If your team penalizes you for "asking questions and looking like an idiot" then the team culture is poor.

Nobody knows everything. Everyone makes mistakes. The team should help those people but they need to ask.

Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job.

Because we try to think as a team, we do better and have less interpersonal clashes. I still complain about things each dev does, that's natural, but our team does pretty well together.

> Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job.

That's easier to do when you're more or less on "equal footing", but if you're a junior, it can take months to years to develop knowledge that seniors don't (depending on several factors). That's the problem, it takes much longer to reach a point where you have knowledge that is equivalent to that of seniors if the culture doesn't lend itself to frequent and high-quality communication and you have to learn about internal tools, processes, code bases and such largely solo. If you share a physical space with seniors you'll at least have some common downtime like a coffee or water break to "bother" them and it can save minutes to hours of tedium each time.

So either you end up being "that guy always asking stupid questions in the chat and interrupting my work" or you spend a lot of time spinning your wheels pointlessly for months/years on end. The first approach leads to unhelpful and delayed responses and the latter makes you so inefficient that you favor lower quality work so that you can actually deliver something.

This is such an important point I don’t think it can be overstated. Psychological safety is one of the key things to have a well-functioning culture and it’s one of those cultural things that I’ve tried desperately change in past positions. It’s hard, and in one place, almost impossible save for eliminating a few key people who hold onto that mindset and clean house a little bit.

There is no growth, no team cohesion in an environment where you’re berated for asking seemingly stupid or dumb questions. But I think people become numb and indoctrinated to it because “well, I had to endure this when I was learning” is such a demoralizing and abusive stance and nobody wants to change.

Things work so much better when everyone has a chance to pitch in, even if some ideas are dumb, just having the option is miles ahead of whatever bullshit people can justify from the “old way”.

Part of the process to change I’ve found is just leading by example. I’ll intentionally ask stupid questions that I know raise the ire of my similarly-leveled coworkers just to make the point to the more junior people that “hey, this staff-level guy is asking this, I might be able to too”. Junior people will gradually start to get the picture and ignore the rantings and ravings and toxicity of the debbie-downwers and the sticks-in-the-mud.

Hard disagree with random questions. If it's easy to ask a random question you're just going to keep asking random questions. How about you write down that question and try to formulate the answer or a strategy for finding the answer?

Here is a workflow I made all people I mentor go through: 1) what is the problem? 2) why is this a problem? 3) what are you actually seeing? 4) what have you tried to solve it? What are the results?

"Random questions" doesn't mean questions without any thought put into them. It just means anything helpful from workflow or environment related questions to code style or processes that are not documented or easy to find. vs. wasting time trying to find things that don't exist or reinventing the wheel, which is more tempting to do when you can't see what your coworkers are doing and don't want to risk offending people who have no interest in passing on knowledge, like a sibling of your comment.

Allowing a noob to spin their wheels for too long isn't just wasteful, it sets the exact wrong tone. The goal is not to "figure everything out for yourself". It's to GET THINGS DONE.

Well said. I am currently working my way through an unfamiliar codebase and even as a mid-career developer, I find it intimidating and inconvenient to continually ask for help over slack for "basic questions". People say the answer is to go deep and gain expertise, but in my experience you need to reach a certain escape velocity with the codebase before that kind of spelunking becomes valuable learning experiences and not just a confusing and messy waste of time. You need either:

* Documentation that is up to date and answers not just technical details but the "why" behind the architecture. Something that shows you where to focus and where the frontier is.

* Defined, limited scope (at first). Scoping yourself to the entire codebase is a good way to become an expert in nothing. You need a foothold where you can gain expertise and give yourself a jumping off point to adjacent areas.

The latter is easier to accomplish than convincing everyone to write pages of docs that don't exist.

As the person you kept interrupting and following to the coffee pot, I much prefer this new way of working.

To be clear, labelled as an 'IC' I have zero interest in training you. You will job hop at the first opportunity, and never lift a finger to help me in the future.

With that attitude yes I'm not surprised that people would be tempted to jump ship.