Why are Software Engineers so touchy about asking questions in the workplace? [closed]

Question

Background

For context, I am a junior engineer. These people below have experienced similar issues, or know of similar issues, that are comparable to what I have noticed.

A Senior Software Engineer that I met at my work had this to say about his previous place of employment:

You know where I used to work, they would swear at you for asking a question. I'm like Jeez whats wrong with asking a question? Here they are more friendly here with questions.

Another Software Engineer I met while volunteering had this to say about questions:

You know what is great about where I work. It's always ok to ask a question.

Finally, at the start of my experience, whenever I asked a question, I would not get an immediate answer even if they knew it. They would sometimes tell me to try to "find it out", even if I didn't necessarily possess the same intuition they did. Now I sometimes encounter times where my questions just don't get answered. Not even an "I don't know" or an "X guy would know". But rather "don't ask X for questions", or just no answer.

Question

What makes asking questions so controversial with Software Engineers in the workplace?

Answer 1

What makes asking questions so controversial with Software Engineers in the workplace?

I don't think this situation is unique to software engineering having worked in software engineering, product management, education and the food service industry, but indicative of a poor work culture in general. In my role as a Team Lead, it's my job to make my team feel comfortable asking questions, but at the same time realize that that answers don't always just fall from the sky and they need to put in their effort to answer their own questions too. While I regularly tell people "The dumb questions are the ones you don't ask," you can border on asking too many questions and not discovering enough on your own. It's a careful balance that you get better at doing over time.

I also see that the common mistake of promoting engineers based on their hard skills and not building up their soft skills. An engineer may be productive working in a team, but it does not mean they are capable mentoring others or leading a team. When a engineer that lacks leadership and mentoring skills, they may not tolerate questions from people and find working with inexperienced people frustrating. This is a failure in both the engineering manager (or lead) and the senior engineer part for not building up that skill set.

Then finally it might be the frequency that questions coming in or the medium that people use to ask questions. I find it easier to snooze or turn off slack OR completely work from home to get things done. I also recommend weeding out takers in the interview process as best you can. Part of my job in leadership is making sure my team has the right level of focus to get their job done. Sometimes that means questions or requests get redirected to me and I vet and prioritize them for my team.

Answer 2

As a Senior Software Engineer, I have to be judicious about how much I assistance I provide to junior/mid-level developers.

From a career perspective, entry/junior level developers are more dependent and will require more training. Mid-level and senior developers are expected to be more independent. There is actually an expectation, that as you grow through your career, that you become more independent in your day-to-day functioning and your outside learnings. This is often explicitly listed as a job requirement in higher level positions, usually along the lines of, “Candidate is expected to operate under a limited set of instructions.”

From another perspective, the senior staff may also be instructed by management not to help too much. I have actually gotten in trouble with management at a previous job for offering too much assistance to lower-level staff. It was tough to hear at the time, but at the end of the day, management was right.

• IT staff are paid higher salaries, and they are expected to deliver. If I offer too much assistance, it makes it more difficult for management to evaluate how much the other employee is producing on their own.
• Senior staff should not take up too much time offering assistance to lower-level staff, as it can take away time from the senior staff’s projects and their ability to meet their deadlines.
• Essentially, with the above two issues, the senior staff member should not be doing the lower-level staff’s jobs for them.
• In worst case, scenarios, I have been told directly by management to let the other person fail.

This may sound negative. At the same time, I am prone to offering plenty of assistance, though throughout my career I have learned to set limits.

Generally speaking, as other posters have suggested, you should do preliminary research before consulting with senior staff. For example, check the web for purely technical questions, and check your company’s internal documentation or reverse engineer for application questions. A judgment call should be made such that you are not spending too much time researching, if perhaps a quick question could resolve it. Find a balance between performing your own research and consulting senior staff.

Eventually, the more answers you can figure out on your own, the faster you will grow in your career.

Answer 3

First of all, I don't share the observations of you and your colleagues. I work with very helpful colleagues that are always interested in sharing their knowledge or help me becoming a greater developer.

Finally, at the start of my experience, whenever I asked a question, I would not get an immediate answer even if they knew it. They would sometimes tell me to try to "find it out", even if I didn't necessarily possess the same intuition they did.

I don't know what kind of question you are asking but there is two reasons I can see for pushing back on giving answers.

1.) The senior developer might not have the time or cannot afford being interrupted at this moment. If you call them on the phone, or go to their desk, it might interrupt their thought and throw them back for 30-60 minutes for each interruption, which is very costly for a simple question. This is very costly for a simple question that could be googled by you in the same time. You could mitigate that by using asynchronous communication (like an e-mail, that can be answered by the senior when she is already between to tasks), or ask them first whether they have time for you and offer to come back later if that's more convenient. Make sure to only interrupt when the trade of is worth it (you saving 1 day versus them losing 30 minutes).

