There’s a certain kind of programming problem that you won’t find the solution to on Stack Overflow, programming blogs, or even an old-fashioned paper book. It’s the kind of problem that is, to use an old Stack Overflow term, too localized. Imagine you’re working on a software team and you encounter one of the following situations:
- You run a local build (without changing any local files), and it fails.
- You’re working on a feature, and you need to know how to simulate a credit card payment for your product, without actually submitting a credit card.
- You’re about to submit a database schema change, and you want to test the database upgrade process the way it will actually work in the shared test environment and on the live system.
There are a few ways you could potentially solve these problems. You can always use the old standby technique of Googling keywords and seeing if you can match the general results with the specific needs of your project. That may get you some interesting options, but it’s likely to require a lot of work.
If your team has good internal documentation with a search function that works, then you may be in luck. If you can find documentation about the exact scenario you’re looking for, then you’re even luckier. Keeping internal documentation is a good practice for any software team, but it does require discipline. Stack Overflow is even trying to encourage team documentation (as long as the team is willing to publish it to the world) with their teams feature.
When Google and internal documentation fail, there’s still one more thing you can try: ask a local expert. Here are a few tips on doing that effectively.
One of the keys to success on a software team is:
- Finding local experts for each area of the project you’re working on.
- Figuring out how to extract information out of them in a sustainable way.
To map out your co-workers’ areas of expertise, keep track of who gets asked questions about which areas. Ideally you should find multiple experts for each area, so you can spread out your questions and avoid monopolizing one person.
A few things to keep in mind as you siphon knowledge out of your experts:
Everyone has a natural speed at which they like to explain things. If you can’t keep up with someone’s explanation, try breaking in at key points to summarize what they’re telling you. That will slow things down a bit, and help you retain the information. You’ll use up more of their time, but it’s better than having to go back to them and ask the same questions again.
This is less likely, but you may even find someone who explains things too slowly. In that case, you can insert comments into the conversation to indicate that you understand and they can skip a few steps.
Some people can be grumpy about questions. Maybe they’re hoping you’ll go away so they can focus on their own work. It’s tempting to skip over them and find someone else who can help you. But is it really fair to reward the most helpful people with more interruptions? Even if those people are happy to help, they still have their own work to do. So don’t be afraid to pester the grumpy people as well. Once they get started, they may start to enjoy explaining something in their area of expertise.
Sometimes the best kind of expert is someone new to the team, or even new to professional software development. They may not know about everything, but they probably know more than you about something. Maybe they’ve spent a few weeks or months working in a part of the code that you’ve never touched. And because they’re not experts in many areas, they won’t be getting dozens of questions per day, so they’ll have more time to answer your questions in detail.
Talking to new experts is also a good time to remind yourself to cultivate your own expert status, regardless of how long you’ve been working in your area of expertise. You can remind people of what you know by answering questions sent to project email lists, contributing to internal documentation, and giving talks. Soon you’ll also have people interrupting you with questions, which isn’t as bad as it seems. Explaining your work to others is a good way to make sure you really understand it.
There will always be a tension between the need to take care of your own work, and the team’s need for experts to keep everyone productive. The key for experts is to plan time for individual work and time for teaching others, and not try to combine the two. I wrote more about this in Deep Work and Collaboration in Software Development.
The ability to seek out and learn from experts is one of those soft skills that people like to contrast with traditional programmer skills like technology expertise and knowledge of algorithms. My thoughts:
- Soft skills don’t benefit a programmer much without the corresponding technical skills.
- The average programmer has plenty to learn when it comes to technical skills.
The first point isn’t controversial. Asking an expert for help without first learning the fundamentals of the topic you’re asking about is a recipe for frustration on both sides. Your time with a local expert should be used for covering specific topics once you can’t make any more progress on your own.
It’s the second point that can generate disagreement about where people should be spending their time (see Skills for Programmers). Nevertheless, by talking to your local experts, you can get the best of both types of practice. Your daily work is a good source of technical challenges, but you can’t take best advantage of them if you’re stuck on product-specific problems. To avoid this, cultivate relationships with people who can help get you unstuck.
(Image credit: Mai Le)