When I started a new job a few months ago, I entered an unfamiliar technology stack. Being the new guy on a project isn’t always easy. While a great team will make it easy to ask questions and learn, there seems to always be another problem to solve, or figure out how something works. This isn’t always solving a software bug, but instead often deals with coming to a greater understanding of how something works, to change the behaviour, or to duplicate it.
I have a great mentor, who knows many aspects of the code base. While he’s always willing to help, I like to reserve my questions for the tough questions. I’ve often found that when asking a colleague about a problem directly, I often wait until they’re at my desk before I rephrase the problem, and make that elusive link between what I think I know, and what the code is hiding. In other words, I can usually figure it out on my own, but I end up explaining it to someone else first.
While this is good, as I’ve solved the problem, and I’ve shown how my thinking works, this isn’t an interview situation where explaining how I think is important. Sometimes, the person I want to ask is away from their desk. They could be in a meeting, or out for lunch. These questions never seem to come at convenient times.
Here are a few techniques you can use to solve these kinds of problems before you pull a colleague over for a talk.
- Summarize the problem in writing. Be specific. This should be a careful analysis of the problem, clearly showing the state of the system, what you’re expecting to see, and what you are seeing. Extrapolate if needed.
- Search the code history. Have any recent changes in the system affected this? Use the blame annotations provided by your version control tool. Perhaps you’re hitting an edge case that wasn’t properly accounted for in recent changes. Watch and see how the function has changed over time. Are all the assumptions still valid?
- From this summary, search the web with any key terms. With some luck, someone else has experienced this problem before, and you can learn what they tried.
- Search Stack Overflow. Many companies now host an internal version, which has information on internal software. These obviously won’t be indexed by Google, and they’re often rebranded. Hopefully there’s something relevant.
- Post your problem to your Stack Overflow site if appropriate. Ensure that you include the written summary from step 1, as well as the results from steps 2-4.
- Send your mentor an email with the link to the Stack Overflow post.
- Finally, it’s best to follow-up with your question, marking the best answer as accepted. Follow up with a comment for anyone who was particularly helpful. Ensure that others who find your question at a later date can also solve the problem.
There’s a set of clear benefits to following a path such as this to solving your problem.
- Help others solve the same problem at a later date.
- Showcase your thinking process for your peers.
- Highlight inefficiencies in the code base. Pain points like this can help target debt reduction strategies.
There are other ways to solve problems like these, but this is an effective strategy in helping not only yourself, but also your organization.