A colleague asked me a wonderful question the other day: what advice would I have for a relatively new developer. My answer? Learn what you can do on your own and when you need to ask for help.
Anyone who knows me knows that I’m always eager to jump in and help answer questions to figure out a solution to a problem. Sometimes it happens that I actually know the answer to a given problem off the top of my head because of my experience(s) with a particular technology or scenario. Much more commonly though, when I see a problem, I have to Google the the answer.
Look, this is something I literally tell people during interviews. I don’t expect you to have every last thing in the Drupal-verse memorized so you can just crank it out on demand. That’s not realistic. None of you are robots. I’m not a robot. I mean sure, if you can just write all the necessary code without looking anything up to generate a configuration form or block plugin, cool! Good for you. I just don’t expect everyone to be able to do that, and many of the best architects and developers I’ve worked with over the years absolutely cannot do that.
In my mind one of the key things that sets a person apart is their ability to go figure stuff out. Specifically, stuff that I know (and they know) they’ve never done before. The developers I want to promote? They can go figure stuff out on their own and they don’t require a lot of hands on attention from me and/or their architects. The people who get promoted even higher? Those are the ones that are so good at figuring things out they can jump into the unknown and help other people solve their problems (even if the helper themselves may not have solved the problem before).
This post is all about how you as a technical person can and should navigate the waters of asking for help. How do you figure things out on your own? When should you give up and ask for help? How should you ask for help when you do ask for help? These are all really important aspects of the social contract between you and your peers.
Imagine this: every time you try to use the microwave in your office kitchenette you have to ask for help. You are perfectly capable of reaching the microwave, interacting with the microwave, and using it yourself. You just haven’t made the effort to understand this particular piece of technology and rely entirely on others to do it for you. If there’s no one in the room with you? You sit and wait and immediately pounce on someone when they come into the kitchen. Maybe you even go find someone else and drag them to the kitchen just so they can punch in numbers for you. Sooner or later? People are going to start getting pissy with you. You’re going to have a reputation. It may actually start to harm relationships with people over time.
Obviously this is a super basic and simplistic example. Writing code is a heck of a lot harder than using a microwave. But at the same time… the scenario isn’t that different. When you go ask for help (and I cannot stress enough, you will always need to ask for help and you should always ask for help) you want to be mindful of the kind of help you’re asking for.
How to Find Answers
So let’s take a more code-based example than our microwave in the kitchen. In the Drupal world, there’s a super common scenario involving Acquia’s Build and Launch Tools. BLT runs a check that compares your configuration in the Drupal database to the configuration on disk. If they don’t match, it will throw an error. That error is:
[Acquia\Blt\Robo\Tasks\DrushTask] Exit code 75 Time 2.857s
[error] Configuration in the database does not match configuration on disk. You must re-export configuration to capture the changes. This could also indicate a problem with the import process, such as changed field storage for a field with existing content. To permit configuration overrides, set cm.allow-overrides to true in blt/project.yml.
[error] Command `setup:config-import ` exited with code 1.
[error] Command `setup:drupal:install ` exited with code 1. I can’t tell you how many times I’ve run into this error, and how much it frustrates me when I do (despite me whole heartedly supporting the reasoning behind the code that throws this error). Yes I practice what I preach when it comes to configuration management strategies in Drupal 9. Also yes, I make mistakes and sometimes my builds error out. It happens!
Here’s the thing about this error though: the keys to unlocking your problem are literally sitting in the output of the problem. Let’s break this down a little bit:
[Acquia\Blt\Robo\Tasks\DrushTask] Exit code 75 Time 2.857sThis line helps us understand what failed / where it failed, but not why.
[error] Command `setup:config-import ` exited with code 1.
[error] Command `setup:drupal:install ` exited with code 1. These two lines, again, help us understand what failed and give us a semi-generic exit code without explaining why.
[error] Configuration in the database does not match configuration on disk. You must re-export configuration to capture the changes. This could also indicate a problem with the import process, such as changed field storage for a field with existing content. To permit configuration overrides, set cm.allow-overrides to true in blt/project.yml. THIS tells you exactly why it threw an error (it also tells you exactly how to fix the error). More importantly, if you Google the error, you will find that the very first result in Google is a Knowledge Base Article (written by my colleague Dane) that tells you what this error is and exactly how to fix it. The second Knowledge Base Article is one I wrote about the issue with a similar solution. The 3rd and 4th Google links are other folks using BLT that are experiencing this exact issue on the BLT issue queue.
My point is that when you have an error with output, the very first thing you do should be to try and read through that output and ask yourself these questions:
does this output actually tell me something useful. if yes, set aside. if no, discard.
for each “useful” tidbit, what does Google tell me about it?
Note: a lot of error output is gobbledygook that is not going to help you. A big part of this is learning what output in error messages you should care about (and which output you should ignore).
I cannot stress this enough: you will not find all the answers to your problems on Google, nor am I suggesting you will. However: you will find some of your answers on Google. I cannot tell you the number of times that someone has run into this exact problem and it’s super duper obvious that they didn’t Google first. How do I know? Because I send them a link to one of those KB articles and they had obviously not seen the article before I sent it to them. After reading the article, they do what it says. It fixes their problem. Good news! We found a solution! High fives all around (and that isn’t sarcasm, I’m genuinely happy when we find a solution to a problem). But this scenario is the microwave of debugging. The error AND a solution are both in the console output. The very first result in Google is a proven solution by the company that maintains BLT. This is incredibly low hanging fruit when it comes to finding your own answer.
Why Should You Bother?
My first two weeks at Acquia, I spent the majority of my time breaking things. Intentionally breaking things. I did this because I was actually really terrified because I had just been assigned to my first project (building out the Digital Signage system for New York’s MTA). I was about to have a development team working for me using a bunch of technology I wasn’t terribly comfortable with. Composer? DrupalVM? These were things I had next to no experience with and I was about to have both a customer and a partner team looking up to me to help them get out of trouble.
The architect on a project is supposed to be the knowledgable one. Supposed to be the person that can help everyone else get out of trouble. I knew that I had two choices coming into that project: I could put in time to understand the technology that we would be using and become as much of an expert as I could in a short period of time, or I could punt every time someone asked for my help. I could evade, I could say I don’t know, I could send them to someone else to get help. Sooner or later though my reputation as a “technical expert” was going to start to waver and wane because I didn’t have the answers.
So I spent a ton of time intentionally breaking Composer and DrupalVM. I tried to simulate every possible thing my team could run into. That way I could see the errors and problems they would have. That way I could try to chase down and Google the answers and fix them. That way when someone on my team had a problem, even if I didn’t know the answer just like that, I had at least run into “similar” sorts of issues in the past.
Did I ask my colleagues for help during this time? Absolutely! There was a ton of stuff I didn’t know and couldn’t find the answers to. I asked my boss, I asked the maintainers of BLT, I asked the maintainer of DrupalVM… I asked a ton of questions. But the point is, I didn’t ask these people every question the instant that I ran into a problem. I spent enough time researching the issues I was running into to either:
find the answer my self (so I didn’t burn my social capital on an easy problem—remember, I was brand new in my job!!)
get enough information about the problem I could help the people who were going to help me narrow down to a specific area of focus.
How to ask for Help
This is where we put this all together. Like I said, I spent a ton of time those first few weeks asking for help (and getting it). I built great working relationships with my colleagues, despite asking for their help and taking their valuable time.
So how do you ask for help in a way that is both respectful and productive?
Put some effort into finding the solution your self (we talked about this earlier in the article)
Share what you’re doing and what’s working (or not) to find the answer: “hey, here’s what I’m trying” or “here’s what I’m looking for and I’m not finding it.”
I really try to avoid jumping into a channel and @here-ing everyone and dumping error output. I try to always give some context to what I’ve tried and where I’m stuck. Usually, I’m not looking for someone to solve the problem for me, I’m looking for someone to point me in the right direction.
I tell developers on my project all the time, when you get stuck, ask for help. I definitely understand for more junior folks early in their career that it can be a real nail biting experience of knowing if you should ask or not. Always always err on the side of asking more questions and wasting less time. But as time goes on and you get more experienced I want you to be spending more and more time figuring these things out on your own. As more time goes on, I want you to be spending more and more time helping other people figure out their problems.
Most importantly, build an ecosystem where it’s ok to ask for help. Don’t make fun of people for asking for help. Don’t make them feel stupid. Don’t browbeat them or shame them. Create a culture of building each other up and helping. Even better, contribute back! If there’s something you’ve really struggled to find the answer to? Write a blog post about it, or open an issue on the issue queue, or open a Knowledge Base article. Do something to help someone else and pay it forward. Doing so helps build your reputation in the best possible way.
In Conclusion
Asking people to set down what they are doing and help you instead truly is an art, and it’s one I highly recommend you practice. There are a ton of technical folks out there all across the spectrum from perfectly happy to help on one end to unwilling to give you the time of day on the other. Sometimes you will be on teams where you truly have to ration the help you ask for because the people you work with don’t want to give you the time of day. I genuinely hope you don’t find yourself in this scenario very often because it just sucks.
I want you to be self-sufficient. Not to get you off my back or get you to leave me alone, but because I know that there will be scenarios where you might not be able to ask for help and receive it in a timely manner. Even if you’re constantly surrounded by willing folks, if you always rely on someone else to solve your problems, sooner or later this is going to happen:
“Oh, such and so is on vacation and they always answer those questions for me. I guess we’ll sit on this for a week.”
“Shoot, it’s the middle of the night where such and so works, we’ll have to wait until tomorrow to get an answer for this.”
We should avoid these types of scenarios at all costs.
Look, errors are frustrating. Debug output is a pain to parse through. But I have confidence in you. You can figure this stuff out. Or at least, you can figure some of it out. When you can’t? There’s a whole bunch of people on your team, at your company, in your community that I bet are willing to help you out.
Photo by Kristin Hardwick from StockSnap