Junior Software Developers! You can do better than just say there’s a problem!

Being a team leader for quite a few years now, I’ve noticed experienced software developers ask questions in a fundamentally different way than junior software developers do.
Furthermore, there are junior developers, who at least try to ask questions like the seniors do, and those developers usually advance faster in their teams, compared with their counterparts.
So what’s common in the way seniors and fast-advancing juniors ask questions?
The short answer is — they’re trying to get as close as they possibly can to the answer they need.
In order to explain that in more details, I’ve categorized questions relating programming issues into 5 groups. Here they are:

1. There’s a problem. That’s the easiest way to bring the issue up, and that’s how a junior will often tell you the build is broken, or he gets some error, but you can and should at least TRY to do better.
2. There’s a problem. Here’s what’s causing it. This requires putting some time and effort in thinking/debugging/reading code etc. Saying: “The page I’ve built is not being loaded because the query that runs on page load is stuck” is far better than saying just the first part of that sentence. Even saying “The page I’ve built is not being loaded, I’ve checked the query that runs on page load and it runs fine, so that’s not what’s causing it to be stuck” is better than saying “The page I’ve built is not being loaded, [come check for me what went wrong]”. Obviously you can’t always know the answer to what went wrong, but making an effort to find out, will help you next time you get to a similar problem (either by knowing where to find its cause, or by knowing where NOT to find its cause). Making that effort will also improve your bug finding skills, which is crucial for developers in all levels. But often you can do even better.
3. There’s a problem. Here’s what’s causing it, and here’s a way to solve it. Now you’re really being helpful. Your team leader is probably a busy person, and even if what you’re suggesting is not a very good solution, he may go for that, just because it means you’re handling your own problems, and he doesn’t have to go over to your cubic to discuss what’s not working. He probably won’t settle for lesser code quality, but if your build is broken and you have an idea as to how to fix it, or you’ve already discussed your solution with some senior developer, and got her approval, than you’ll save his time. And again, just like in all higher levels — the effort you put into finding those extra details (in this case the detail is a solution) will obviously improve your technical skills.
4. There’s a problem. Here’s what’s causing it, and here are several ways to solve it. If the issue is a bit more complicated, and there are several viable solutions, and you think your team leader would want to have a say — than you might want to show him all the relevant ways of solving the issue, and decide with him which way to go.
5. There’s a problem. Here’s what’s causing it, and here are several ways to solve it. I recommend this way because of such and such criteria. When you encounter a complicated decision, How do you decide which way to go? The right way is: first, find all relevant solutions, second, find all relevant criteria to compare those solutions by, and third, compare those solutions and find the best one. This is how the best developers I’ve met get to a decision, and when they need their team leader’s opinion or approval, they share all that information with them. So they would say something like: “As for that bug with that file uploader plugin we’re using, I can try to google for known issues, and if that’s not working I can debug it to find the problem myself. I can also download a new plugin, test it, and replace the current one. Another thing I can do is write a new plugin altogether. In terms of time, I estimate the first option to take the least amount of time, but since it seems there is a lot of functionality we’ll later need, that it currently doesn’t support, I think it’s time to find a new plugin. Writing one from scratch, seems like an overkill at this point, hence I recommend I’ll find a new one, and incorporate it in our solution”. As you see, the criteria used here are: time cost, and forward compatibility. There are many other criteria you can compare solutions by. Things like: performance, security, readability (if the issue relates to writing code in different ways), compliance with best practices, and so on. Obviously for some decisions this is an overkill, you don’t need that many details in order to get to every decision you make, but I wanted to give you a complete example of how it’s done. Of course, that’s not only true for “problems”. This is true for all kinds of deliberations concerning programming. Here’s another example: ”As for the DB structure to support the new page, I’ve considered either creating a new table, or adding new columns to an existing table. As the existing table is already quite big, and all of its current columns have very specific meaning and use that they do not share with the new columns, I recommend creating a new table with a 1:1 relationship with the existing one”. I’m sure you can find the relevant criteria used here by yourself. (For more on solving a programming task or bug, check out my Udemy course for Junior Software developers) So I hope you can see how each level is related to how much effort the developer who asks it is willing to invest, and/or how much experience he has. But how do you get from level 0 to level 4? In two words — You try. It’s very tempting to just ask a senior or your team leader what to do, but this way you’ll never advance. It’s very tempting to go for the first solution you think of, and just offer that, but that is unprofessional. Trying to solve every challenge you have, even if the only idea you have is to google it, is far better than just asking someone to tell you what to do. It also respects his time. And it will help you advance over time from level 0 to level 1, from level 1 to 2, etc. I’m not suggesting a junior developer can always ask level 4 questions. Naturally there will be questions you really don’t have a clue as to what to do about them, and there will be other questions you will be able to show some solution, but that’s all. And THAT’S FINE. Just keep on trying to take the next step. (By the way, here are some tips for things you can do when you’re stuck on a software development task) So next time you want someone to help you, think: how far can you advance on your own? What valuable information can you provide them in order for them to help you? Remember, being resourceful is one of the most important qualities a developer can have, and being independent has a lot to do with that. So the one thing you can take from all this is: do all you can before you ask someone else to help you. In the long run it will be worth your while.