The Art of Asking (Others) 1/5

When joining a new project or onboarding to a new organization we are often told some variation of “there are no dumb questions” and encouraged to ask away. I appreciate the intention and wholeheartedly agree with the spirit of this saying - that you are not expected to know everything already and asking someone is likely the fastest path to enlightenment. Having a question, in and of itself, is great and getting answers to questions is a key part of how we learn and grow as engineers (and human beings). 

That being said, what I take umbrage with is the idea that every question, no matter how you ask, who you ask or even what you’re asking about is “good” and what matters is that you asked it at all. There’s a big difference between “vague question specific answer” and “teaching me to fish” questions.

Over the course of my career(s), my relationship to questions changed, here's the rundown:

Asking Questions as a SWE

Early in my career change, with only CS 101 and a 3 month bootcamp under my belt, bright-eyed and bushy tailed, I didn’t even know what I didn’t know and I had a never ending stream of questions that I was not shy about asking. Luckily for me, I had patient, kind, and smart mentors who answered questions like: 

“omg how did you just know that the port for SSH is 22?! Is there a list of ports somewhere I need to memorize?”

Or 

“Sooooooo a server is like a computer without a monitor?”

Over time I noticed a pattern, I would ask what I thought was a simple question and find myself in a 20 minute long quasi-lecture that didn’t always address the actual question I had. Sometimes the background context and diversions were interesting and necessary but many times they weren’t. Like when I was managing my teams Jenkins setup came across a mention of Hudson, I asked “Why is there a mention of Hudson in this Jenkins docs?” and got a long answer about the history of the project(s) and the fork. That certainly answered the question that I asked but in way more detail than I needed. Ultimately what I wanted was a short answer like “Jenkins is a fork of an original project Hudson, you don’t need to worry about it”. 

When I asked “bad” questions, nobody won! I left more frustrated and in the dark than before. The person answering my question(s) would sometimes be frustrated because they spent a lot of time answering the wrong question. Partially this was because I didn’t know the lingo to use, partially because as a newbie I didn’t have much experience to draw on, and probably a bit of bad impulse control thanks to undiagnosed adhd. Maybe a few months into my career is when I realized there was more to asking a question than word vomiting stream of consciousness about the problem/concept. Through trial-and-error I got better at preparing and phrasing questions better as I grew as a SWE. 

Answering Questions as an SRE

After switching to infra/operations/sre/”””devops”””” (wo)manning helpdesk became a core duty. Anyone who has done help desk duties can recall endless examples of “bad” questions that became a time sink and ended up frustrating everyone involved. There’s an asymmetry in engineering orgs where there are way more SWEs than SRE/Infra to support them. Anecdotally I found a correlation between the quality of questions asked in helpdesk and the level of fuzziness around team/role expectations and boundaries. Ultimately at the end of the day me and my teammates were getting paid to manage infrastructure, operations and support developers even if we felt like we were doing more than our fair share.  This is about the time I stopped telling people “there are no bad questions!” and developed a more concrete idea of what makes questions frustrating to answer (tl;dr “low effort”). In the context of joining a new company, in a way your peers are being paid to support you and answer your questions, similarly when asking for technical support from a vendor the staff is paid to answer questions. This dynamic all changes when it comes to open source software and projects…

Asking & Answering Questions in FOSS/FLOSS/OSS

After my burnout-sabbatical-retirement I joined Marketing as a Developer Advocate at Chronosphere where I get to focus on the experience with open source observability projects like Fluent Bit, OpenTelemetry, Perses, Prometheus, OpenSearch and more! Popular FOSS or FLOSS or OSS has the same asymmetry issues where there are way more users of a project than contributors or maintainers but another layer is that OSS work is generally speaking unpaid or it’s only a partial responsibility of a role. CNCF hosts a Slack instance for the open source community to gather to discuss projects, get help, and share best practices. There is no expectation that every question will be addressed as support and advice is given on a voluntary basis, that is people CHOOSE what they’re interested in working on and importantly what questions they answer. Sitting in some channels I noticed there were some questions that would get immediate answers or spark a thread full of details and support while others languished and quickly disappeared into the backscroll never to be addressed. And I wondered “what happened? Did they ever find the answer? Were they able to do the thing?” 

From “bad” to better questions

I don’t think the framing of questions as “good” or “bad” is very helpful. I find that asking myself a lot of “bad” questions is the process to formulating a “good” question I can bring to someone else. So this series is about understanding how to ask better questions scoped to onboarding to a new open source project or for technical support troubleshooting. 

The better you get at asking, the better chance you have of not only getting an answer but getting a quality answer. 

Elements of Better Questions

• Due Diligence
• Background Context
• Considering the Channel
• Relevant Details
• Giving Back 

I’ll dig into each of these in detail in future blogs! This series is based on the talk I gave at FOSSY ‘24, I don’t believe the videos are up yet but you can check out my slides (and all of my decks) over on Slideshare https://www.slideshare.net/slideshow/the-art-of-asking-fossy-2024-pdx-paige-cruz/270708495

CAT TAX