I used to think the best engineers are the ones that write the cleanest code. When I started out developing software, I thought it was all about writing the cleanest and fastest. And of course, writing robust software that can stand up to testing. But recently I came to a realization. After years of endless discussions about which design patterns make the “sexiest” code, and refactors upon refactors of perfectly functioning code, it hit me. Most of your time as a software engineer isn’t spent writing code. It’s spent researching.

Research is the backbone of any productive software engineer’s body of work. You research new technologies. You read up on other teams and how they developed software to fit their needs. You try to understand what your competitors are doing, and which features will make a killer product. Being an effective researcher is essential to being an effective software engineer. Next, I’ll tell you why—and share some tips that have helped me.

There are three reasons why I think it’s important to be a good researcher:

1. You become more self-sufficient: Good researchers have greater autonomy. There’s nothing more liberating for an engineer than when she unblocks herself. At startups, where it’s essential to the business to move product quickly, this is especially relevant. If you can get answers from research, you can free up other engineers from disruption, too.
2. You get better at asking questions: OK, so no question is a “bad question.” Unless you didn’t research it beforehand. Imagine you’re in the zone, headphones blasting music, and…BAM! Bob has a question. You ask him to repeat it, because you didn’t hear him the first time (the music). You realize Bob isn’t sure what his question is, and you spend the next 15 minutes trying to understand. Between the two of you, that’s 30 minutes of lost engineering time. Don’t get me wrong: It’s important to ask for help when you need it. But also, don’t be like Bob. Take the time to research your problem and formulate questions before you ask for another person’s time.
3. You make valuable contributions: A lot of an engineer’s time is spent planning for major products. This planning phase includes everything from understanding the user’s needs to architecting the software to supporting the product. Being a good researcher ultimately means you can provide valuable insights. And having valuable insights make products and teams more successful.

Here are a few tips I’ve learned (sometimes the hard way):

1. Don’t go down the rabbit hole: When I’m researching new technologies, I oftentimes get sidetracked by irrelevant details and concepts. Engineers are inherently curious, and that’s a good thing—but when you’re researching it helps to focus on your goal. I like to start by coming up with a set of high level questions I want to answer. I find it especially useful to do this with another engineer. Then I budget out time to find the answers, and budget a little more time to ‘wander.’ This allows me to answer my high level questions, explore the topic a bit more, and catch things that might be interesting.
2. Do document your findings: Make sure to write down what you learn— about what works, and what doesn’t. Documentation is useful for keeping track of relevant information and especially for collaborating with your team. Here, we document everything. We probably spend as much time documenting our findings as we do writing code or solving problems. And it helps to be organized about it: We use Confluence to keep track of our findings. The full text search and versioning give us greater control of our findings and accessibility to our whole organization. But like any good documentation, we put some work into  keeping it organized.
3. Then, present them: Presenting your findings is a great way to keep yourself honest and reinforce to yourself what you have learned. It requires you to make sure you are thorough in your research. It also gives you an opportunity to receive feedback from others and seek out ways to build on your research.

Hopefully, I have convinced you that it’s worthwhile to develop your research skills—for your own sake, as well as your team’s.