I think one of the most prolific pieces of advice for Junior Engineers is “ask a lot of questions”. The idea behind this is that if you are stuck on a problem and sitting on your hands you are wasting time. You should instead ping your mentor or team lead and ask them as quickly as possible to get the solution.
But this is wrong. Asking questions — before trying to understand — short circuits your learning process. Instead of digging deeply into a problem, you are getting to the end first. The pathways through the code that are so valuable to learn are still foggy bogs of unknown.
In the ideal, fairy tale scenario, the Senior or Lead will stop what they are doing, analyze your question deeply, and give you a nice answer that, not only answers the question, but enlightens you and gives you +20xp and lifts this fog. The problem is this is the real world. In reality most of the time the answerer will just spout the solution and move on.
So why is this a bad thing? Let’s check out an example.
Real World Scenario
Say you were confronted with this little nugget in the codebase.
def update_user_properties(user)
UserPropertyUpdateJob.perform_in(20.seconds, user.id)
end
First thing you probably say to yourself is — "This is fucking stupid! Why the hell are we waiting around for 20 seconds? This is ‘bad code’”. Yep, 100% this is bad code. But, pretty much every codebase I have ever worked on has a piece (or 10) of code like this. If you are lucky you’ll get a little comment that says “DO NOT CHANGE THIS”, but in reality it’s usually like the above snippet. And usually there is a completely valid reason for its existence.
So your first instinct is to hop into slack and write “Why is this sleeping here?”. Senior responds “Ah its a race condition thing, there is a ticket in the backlog to fix it”. What did you learn here? Nothing.
What if instead of asking you try:
Reading all the possible code paths in which this method is being invoked
Removing, increasing, decreasing the delay
Acting like a user and walking through the code paths with the delay removed
My guess is after going through all of that, you will either a) understand why the delay was added in the first place or b) have 20 new questions about the codebase you found on your journey.
When to ask questions
Okay so I was being a little overdramatic earlier. Obviously you want to ask questions, but you want to ask good questions. Questions that show that you tried your best to understand first, before instantly turning to your mentor. So now that you have walked through the code base, understand what is calling your method (and maybe you even figured out the why), you can have a productive conversation with another engineer.
The upside to this is not only that you learned more, but you also saved time for your mentor. If you can batch up your questions, and show that you put in work before turning to them first, you will impress them.
——
If you like this post, consider subscribing. Soon I will be releasing a monthly paid issue aimed at engineers wanting to learn Ops skills. It will cover everything from what is an HTTP request all the way up to building our own monitoring and deployment system.
—— Sponsored
ActionForms - Easy backend for your forms. Collect emails from your site in less than 30 seconds.
WolfStar, Inc. - Top-tier web design & development for all your needs.
Contact me: sam@fdsa.me for sponsorship opportunities