[vncecartersknee]

Even as someone thats only just above a junior engineer, I feel like I've been made to feel stupid or that I was wasting other peoples time or such for "just asking questions" so many times. I'm extremely reluctant to do so tbh. There have of course been people who encouraged and welcomed questions (for whom I'm extremely grateful) but it's the negative experiences that stand out.

It's really been a major contributor to my loss of interest and passion for this industry over the last few years I think.

[mypastself]

Not to discount your experience, and it’s likely this doesn’t apply to you at all, but I don’t think welcoming all types of questions should be expected in this type of environment.

There is usually a baseline level of knowledge and skill expected even from a fresh coding bootcamp grad. If they’re not familiar with certain fundamental concepts, answering some of their questions can be frustrating for more senior colleagues.

Business domain knowledge or company-specific tooling is a different thing, but even there, some people tend to avoid note-taking (or looking up documentation), which can result in them repeatedly asking the exact same questions.

Of course, even in those cases, some degree of tact and patience on part of the seniors should be expected, but as harsh as that sounds, there is such a thing as a stupid question.

[Cthulhu_]

It depends on the question and the onboarding of the company.

I think the onboarding should make sure there's a list of required reading - books, articles, etc - that the current employees know about, things that influenced how they made the application, what best practices they adopted, etc.

As the person asking the question, always check first if you can google it - the question has to be specific to the application and its authors, not e.g. programming or framework specific questions.

That said, the people answering the questions should make sure to "teach a man to fish", by both answering the question and linking to the relevant resources.

That said, linking to resources and the like is nice, but I also think a lot of people can't be bothered to read - I may be one of those. I will quickly scan something to solve my current problem, but hardly ever sit down to study the materials. One reason is just how quickly technology changes, so it's not worth investing in one technology unless you're actively working with it Right Now. I stopped keeping up with things like Angular, Java and Swift / iOS because I just don't work with those anymore.

[skinkestek]

> There is usually a baseline level of knowledge and skill expected even from a fresh coding bootcamp grad. If they’re not familiar with certain fundamental concepts, answering some of their questions can be frustrating for more senior colleagues.

Many schools seems to take pride in not teaching you how it is really done.

Banning IDEs is a classic.

A friend of mine got some remarks after I'd helped him: I'd introduced him to the BlockedQueue in Java and he wasn't supposed to know about that.

> Business domain knowledge or company-specific tooling is a different thing, but even there, some people tend to avoid note-taking (or looking up documentation), which can result in them repeatedly asking the exact same questions.

My current client actually praises me for just being honest and saying that the existing documentation isn't good enough.

YMMW but many times the training you get for the business specific part you get is awful or non existent and the documentation consist of whatever the previous person (who invented the tool/procedure/whatever) needed to remember.

[watwut]

> Banning IDEs is a classic

I never heard of that.

[TeMPOraL]

I can imagine reasoning behind that, at least today.

Last year, I've been tutoring a teenager who wanted to take CS on his maturity exam[0]. The exam has a theoretical (algorithms, knowledge) and practical (programming, data science, databases) parts; for the latter, you're expected to write some code in one of several approved languages, using one of several sets of approved tooling (which includes FOSS tooling).

My student wanted to use C++, and thus had a choice between Visual C++, DevC++ and CodeBlocks. It's quite obvious that one of these three is entirely not like the others. Between advanced IntelliSense, errors being flagged as you type, limited on-the-fly static analysis, and semantic suggestions[1], you don't have to know as much about C++ to succeed - the IDE will let you click your way into a working program.

All of these are very useful features when you already mostly know what you're doing. But if you're being tested for your knowledge? That defeats the assumptions of the exam, and of the educational framework behind it. Good education needs to walk a fine line of making sure the tooling augments, not replaces your understanding - so I can understand if some universities choose to skip IDEs initially, letting the students understand the problems their tools are solving for them.

--

[0] - aka. "matura", https://en.wikipedia.org/wiki/Matura#In_Poland. CS is one of the optional topics you can take, and since our universities don't do admission exams, your score on STEM topics on matura is important if you want to continue formal education in technical subjects.

[1] - Green, squiggly lines, programmer equivalent to grammar checks from Word :).

[mypastself]

I was hesitant to include the documentation part of my comment for the exact reasons you mention. In fact, documentation often is just somebody’s notes.

[crispyambulance]

> I don’t think welcoming all types of questions should be expected in this type of environment.

That's the "work-should-be-like-stackoverflow" attitude that many folks have. It's toxic.

What may sound like "a stupid question" might be a signal that the asker just needs some direction to get oriented. Or in the case with a bootcamp grad they might be missing whole areas of knowledge that others take for granted. You may argue that they shouldn't be there, but then the blame has to go to whoever did the hiring. It's not like bootcamp grads have been certified by a board to be programmers.

Part of being a senior/expert is being able to communicate with, onboard and assess juniors and new members. That always means MORE than just trying to exactly answer their specific questions. It means probing behind the question and trying to understand where they are coming from and what they need rather than simply what they're asking.

If you can't do that, and you just expect folks to "hit the ground running", you're not really a senior, you're a cog that needs other cogs to mesh with.

[mypastself]

I think you’re arguing against a far more extreme version of the comments than the ones I actually wrote, but I will address one point. The claim that whoever hired the person is solely responsible for their performance takes away the person’s agency to an unfair extent.

[robaato]

Well there are questions and questions, and also many ways of and times of asking them.

For example, and oldie but goodie is: http://www.catb.org/~esr/faqs/smart-questions.html

That might be overkill for internal review situations, but it is worth reading and bearing in mind.

Context is all. Sometimes it is the problem of the person you asked. Sometimes it is just the wrong time. Sometimes they are under pressure or just feeling a bit grumpy and snap at you. Sometimes there really is a "stoopid question"! Sometimes you need to try asking the rubber duck first (https://en.wikipedia.org/wiki/Rubber_duck_debugging)!

Keep your chin up and don't take it personally!

[munchbunny]

> Even as someone thats only just above a junior engineer, I feel like I've been made to feel stupid or that I was wasting other peoples time or such for "just asking questions" so many times.

Assuming you’re not a help vampire (I’ve worked with junior engineers like that, and it’s frustrating because they eat up time unnecessarily), then to the extent that you can, I would recommend finding a new team that doesn’t do that. It’s toxic to your growth and career development. Junior engineers might be junior, but “junior” is not the same as “incompetent”, and teams that don’t appreciate the difference are probably not good places to spend your early career.

[mattm]

Obviously, there's a line. If you're asking questions about every line on the code review, yes, it's going to make others hold a low opinion of you.

I like the rule of 3. Review the code but make notes to yourself first about things you want to ask about. Then pick the top 3 most important ones and ask those on the code review. For the others, try to figure them out on your own or ask someone privately if you can't figure it out.

[dkdbejwi383]

I guess one thing to remember is that they aren't necessarily lashing out at you personally, but it's their own insecurity which feels challenged by being asked a question. They're probably feeling the effects of impostor syndrome just as much as you are.

[Milner08]

That's a shame, my personal perspective is so long as the question is thoughtful its fine. I sometimes get people commenting "whats this" on a random line and I haven't got time for that (unless its blatantly obvious what they mean), but if you were to ask "Why are you using X, I'm not sure I understand" I would be happy to answer it and walk you through it, you never know maybe we could both learn something.

People are always busy but as a senior engineer I see teaching/helping junior engineers as a big part of the Job and so long as they are willing to put in some effort and think about it I am happy to give up some time to help.