Data engineering is diverse work. We build systems that handle, process, and store data for various analytics and machine learning purposes. Systems, which in turn, touch other systems. Our team is doing a good job with standardizing our workflows and deployments. But still there are so many different systems and parts to these systems, and they change all the time. There’s not one single book or blog post you can read and forever know everything about data engineering in any given situation. Sooner or later, hopefully sooner, you need to – or get to – communicate with others to do your job.
The above may sound self-evident. After all, you need communication skills to work pretty much everywhere. And most of us no longer work with just one system or programming language that you could know by heart and never have to ask anyone anything. Still, asking for help does not come that easily to everyone in this profession. At the office, you could at least just walk over to your colleague and complain vaguely. But now since the pandemic started our team has been working from home, which means that if you need help you’ll need to be more explicit and write your question in chat or email. Sometimes that extra step can help make things clearer – maybe the answer will even come to you while you’re formulating the question. But phrasing the question in a clear way takes time and effort, and having to spend a lot of time on something that used to be so easy at the office and is not directly visible as lines of code or completed tickets can feel stressful and frustrating.
I don’t believe I’m the only one who finds asking good questions difficult. Googling ‘how to ask programming questions’ gives over 308 000 000 hits, so the solution might be more complicated than ‘stop worrying and just ask’. I’m not going to go over how to actually format questions well. That Google search can help you with that, and I don’t think the wording part is the biggest challenge. Rather, I want to focus on why asking questions can be stressful, and think about ways to make it easier. After all, we might be remote for quite a while, so asking for help remotely is a good thing to practice.
I’ll focus on two things that cause stress when asking for help with a problem: having to show your perceived incompetence, and having to decide when to ask for help. This post might speak more to people who are working with systems relatively new to them and can’t avoid running into things they don’t know. Still, having to work remotely takes away the opportunity to casually ask colleagues questions, which can make it more stressful to many.
It feels like everyone else knows everything but me
Revealing that you don’t know something is scary. And it can occur more frequently when working remote. In a team room, there’s support available even if we never explicitly ask for it. If you have a problem, you might not even need to say anything – looking worried or sighing can be enough for someone to offer help. Plus, if you’re dealing with a problem that you kind of know how to solve but not quite, just complaining to your coworkers about difficulties can validate your struggle. They don’t even need to say anything. You can look at them and see if their silence is more of the approving or disapproving kind. Of course, you can just contemplate aloud in chat. But if no one comments, how do you know what that silence means? Did anyone read your message? Was your idea obvious or just bad? Or maybe no one else knows, which is probably more common than we think.
In the team room you also don’t have to make as many decisions on when to ask for help. If you seem to be stuck, someone might just offer help because they see how long you’ve been working on something. Remotely, the responsibility is all on you to ask when you feel you have been struggling with an issue for too long. Under normal circumstances, our team would work remotely one day per week. Then, people liked to say remote work days were the ones they actually got things done and could focus completely. If you run into an issue you could decide to ask once you’re back at the office. But when working remotely every day, you can’t postpone things to your office days any more – questions that arise become interruptions that need to be dealt with right now.
Before the pandemic started, I noticed that a lot of people usually wanted to have their open questions answered before the remote day came up – even though they would be able to ask people over chat or phone on the remote day as well. Maybe we’re so used to the mindset that remote work means less interruptions and interactions that spontaneously asking questions is slightly harder remotely, even though remoteness is our new normal now.
Some more reasons why programmers can be reluctant to ask questions can be found in the 308 000 000 Google results on how to ask questions. I think any non-programmer would be surprised at the level of effort programmers expect from each other before making a simple post – days of research, perfect grammar, catchy title… Granted, most of these tips are for sites where volunteers answer questions, so it’s reasonable to expect the asker to do some work on their own. But most developers know what it’s like to gather courage to present half-working code that nevertheless took hours or days to write, only to snarkily be sent back to documentation for “not really understanding what they’re doing”. Often, the asker will just let it go, thank the person who responded (for what?), or perhaps even lie that they get it now and no longer need help.
How to make things easier
At work, you need to be able to solve problems. Often, this means you need to ask for help, ideally in ways that make your own effort visible and that make the problem clear. To save some of your mental resources for actual coding, here are some tips on making it easier to ask for help.
Practice: Just ask more, questions. Try asking them faster. Ignore the voice that says you have to prove your basic critical thinking skills. After all, you were hired, so you can expect your colleagues’ trust and confidence. Work is not Stack Overflow – you won’t get banned or your reputation decreased if you ask the wrong question. (I know I wrote earlier that the answer to asking better questions easier wouldn’t be just to stop worrying and start asking. But it can be part of the answer!)
However, reading documentation and googling should still be the first step before asking others. In most cases those are the sources your colleagues will be checking as well. Also, the work of answering questions will often fall on the same few people in each team, especially if they have a reputation for being helpful, so try to be considerate and check if the question has already been answered.
Keep it casual: We can try to normalize asking informal questions online (just like “real life”). For many people this isn’t a problem at all, they can just call others with no agenda. But a lot of developers might either avoid talking on the phone, or just not appreciate unexpected interruptions, so it can be useful to try and create a space dedicated to informal questions.
As an example, our team set up recurring Teams meetings, “coffee chats” with no agenda where people could just drop in. At first, we had this coffee chat every day, but after a few weeks less and less people kept showing up. Having informal meetings online is harder than it seems, and a lot has been written about “Zoom fatigue” already, for example here. Missing non-verbal cues and the lack of parallel conversations probably are reasons why the meetings started to feel taxing instead of a nice casual place to ask questions. But since people in the team still felt it’d be nice to have a regular timeslot for asking work-related questions synchronously, we decided to try having the meeting only once per week and with a more clear focus on work.
This weekly chat has succeeded pretty well in creating a space to ask questions that don’t need to be perfectly thought out yet, and it’s a good place to talk about bigger questions that are tedious to have over text chat or in comments on tickets. It’s also an opportunity to talk about big picture things with most people present but no strict agenda required – talks that back during the office days would happen during lunches or coffee breaks with just a handful of people present. Of course, no meeting is immune to people zoning out, but at least people are available if you need them.
Complain: Remember to complain aloud sometimes (both in person and remotely). I’ve found it very refreshing that people in our team can say that they don’t know how to move forward on an issue without having an immediate plan on how to fix it. What’s even more refreshing is that the response from managers and coworkers is not ”why didn’t you tell sooner”. Instead, usually it’s an offer to help or simple encouragement. Knowing that not knowing what to do is ok makes my job much less stressful. And we’re making new things, so it’s good to feel comfortable in uncharted waters.
Categories