---
layout: ../../layouts/BlogPost.astro
title: "Ask The Darn Question!"
pubDate: 2022-11-05
---

One of the areas I struggle with when it comes to working in a professional web development environment is asking questions. Whether it’s a problem I’m stuck on, or something about the codebase I don’t quite understand, I’m more likely to end up banging my head against the wall trying to find the answers myself than reach out and ask someone a question.

It’s not out of pride, at least I don’t think it is. It’s more about insecurity. I’m afraid asking for help will somehow reveal to the more experienced devs that I actually have no idea what I’m doing. I will expose myself as a fraud who doesn’t know the first thing about development, and I don’t deserve to get paid for it.

Of course, logically speaking, this is not true. It’s a story told with a combination of imposter syndrome, an anxiety disorder, and a copious amount of logical fallacies. I’m not a fraud, I’m just inexperienced. I can write code, and it may not be the best code ever written but it generally works, and there’s room for me to improve.

All this to say, it’s ok to ask for help when you need it. I’m writing that as a reminder to myself as much as to you, the reader. No one person has all the answers, and in development there are a multitude of ways to solve a given problem. Consider this: you’re more competent than you give yourself credit for, but maybe you just need a fresh perspective.

I had couple eye-opening experiences this week at work.

Firstly, I was running into an issue where a particular set of values wasn’t getting passed through correctly in our beta environment even though everything was working perfectly when I tested locally on my machine. I was stumped. My boss took a look and suggested I get the values I needed from somewhere else. It worked like a charm! In retrospect, it seemed like the obvious solution, but its easy to get so caught up in looking at a problem in a particular way that you lose sight of other perspectives. In this case, it wasn’t that I didn’t understand what I was doing, I just needed another perspective.

Secondly, earlier in the week I was struggling with trying to track down a particular issue in AWS. I couldn’t find the log I was looking for, and I was completely perplexed. I asked a co-worker, and he asked me if anyone showed me our naming convention for our serverless functions and how to navigate them in AWS. I said no, so he took about 10-15 minutes to show me the ropes. It was something I couldn’t have known, I’d had zero AWS experience before this job and I’m still in the process of getting to grips with our massive codebase. Nobody had taught me what I needed to know, and I had been too nervous to ask, so I just flat out didn’t know.

So, if there’s one thing I hope we all can take away from this it’s that, if we’re truly stuck on something, there’s more harm in not asking questions. There will always be something you don’t know, and there will always be another way of looking at a problem you’re facing. As long as you’re not asking for help as a first resort, and you’re putting in the effort to try and solve the problem yourself, then just ask the darn question!

And if you’re ever feeling any doubt, come back and read this post. I know I will.

---

_This post was originally published on my (now defunct) blog on my portfolio site [ghall.dev](https://ghall.dev), and was republished here for archival purposes._
