One of the first things I check when recruiting, and that I try to instill in my teams, is a thirst for asking questions. In this post, I’ll try to dispel most of the misconceptions and bad practices I’ve encountered surrounding this core skill.
“How” doesn’t mean “why” or “what”
It’s not because you know of to do something that you understand the why.
If you go back a few years, you weren’t taught multiplication at school by simply telling you that 2 times 3 equals 6. What is usually done is laying two heaps of 3 pieces each and having you count them as a whole to get you to understand the core principles behind it. It’s the same understanding you have to aim for throughout your career.
For example, when you’re running <package manager> install
you should at least understand the core principles behind that command. Why do we have a <package dependencies>.<ext>
and a<package manager>.lock
file? Where do the packages come from?
So while the “how” will guide you to the “why” or “what”, you can’t have the first one without learning about the others.
Dig only based on necessity
It’s a fine line between understanding the core principles of something and getting into its atomic composition. When learning and asking questions, you must remain pragmatic on the time-to-knowledge-value ratio.
A rule of thumb is that if you use something which feels like dark magic, you should dig into the 20% that dispel 80% of the fog. Some engineers are misled into thinking that their skill level is proportional to memorizing exactly how things work and why. In reality, knowledge is knowing where to find the answers to these questions easily.
For example, if I were to explain package manager, I would go through the following:
Dependencies file used for human readability and interaction
Dependencies can have dependencies themselves
Lock files are for the machine to get reproducible builds and avoid unwanted change
Versions built and bundled tagged versions hosted on a repository
There is probably a cache on your system
But I would leave package fetching optimization alone, as it doesn’t concern me in my everyday job. If I were to need such information, I would probably start with some documentation and may end up digging through source code to get my answers on a use-case basis.
There are no dumb questions…
The rule of thumb on this one is simple; if you don’t get something, chances are that:
At least one other person on your team doesn’t get it
No one may know, and that’s a risk for the whole team
Future team members won’t know either
Consider that it’s effortless to get caught up in a project once you’ve been at it for a couple of weeks. What may have seemed strange at first may now feel normal, which doesn’t mean it is.
Even common knowledge is never as common as you think. For something you learn today that will seem obvious tomorrow, you’ll be surprised at the number of people you expect to know about it that actually don’t.
Just take a step back here, and consider that I’m writing about “asking questions”. It sounds easy on paper, but I’ve needed to explain the gist of it way too often for it to be as trivial as it seems.
…if you ask them once…
If you’ve had to ask something, ensure you’ll only need to ask it once. Whether it’s a document on your team’s knowledge-sharing platform or something scribbled in your notebook, ensure you can find that information again in the future. The how is up to you and your team (or a later post).
… and share the answers
You’ll also get quite the bonus points if you share this new knowledge with your team orally. While writing is essential, it’s only 50% of the work and value. Simply saying “Hey, I’ve learned about X; you can find out more on page Y of our wiki,” will bring out the remaining 50% and exciting conversations with your team.
Question seniority …
Just because your architect, manager, or CTO told you that something is done in a particular way does not mean it’s a universal truth.
While volume changes across teams, technical debt starts on day one of any engineering project. It can be the stack, a third-party provider, or design patterns; every choice made on behalf of the project impacts it in the long run.
A typical example is in a project’s file structure. You may be losing a lot of time finding files because they are organized by type, not by domain/feature. If you asked why you may learn that it’s done this way simply because that was the boilerplate template’s structure.
So it’s vital always to question how things are done by asking why they are done this way. Not everything is picked on purpose, the why may be deprecated, and there is always room for improvement in the “how”.
More than once, when asked a question about a particular project’s standard, I’ve been caught saying, “We do X because of Y back then, but now that I think about it, that’s probably a mistake”. Thus, helping the whole team progress.
… but no need to be smug about it
I love managing teams. Not only because of the social interactions but because that’s when I learn the most.
How? I always approach what my team members discover with curiosity and genuinely want to know more about stuff I don’t have time to work on. By doing that with ten people, I learn way more than I achieve by myself.
If you have a good manager, chances are they will act the same. So, you don’t have to point out that you know more than them; they already know it’s often the case. Simply show them genuine excitement for what you’ve learned and turn this mentoring into a collaboration.
Asking questions is the path to opportunities
Want to work on cool things? Don’t wait for others to include you and ask away. Get a good grasp of not only the tools you use every day but also of the business you’re working in, what process the users currently go through, their issues, what your sales team is pitching, … You’ll learn a lot and may even see opportunities no one has thought of.
We’ll explore more on this topic later on. But I assure you, it’s where the fun part starts.