The more you progress in your career the more patterns you recognise. Consequently, the notion of “Ha, I’ve seen this before” becomes increasingly frequent. I’ve gone from a brand new struggling data science intern (I really do sometimes miss that) to belonging on a team where I’m one of the longer tenured engineers. I see all sorts of problems arise which have slowly been accumulated in the rather dusty portions of my neural pathways, from my own mistakes, helping others or simply shared learnings and god forbid P1 incidents. Each time, building up my subconscious pattern recognition of “things that break often”, silly things like Boto3 giving you an access denied error when calling PutObject because the bucket is in a different account, or that one specific api endpoint which requires a bearer token as opposed to every other endpoint on that service. This pattern recognition is great, but only if you give me the context needed. In this post we’ll look at how to make your questions get answered faster by being more specific and informative when asking for help.
If you’re in engineering you should have a dedicated channel to talk to engineers in your team, most commonly slack but other platforms exist. There’s a couple of no-nos to be aware of when you’re stuck. First Is anyone familiar with technology X?, you’ll get two responses, silence from those who aren’t and the “Yes, why?“. Rather, I’m using technology X and am running into the following error …. Brilliant! Now I can help you straight away, you’ve successfully reduced the number of hurdles I need to jump through to help you fix your issue. There’s also a second benefit, another engineer might not have been familiar with technology X, however it just so happens that technology X is written in golang which this other engineer is familiar with and they can help too! By just asking, rather than asking for permission to ask a question first there’s no pre-qualification that reduces the pool of people that can help you.
Has anyone worked with Terraform before? becomes: I’m trying to deploy service X with Terraform, but I’m getting this Error: Provider not found when running terraform apply. I’ve already tried reinitializing. Anyone seen this before?
I need help with a weird bug — who can I talk to? becomes: Hey team, I’m using Redis and running into an issue where keys aren’t expiring as expected. I’ve set TTLs, but they don’t seem to be respected. Can I pair with someone on this?
You want your question to come across as informative and direct rather than easy to ignore. You want to capture all potential expertise rather than disqualifying those who might not think of themselves as experts. Just ask and get help faster.
Where are you seeing this issue? What error message are you getting? What are you trying to achieve? - These are the questions that will inevitably get asked by any engineer trying to help. Adding all of your available context will drastically cut down on the back-and-forth we’ll have to have. You could almost think of your question like a mini support-ticket or GitHub issue, content-wise it should be self-contained enough that another engineer ten minutes down the line can still meaningfully respond.
Good considerations:
A screenshot of an error message is helpful. The same error message copied into a code block is far more helpful. It’s searchable, I can copy-paste it, I can pipe it into JQ if need be. Another bonus is that someone running into the exact same error can search it in your Slack history. Use triple backticks (```) to format multi-line blocks, this works mostly everywhere you need it to.
Example:
$ terraform plan
Error: Provider not found
│
│ on main.tf line 12, in provider "aws":
│ 12: provider "aws" {Pair that with a quick note like I’m trying to run tf plan locally. My Terraform version is 1.6.0. I’ve pushed a branch with my changes and can be viewed here … and you’ve given some great context. (Also see how this is all coming together?)
When you do get help, say thanks. Update the thread if you fix it yourself. Drop a quick “resolved — it was due to X” so others can learn from it. If you had to Google around for hours and found an obscure GitHub issue that cracked it, add it in. Including this information in thread after closing an issue will help anyone with a similar issue searching through channels to resolve their problems faster and might even help you in the future.
In the end, we’re all just trying to help. Engineering is too vast, too deep, for any one person to have all the answers. The best engineers ask questions all the time, not because they’re clueless, but because they’re efficient. They care more about solving a problem than proving they can do it alone. On the flipside, when you find yourself answering these questions, you become responsible for creating an environment where we can all thrive. So show care and show that it’s okay to ask for help.