The Most Important Thing I've Learned as Junior Developer

I’ve started working at EzDerm two years ago. I’ve had about ten weeks of probation, and at the end I’ve got some feedback on my progress. I was critiqued for few things, and I’ve got another four weeks of probation to improve.

One of the things I was critiqued for was that I asked questions all the time. This sound general, but I’ll describe what they’ve meant. For those first ten weeks, I was asking a lot of questions while people were working. I’ve got the answer, but I’ve annoyed them, breaking their flow, making them switch from their tasks to help me, and similar. In the end, they didn’t get as much done as they would have because of me.

The solution my team lead gave me was to stop asking questions right away and to try something out myself, to find the answer, google it, search the codebase, find something similar and modify, etc. That way I learned more than if they had given me all the answers. This holds to this day, I do my research and try something out before asking them for help.

There are still times I ask them for help with something I have no clue about what’s going on, but I give them heads up, like: “I’ll need help with this, so when you’re available…”, you get the point. Before they come to help me, I try to prepare everything I can so I don’t waste their time. That could be some sample data, so we can debug, or few blocks of code that I’ve tried and don’t see what’s causing the problem, something tip that I’ve got from somebody else that’s related but I don’t quite understand, and similar. This way, they have the context of what’s going on, where I’m stuck, and I don’t waste their time as much as I would if I’d just ask question, and they don’t know what’s it about - since they’re out of context, so they start asking me questions.

Of course, sometimes you have to ask questions, for example there’s a feature you know nothing about. I find who worked on it, and again, give them heads up that I’ll need help.

Building up on the last paragraph, you have to know who to ask. We didn’t work on everything together, there are few people who worked on one feature, others on other feature, etc. Maybe some questions aren’t even for your team, but for somebody from some other team (QA, Project Manager, Web/iOS team…), they can sometimes be of more help. I commonly talk to them to see on client side how something works, what to look out for, what’s related to that, so I can debug and see details about the feature.


This is a bit embarrassing, but I’ll give an example:

Two years ago, if I’m working on some task, as soon as I can’t figure something out, I’d ask somebody (or even everybody) from my team “how do I do x?”. This happened multiple times a day, and I didn’t even try to figure it out.

Now, I usually find the solution by myself because I didn’t ask right away. I get stuck on a problem, I debug, I look at the code a bit deeper, I find comments (if any), and in the meantime I make some progress. If I don’t find the solution, I don’t bother everybody - I find who worked the most on that feature, and let them know I’m having issues, and if they are available soon that I’d appreciate their help.


It’s a rough thing to know that you’re the annoying one, so I hope this helps everybody in similar situation that I was in, not just juniors.