Asking as a Training

Photo by Ivan Gromov on Unsplash

Asking as a Training

Clear technical communication

Feb 18, 2023ยท

5 min read


People want to help you, especially if you are a beginner. But most times it feels as if no one gives two f*c*s about us.

Guess what? They shouldn't, no one owes you anything.

But the world is excellent if you take the time to go out, interact, and stop believing what you see in the news about the world.

Engineering can't exist without communication because most of our work is done in teams. We encounter a lot of bottlenecks in software development, and our ability to clearly articulate these questions is usually decisive in getting that product to completion.

Questioning as a Service

It's high time we create an AI service that helps tech people reformat their questions clearly and concisely.

Take a look at some questions I selected from online communities I'm part of.
While they are not bad, I don't think they are efficient. People have a lot to do, so while questions to solve business or technical issues, it will do you a lot of good to be effective.

Question 1

"Hi @here, I need help on how to iterate through an array of objects in JavaScript and display each object at a time so that when I click on the current object the next object will show making the one I clicked disappears on and on like that. But only one should show on the screen at a time."

Question 2

"Please what can actually be the cause of an error with argocd that takes a long while to sync an application"

These questions are not straight to the point, fuzzy at first sight, and show a deep sense of entitlement.

  • Conciseness can be hard to come by. Senior colleagues struggle to communicate problems. As developers, we are most guilty of feeling that people should be able to understand us, but it is not always as such, and we should be aware of this.

  • I would choose a clearly outlined format of gibberish over valuable clumped-up information if I didn't know the message each passed across. The pleasantness of your question matters a lot.

  • We were/are (once) guilty of this. "I'm just getting started in tech so everyone is dying to mentor me". No Jude, no one is dying to mentor you, they are facing their respective careers, and although they would love to see you succeed, you have to show that you warrant their time. Show your action and dedication to solving the issue you are presenting. If you can't show a bit more commitment to killing your bug, why should they?

Reasons to edit

There are numerous times I've searched stack overflow for someone else's bug. Before you press send and take the easy way out, ask yourself if your question could use a bit more research.

Just imagine trying to help someone who doesn't know what their problems are ๐Ÿคทโ€โ™‚๏ธ.

There are three reasons I recommend asking questions differently:


I'm still learning that to be the engineer I want to be, I have to start doing things myself. The theory of use and disuse, if I use my resilience to find a solution to an issue, I become better. If I get to do things the easy way, I hamper my resilient building abilities. Try to ask questions harder, and you'll be building your communication passively.

Boss level serendipity

When you communicate clearly, people take notice. People answer your questions faster, you build a better community reputation, and good stuff happens.

Finding answers

In my experience, anytime I try to clearly format my questions, I usually come up with the answers before even asking. Anytime I ask a question, my brain goes into god mode trying to figure out the answer. I don't know why this happens, but you have to give it a try.

Learning to ask

There are four to six steps I take when crafting my questions, this idea is not originally mine, but I've tweaked it to be simple and effective. Even though I don't always keep to it, it's my default system.

  1. Title - Give a one-liner to what the question might be about, or the scope of the question.

  2. Description - Briefly describe what you are working on, or what you are doing.

  3. Expectation - What were you expecting from the code or feature? Share the code.

  4. Reality - What actually happened? Describe the error in detail.

  5. Thoughts - What do you think might have caused this problem?

  6. Action - What steps have you taken to solve the problem? You can ask for directions (and if it's annoying, ask for the answer ๐Ÿ˜‚).

Check it out

Now we are going to take the first question, and clearly outline and format it using the six steps.

Title - Working with Javascript Array methods (on the DOM)

Description - I'm learning how to use arrays. So I decided to put objects inside the array and wrote a function to display the next object on the browser.

Expectation - After writing the function to iterate through the array, I expected the details in the object to change as I clicked the button.

Here's the code on <something like a code playground>

Reality - Anytime I click on the button, these errors pop up, and the objects refuse to change.

Thoughts - I think I didn't write the function well, maybe something in my naming or I don't know much about the DOM methods I'm using.

Actions - I'm watching a video to really understand the DOM methods and renaming the variables again. Could you point me to a better resource on using arrays in the DOM? Thanks a bunch.


We won't be able to communicate clearly every time. But if we try to actively do better than just doing nothing, we would attract better help from people, and most importantly train our communication. A win-win right if you ask me.

Care to drop any extra tips? If yes, please do. If not, please like and share. But don't you forget to follow.

Danke ๐Ÿ–ค.