Modern software development requires a ton of research. Whether you’re trying to solve a complex problem, or learning new technologies, you’re going to be spending a lot of time reading blogs, documentation, and forums. Improving your research skills can greatly increase your effectiveness as an engineer. Here are a few tips:
Read the official docs first.
Big organizations are producing great documentation. Google, and Microsoft (I’m sure there are others) in particular put out a lot of high quality reference material and tutorials. Open source projects increasingly recognize the importance for ubiquitous documentation of their features. When you’re trying to better understand a tool or technology, start with the official documentation. Official documentation is almost always organized by version, and it’s more likely to be complete and correct than unofficial guides.
Recognize your level of competence.
If you begin looking for a solution, but you don’t understand the domain, then you’re going to burn time reading documents that you don’t understand, or searching without the proper keywords. You’re often better off starting with a general overview of the problem domain.Simple overviews will help you to understand the jargon involved, and how the various pieces fit together. When you begin looking for a solution to a specific problem within the domain, you’ll understand the proposed solutions better. With general knowledge of the domain, you’ll have a clearer understanding of what you’re looking for, and which low-level articles are relevant to your search.The value of recognizing that I didn’t know enough to solve a problem became obvious years ago when I was thrown into trying to debug a concurrency error in a Java EE Message Driven Bean hosted on Weblogic. While the error itself turned out to be a fairly straightforward multi-threading issue, the error messages and behaviors resulting from the error were wrapped in layers of framework that I knew nothing about. I burnt a lot of time Googling error messages, and messaging behaviors before I realized that I needed to start from scratch and build an understanding of the system’s fundamentals. Once I had a clear understanding of the fundamentals, the potential sources of the root cause became obvious.
Scan and delve.
Scan websites and documentation for the subject you’re looking for, or for components which may help solve your problem. At this point, make note of sources, you’re just looking for the pieces of the puzzle, not trying yet to figure out how to put them together. Don’t invest too much energy in reading any one source. You’re just looking for candidates about which you’ll gain a deeper understanding. As you accumulate articles, start reading through the most promising end-to-end.I often loop through a set of documents several times in this stage. First, I identify what I believe I need for a complete solution often identifying multiple documents about the same subject. I then I read a little deeper, filtering out articles that aren’t relevant or are redundant. I then then start working through the relevant guides, again making notes of any gaps relevant to my specific problem. Throughout the process, continue to add to your reading list where you find gaps, and cut unhelpful documents.
Refer to blogs and Stack Overflow, but don’t assume their solutions are right for you.
Check the dates, and check the versions. Never use a solution that you don’t understand. Stack Overflow is a fantastic reference for all things technical, and there are blogs describing solutions for every common technical problem, and most uncommon problems as well. However, it’s important to know the difference between a solution which is correct in its context, and one that’s correct for you. And, it is important to recognize when a solution was correct in its time, but is either no longer relevant, or no longer the best solution.Stack Overflow and blogs can be used to guide more in depth research by providing information on how pieces fit together. You’ll find information on what works, but until you understand why it works, the solution has no place in your code.
Know your jargon.
Jargon is necessary and helpful, but it creates potential for confusion on two fronts. The first source of confusion is lack of familiarity with the terms being used. The second, and less recognized source of confusion, is when familiar words have unique meaning within a special context.If you’re struggling to understand an article, and the words being used are unfamiliar, or appear to be used incorrectly, then it’s time to review the vocabulary. You won’t find any glossaries, so it’s time to read through general overviews or introductory tutorials. These types of beginner documents may feel too simple, but they’ll provide the required understanding of the domain and terminology that is used.
Read the bibliography.
Whether you’re looking for a deeper understanding of the subject, or you’re still trying to understand the document you just read, a bibliography or informal list of references will help. If an author links to other works for clarification or as source references, it is almost always rewarding to click through and read the references. Even if these references do not provide any new information on how to implement a solution, they will probably provide details on why the solution works.Follow these tips, and discover what works best for you. Treat research like a skill that you can improve with attention and practice, and you’ll find yourself becoming a more efficient, and more effective engineer.We are Smashing Boxes. We don’t just build great products, we help build great companies. LET’S CHAT.
