Before you ask for help, do your homework!

Antonija Bilic Arar

A seasoned engineer shares research methods and tools he developed and uses while encountering issues with code.

Have you ever been approached with a mere “I get an error *waves hands*. Do you know how to fix this?” request for help from a customer or a non-technical colleague, containing no details whatsoever?

Or, differently, have you ever stumbled upon a problem while writing code, scratched your head, and investigated it for a few hours until you gave up and put in a gnarly workaround?

You just wasted a few hours, and the only result you arrived at was a bit of unsatisfactory tech debt. 

Relatable? 

It is for Ievgen Pyrogov, a software engineer from Ukraine who stumbles at code issues every day and has developed a methodology for the steps to be taken before reaching for help. He applies that methodology, called ‘Doing the homework,’ in his everyday work and likes to share it with other software engineers.

Gather the information

So, what does doing your homework mean when whatever you’re trying to do is just not working? For starters, it’s not googling or asking a question on StackOverflow as the first step!

Have you ever asked a StackOverflow question only to receive a request to provide more details before actual help can even start? Ievgen asks. Situations like that are what he calls “homework that is not done.”

While it’s hard to avoid “not doing homework” at all times—indeed, sometimes we get a generic “Segmentation fault” and have no idea what’s going on or where to get any additional info—that is not a typical case.

I am a strong believer that we can do so much more in collecting additional info. Through the years, I’ve adopted a habit of gathering as much information as possible before reaching out for help. That is what I call “doing my homework.”

Controlled discovery chaos

Doing the homework is not a chore but a source of joy and discovery for him because he enjoys learning new things and filling the gaps in his worldview the most in his work. What started as a chaotic discovery process has turned into a somewhat structured process.

I typically let my brain swim in the new information, unconstrained, organic, or chaotic, for the lack of a better word. If you walked past me during my discovery process, you’d easily see the number of tabs in my browser go from 3 to 30 in a few minutes.

Over the years, however, I started noticing patterns in my chaotic approach. For example, I start with Googling, then look through official documentation, then find other places on the internet that are typically not very well indexed by Google, etc. 

In another instance, intuition might tell me I need human help ASAP, so I start by writing a question and going to StackOverflow—in many cases, it makes a lot of sense to prepare and ask the question upfront before continuing a personal discovery adventure.

Did someone else encounter this problem before?

Asked to give an example of what the process may look like, Ievgen walked us through an imaginary situation:

Let’s say I am facing an issue that could be qualified as “a configuration issue.” while configuring something, I followed the steps from the official guide, and yet, somehow, the thing still does not work. The first question I would typically ask myself is: did someone else encounter this before me, or am I looking at something completely new? 

In situations like this, my instinct is to always start by opening Google in my web browser.

Google can be funny, though. Sometimes, it gives literally nothing in response to my search queries, prompting a question: Am I asking a novel question, or am I asking something so dumb that people don’t even bother putting it online?

So, the immediate next question I am faced with is: How do I even know what to Google for? These days, we are very privileged to be able to run Google queries by one of the genies, ChatGPT or Claude, asking them: “Here’s my situation—am I even asking the right thing here?” “What would be a good way to think about this problem?” or “What do YOU think about the issue at hand?”

AI models can give some interesting responses, although I typically try to curb my enthusiasm and treat it as a good food for thought, but not more than that. 

After asking AI and correcting myself a few times, I’d typically pick up the right trail with my search queries and end up on StackOverflow. But what if StackOverflow has no ready answer? That’s where it can get really interesting and where ChatGPT can really help brainstorm the problem and come up with a minimal generic reproduction example that is safe to be shared outside of the company environment.

Apart from asking, googling, browsing through StackOverflow, or using ChatGPT, I like to dig through archives for more clues on my issue. Sometimes, I use search capabilities built into the version control system; sometimes, I visit very specific bug trackers and try to search there; sometimes, I browse through IRC channels or very specific forums.

Ideally, what comes out of this process is a set of information:

Here’s what the official documentation has to say
Here’s what implementation actually does (according to VCS)
Here’s what folks on GitHub Issues say about this
Here’s what a recent change log entry has on the issue – it turns out something got fixed recently, and we’re still on an older version of the software that doesn’t have the fix

Ask, don’t act!

Apart from the joy of discovery and learning that he gets from the process of doing the homework, Ievgen roughly estimates that 60% of the time, doing it helps him find the root cause of issues without even posting anything online! 

Being an engineer, Ievgen admits, means being heavily biased towards taking action, such as jumping on writing a hotfix or digging into a rabbit hole. Hours and hours of futile work could be avoided, he says, if engineers could learn to step back and – ask questions.

 Questions that come to mind sound like this:

“How do I know this?”

“How can I verify this hypothesis?”

“What makes me so sure this holds true?”

“What can I do to verify this class of hypothesis faster?”

“What is it that I could remove from the equation while still demonstrating the problem?”

What I love the most after posting online is when people point out that my expectations were not entirely valid. I crave these moments, as this is when my “view of how the world works” fundamentally slightly adjusts and self-error-corrects.

> subscribe shift-mag --latest

Sarcastic headline, but funny enough for engineers to sign up

Get curated content twice a month

* indicates required

Written by people, not robots - at least not yet. May or may not contain traces of sarcasm, but never spam. We value your privacy and if you subscribe, we will use your e-mail address just to send you our marketing newsletter. Check all the details in ShiftMag’s Privacy Notice