Be Your Team's Resource
Programmers are a curious bunch. I mean this literally: we are curious by nature. That is a good thing given how rapidly the tech world evolves. That curiosity keeps our skills relevant for our companies and clients. This curiosity is on display anytime a group of programmers go to lunch together and spend it talking about the tech stack du jour.
So why, when we are all so curious, are we so bad at asking questions?
We're all guilty of this. Spinning our mental wheels on a problem someone right next to us probably knows the answer to. We are too hesitant to ask questions.
We each have our reasons for this hesitation to ask. Some enjoy the educational rabbit-hole caused by getting stuck on a problem. Others work with a programmer who leaves their headphones on and responds with frustration when interrupted. Some are just shy. We all have a degree of nervousness about revealing that we don't know something. It's basically the middle-school effect.
What we need is a person on the team who, over time, makes their willingness to field questions obvious. Someone team members are comfortable asking for ideas or help from. As you may have guessed, that person should be you. And why not? The benefits speak for themselves.
Just consider the pros and cons.
Pros
- more complete knowledge on topics you are familiar with
- some basic knowledge on topics you weren't familiar with
- increase your team's overall productivity
- increase your team's trust in you
- a better understanding what everyone is working on
Cons
- you may get a little less work done
Expand yourself
Of all these pros, i think the knowledge increase is most immediately obvious. As the saying goes, "If you can't explain it simply, you don't understand it well enough". Being asked questions regularly forces you to deeply understand topics in a way you didn't before. Over time this results in a surprising understanding of programming concepts.
And it isn't just for the topics you know, but the ones that you don't. When team members are willing to seek your advice or help on topics, you get introduced to many things you might not have seen before. My first introduction to a number of libraries has come from being asked a question by a team member. This is great for you, but it also means you serve as a mind to bounce ideas off of for your team members.
Productivity: a give and take
A resource's productivity absolutely goes down compared to if they never were asked a question. But the dip is not as much as you may think. The increase in understanding you gain over topics often compensates for the dip. Being asked questions by people who think differently than you expands your problem solving perspective a bit, which also leads to you solving problems a bit faster. [citation needed]
However, as your productivity dips, you will be surprised to see the increase in overall productivity of a team. Collectively, the time we waste while stuck on a problem someone else on our team knows the answer to would be a frightening, and quite frankly depressing, statistic. We will never eliminate this in a sustainable way, but that doesn't mean you can't make some progress reducing the wheel spinning.
A higher view, a greater understanding
One of the most valuable things for engineers to learn is the high level view of what everyone is working on. Over time this builds a deep understanding of a living system that is all but impossible to get otherwise. This sort of high level knowledge can be of great use in the future as your role expands and you have a working knowledge of systems you may have never actually worked on.
So file this one under investments. Over the next 3-6 months this will provide little benefit to you. But as the months turn to a year you will notice a differentiation in how you view the systems you have your hands in. Your perspective compared to the other team members will expand, largely because you will have paid attention to the work of those around you.
Tight lips sink ships
Perhaps the biggest collective benefit of becoming a team resource is building the trust and communication level of your team. It begins to foster a culture of learning instead of blindly assuming people know the answers or can "figure it out". Some developers can get very frustrated when they are stuck on a problem. Frustration is rarely something i want my team to embody.
Once the culture evolves, its amazing how people will each expand from their former shells. Shy developers become less hesitant to ask questions. Developers who enjoy the knowledge rabbit-holes tend to enjoy fielding more questions themselves. Heads-down and headphones-on developers get asked fewer question. Everyone wins.
How do you start
I'd suggest spending a day or two without your headphones on in your office. This makes you immediately more approachable. Also, pay attention to body language. Many devs get visually frustrated about problems they are stuck on. When you see it, ask them what's up. More times than not, they will vent about a problem and figure it out themselves while venting. This is a great start.
Another important note here is that many teams already have someone who has been passively acknowledged as the team resource. That is great. If that is the case, the culture is likely already one where people are comfortable asking questions and bouncing ideas off one another. Make yourself a part of it.
Like i said before, everyone wins when teams have a resource to go to with questions and ideas. It's somewhat surprising more teams haven't adopted this culture already. I'm not going to bother speculating on the reasons for it, but i do know the solution. It happens to be a rather easy one.
And hey, everyone wins. Hell of a sales pitch.
tl;dr You have answers to a lot of questions other members of your team don't ask. Become the person they go to for answers.
