Topics covered in this post:

Answer your own questions ( Rubber Duck Debugging )
What happens if I try...
Long poorly framed questions
What was the answer again???
I don't know the error message
Not tried anything ( I came to you first )
Conclusion

Answer your own questions ( Rubber Duck Debugging )

Have you ever started talking to someone about a problem and at some point whilst you were talking you suddenly figure it out without the other person having to say a single word? You turned that person into a rubber duck.

In software engineering, rubber duck debugging is a method of debugging code, it is a reference from the book "The Pragmatic Programmer" in which a programmer carries a rubber duck and debug their code by forcing themselves the code line by line to the duck.

This is an actual thing, and it really works when you are stuck, but it is not a good thing to do to a senior developer at work or to anyone you are trying to get help from, it is actually very hard to get back to the level of concentration after distraction so this can really rub people off the wrong way.

Solution

Try to talk your problem out line by line, get a rubber duck if you must, if anything senior developers will find it super hilarious that you tried it first and will be more inclined to help you afterwards if you are still stuck.

What happens if I try...

If you find yourself asking lots of questions such as "What happens if I try...?" you might want to change that as that could also potentially get you more enemies than friends, that question most of the time can be avoided altogether.

Most times when you ask that question, the developer you are talking to would be thinking to themselves "so why don't you try that yourself and see!" when asked too many times you might get a not very nice response.

Solution

Satisfy your own curiosity by trying it out your self, this way you end up teaching yourself a point or two about how it works, if it is something you cannot test without an irreversible side-effect, then ask for a test environment to experiment with.

This is also a way of gaining independence as a newbie developer and it will be noticed by your peers "he/she figured it out even before I could tell them about it" look who is making friends! 😊 👏 👏 👏 👏

Long poorly framed questions

Avoid taking too long to explain the problem, this could be genuinely as a result of nerves kicking in or just frustration of being stuck at a problem for a long time and therefore you feel the need to vent it out a little.

I get that and it is ok to do that sometimes, but remember the other programmer is also working to a deadline and probably prefers a shorter version of the question, don't spend too long explaining how you have tried everything in the book.

Solution

Frame the question before you ask it, keep it short, mention only all that is required to re-produce the problem without too much explanation of why you think you are right and your computer is clearly against you that morning.

What was the answer again???

Try everything possible to keep asking the same question over different days, what was the answer again? is a question that will land you on the wrong side of your fellow developers, and this does not show initiative on your part.

Solution

When you get a solution to a problem, use that as an opportunity to learn that solution so it is easy to recall in the future, don't just copy and paste without using that opportunity to learn.

Create your own list of how you solved particular issues so when you need a refresh your memory you can go to your list and take it from there. This means you can also potentially help others solve that same problem! 🎉 🎉 🎉 🎉

I don't know the error message

Error message is the window to the heart of any problem, so when asking a problem expect that the senior developer will ask for error message, chance is that they have come across that same error and can identify it.

Saying you don't have it will result in you having to go back to find it and come back with your problem which now is taking longer than it would if you came prepared in the first place.

Solution

Read error messages, use them as clues to the problem's solution and if you are still stuck, take that error message with you when seeking a solution.

Not tried anything ( I came to you first )

Don't be too eager to show off your error messages, this is the wrong way to learn, remember ever time you get an error it is an opportunity to grow and learn something new, don't pass it on as someone else's problem to solve.

Solution

Take time to get familiar with the error message, read it, search for a solution in documentation, google, stackoverflow etc attempt to solve it first and then if you still need extra pair of eyes then go ahead and as for help.

Conclusion

There you go, we have gone through some example questions to avoid, now this is by no means an exhaustive list, but with these you can easily see if a question is going to make you friends or enemies at work.

Generally programmers really do want to help, in fact a good question is practically impossible to ignore, it gives a programmer a chance to geek out full time! 😂 so asking questions is not the problem, it is the quality and framing of the question that makes the difference some times.

Happy Coding...