How to ask a proper question (2025)

As many of our students hardly have any programming experience before they start our program, I often help them not so much with how to apply the code they learn, but how to approach code in general. Colleague teacher Rein Op 't Land and I gathered the advice we give repeatedly to our students and here it all is! Last time, you could read how to figure out what code does. Today: How to ask a proper question.

OK. It seems basic, but you don’t want to know how often we give students some instructions and not much later, they come back like:

Yeah, cool. Then they usually look at me expectantly, to magically solve their mysterious problem and especially when I am not teaching that day, I have absolutely no clue what they are talking about.

On the other hand, there are students that don’t ask for any help and are stuck on a syntax error four hours. That is obviously not the right way to go either. And that is why I would like to present the ultimate guide:

Whenever you start working on improving your code and even more so when you get to work as a junior, this might be tough decision to make. On the one hand, you might feel you can (or should be able to) fix everything yourself. On the other hand, we all know that by trying things yourself, chances are you will make mistakes, and you do not want to waste too much time on stupid stuff that would be easy to fix either.

I figured out that the right moment to ask a question is when you are stuck. Is that an open door? Probably. The real problem turned out the be to identify when you are stuck. Often you will be so caught up in your code, you might not even notice you haven’t made any progress in the last hour.

A technique to focus more on your process, rather than results, is the 5 minute rule. The idea is to set a timer for 5 minutes (or 2, or 10, or 15, depending on the size and complexity of the thing you are working on) and every time it rings, you’ll ask yourself the following questions:

Whenever you can’t answer one of these questions, you’ll set your timer again and spend 5 minutes on answering it. If you managed, you continue to the next, if you couldn’t figure it out, this is the time to ask a question!

You could extend those five minutes to any time that suits you. However, I would recommend to never make it longer than 15–20 minutes. This will not only force you to split up your tasks in smaller steps, but also prevent you from being stuck for too long.

The cool thing about following those four steps, is that you are very aware of your own thought process, making you think of what does and doesn’t work, and where exactly in the process you got stuck, which makes it easier again to formulate a question. Let’s look at how that works in practice!

A super simple example

Let’s look at a super simple example. Imagine, you are building a static webpage (only html/css) to present yourself, applying the five minute rule. After five minutes, you will ask yourself the first question:

1. What problem am I solving/feature am I building?

Easy enough. You are working on your index page. Next question please!

2. What part of the problem/feature am I currently focussing on?

Let’s say your current goal in life is to change your background into a green color.

3. What did you try? What did you want to/ expect to happen?

You tried some code you found online, you are pretty sure it should turn your background color green.

4. What happened instead?

Nothing changed. Plan of action: check the code and otherwise…. ask a question!

A slightly more complex example

If only life were always as easy as the example above! Sadly, (or fortunately,) it isn’t. Let’s look a slightly more complex example. You were asked to create a server for a web shop. Set your timer, see how far you get and after five minutes, start asking your questions!

1. What problem am I solving/feature am I building?

Actually, this might be a tougher one, this time. I mean, you are building a server, which consists of many parts. Where should you start? If you don’t know, take five minutes figure it out. Which parts does a server consist of. Where do you normally start? Rather than possibly being overwhelmed by what you have to do, you now a direction to go to, a smaller problem to solve. Set your timer and go for it! If you didn’t figure out within the time, or if you aren’t sure, go and ask a question!

2. What part of the problem/feature am I currently focussing on?

Let’s say, that after some contemplation while answering the last question, you decided to build a controller. Which endpoints do you need?Which endpoint are you going to start with? Set your timer and figure it out! Got stuck? Ask a question!

3. What did I try? What did I want to/expect to happen?

When you ask yourself this question, you might figure out you just don’t know where to start! It makes sense to look through the docs or examples in other apps that have similar functionality. If you still don’t know after five minutes, ask a question! Ask where you might find better examples. Or you might start at question 2 again, and decide to focus on identifying (or understanding) code in the docs that you don’t know. If you get stuck longer than your timer allows, ask a question!

4. What happened instead?

So you figured out how to work with the docs, set up your controller, created an endpoint to answer to a get request, but rather than some nice json, you get an error. Or even worse, you don’t get any response at all!

If you got an error, good for you! Start again from question two. The specific part that you are focussing on now will be fixing your error. Try doing so for five minutes. Then ask yourself question 3: ‘What did I try? What did I expect to happen’. I you can’t answer that question, try figuring it out for five more minutes. If you still don’t know, ask a question!

If you didn’t get a response, try to figure out why, for five more minutes. If you can’t figure it out within that time: ask a question!

Students sometimes get frustrated because we don’t give them the solution right away, but tell them to google it. We don’t do that because we expect them to be able to fix everything themselves, but because within ten weeks, they will be working in a company, that won’t take guide them through their problems either. As a programmer, you will first have to try to fix your issues yourself. If you get stuck for too long, it is perfectly fine to ask, but only after you tried.

Following the steps above should help you to keep track of your progress and help you to identify when you get stuck. It also makes it easier to actually ask your question. Imagine that now, you would go to a teacher/colleague and rather than stating that ‘it doesn’t work’ you will say:

Or:

Etc. If any junior would ask all of their questions this way, you probably see all the teachers and seniors around you like:

On top of that not only we as teachers, but also you as a (lifelong) student will be able to identify gaps in your knowledge and understanding, which will make you able to grow faster as a developer!

Following those four steps (answering those four questions) not only helps you organizing your mind and asking useful questions, it will also prevent you from being stuck on a problem for longer than 5 minutes. And it will prevent you in many cases pursuing a solution that doesn’t bring you anywhere for longer than 20 minutes. Time that’s both valuable to you as a student and the company that you are working for.

What was your experience as a junior, or going through a bootcamp asking questions? What was your strategy to get thing done? How did you prevent going down the rabbit hole and coming out three days later, all confused? Let us know in the comments below!