2.) It might also be meant to be for your best. As a junior engineer it might seem convenient to get your information from a senior in your area, after all she knows all the answers and it only takes you 10 minutes get it from her. But this way you are not learning the necessary skills you need to grow in your career. Self-learning is a giant part of being a software developer, as technology is changing daily and even the knowledge banked by your senior colleagues is likely to be slightly out-dated already. If you show signs that you cannot simple information from the internet yourself, your senior would be perfectly right to tell you to find out for yourself. This might be harder to in the beginning, but being able to get knowledge from reading specifications, code or, yes, stack overflow is critical.

Typical questions I would expect someone to get from the internet or a book: - What is the method to do x in this public library - What does this mysql error message mean? - How do I resize images on a Mac - How can I undo a git commit?

For these kinds of questions, I'd suggest to try finding things for yourself for 1-2 hours, before asking questions, unless someone seems open for questions (like someone walking around idle). It also will help you more if you ask how your could help your self. "Hey, do you know a good reference for X" will be much more useful to you in the long run than "How do I do Y in X".

Only for questions that are not about public domain knowledge, and also not documented internally your senior might be the right first stop: - What is the method to do x in our undocumented internal library - Where does this error in our technology stack come from. - What tools are sanctioned by our IT do resize images? - What is our department's workflow to rollback changes?

As the proverb goes

Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime

Answer 4

What makes asking questions so controversial with Software Engineers in the workplace?

I think the "controversy" might be in the eye of the beholder.

While I have no doubt that there are some workplaces where developers refuse to answer any and all questions raised by their teammates, I'd wager that these places are really, really rare (and not a place anyone with options would choose to work at).

Instead, most places, I imagine, are fill with experienced developers who want the junior developers to succeed, but know that some of the most important skills which will enable success is the ability to reason about a problem, perform a certain amount of experimentation, and "dig-in" to get close to a solution.

In a firm with a good work environment, the senior developers will need carefully balance how much help to give and how much to expect the junior to figure it out themselves.

Answer 5

This is a big problem in workplaces and as @jcmack indicated, it's not unique to software engineering.

There are many reasons why questions might be dismissed or responded to with harsh judgment. You can see a microcosm of this in action by merely reading about the recurring "Why is stackoverflow so mean?" problem.

Even though stackoverflow.com is not work, much of the same dynamics apply at work. To a large extent the way people think about questions in technical domains is reflected in their online communities like stackoverflow:

• There is an expectation that someone asking a question needs to demonstrate that they've tried to answer their question in advance by either doing research or attempting some basic troubleshooting. People who don't do this are seen as "help vampires" and they're seen as a drag on productivity because they take time away from productive people they could have solved the problem on their own.

• Questions are expected to meet certain criteria for validity. Questions that have a yes or no answer aren't valid because finding that answer is usually trivial. Open ended questions are ALSO considered bad because answering them requires someone to take serious effort when that effort should be carried out by the asker. Questions that indicate a false assumption or misunderstanding are considered invalid because it would require too much effort to re-direct the understanding of the asker. These questions are dismissed with something along the lines of "not-enough-knowledge-to-ask-a-question". There's a narrow band of inquiry which is considered "just right".

These are very strange attitudes that people have about inquiry. Things are definitely more relaxed in academia, and many (myself included) have experienced culture-shock upon crossing-over from academia to workplaces. I suspect that the root of these attitudes in tech workplaces descend from the Protestant work ethic and has been passed on for generations and even across cultural boundaries. There exists a revulsion against providing assistance of the "unworthy" which people sometimes label as "spoon-feeding".

Beyond what you see in reflected in the stackoverflow microcosm, there are other dynamics which contribute to attitudes about questions in the real working world, specifically I am thinking about "status" or "hierarchy". In any organization, regardless of titles and regardless of what people may say about openness, you have boundaries between different "tribes" that limit the types of interactions that are considered acceptable.

Asking the "wrong" question, even an innocuous one, to the wrong person in the wrong "tribe" can be perceived as a threat for a variety of reasons ranging from subversion of communication hierarchy (eg, getting help from IT without a ticket) to more serious concerns about job security (eg, what happens if by "giving" too much help to juniors, seniors end up on the next chopping block because they're no longer needed?).

All of these obstacles, however, can be worked around or bent by people who are willing to cultivate personal relationships with others in the organization. It doesn't have to be "personal" as in friendship, it can be as simple as providing non-transactional favors to others in such a way that they remember you when you need help.

Anything that enhances empathy between two people will make them more likely to react with consideration and less judgement to questions. If the person you're asking trusts you implicitly, they're going to not only try to answer your question but also correct any misconceptions they're detecting on your side. You still will need to be considerate in what you're asking, but at least if you get it wrong, the person answering you will be more likely to point you in the right direction rather than metaphorically "downvoting" you.

Developing that kind of trust, of course, takes time and it's not always possible with every person you interact with, but it still helps a lot to have a network of people that can talk to each other without being blindly reactive.