# Reading Research: A Guide for Software Engineers

DevFeed: [Reading Research: A Guide for Software Engineers](<https://devfeed.tech/articles/reading-research-a-guide-for-software-engineers-12494.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2020/05/25/reading.html>)

Author: Marc Brooker

Published: 2020-05-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Software](<https://devfeed.tech/topics/software.md>), [coding](<https://devfeed.tech/topics/coding.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Stack Overflow](<https://devfeed.tech/topics/stackoverflow.md>), [Raft](<https://devfeed.tech/topics/raft.md>), [API](<https://devfeed.tech/topics/api.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [books](<https://devfeed.tech/tags/books.md>), [cryptography](<https://devfeed.tech/tags/cryptography.md>), [guide](<https://devfeed.tech/tags/guide.md>), [latency](<https://devfeed.tech/tags/latency.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [raft](<https://devfeed.tech/tags/raft.md>), [research](<https://devfeed.tech/tags/research.md>), [software](<https://devfeed.tech/tags/software.md>), [technical](<https://devfeed.tech/tags/technical.md>)

## AI overview

A guide for working software engineers on reading research papers. It presents solution finding, discovery, and curiosity as three useful reading modes, explaining how research can reveal solutions, alternative approaches, optimization opportunities, and new ways to think about technical problems.

## Source excerpt

Reading Research: A Guide for Software Engineers Don't be afraid. One thing I'm known for at work is reading research papers, and referring to results in technical conversations. People ask me if, and how, they should read papers themselves. This post is a long-form answer to that question. The intended audience is working software engineers. Why read research? I read research in one of three mental modes. The first mode is solution finding: I'm faced with a particular problem, and am looking for solutions. This isn't too different from the way that you probably use Stack Overflow, but for more esoteric or systemic problems. Solution finding can work directly from papers, but I tend to find books more useful in this mode, unless I know an area well and am looking for something specific. A more productive mode is what I call discovery. In this case, I've been working on a problem or in a space, and know something about it. In discovery mode, I want to explore around the space I know and see if there are better solutions. For example, when I was building a system using Paxos, I read a lot of literature about consensus protocols in general (including classics like Viewstamped Replication1, and newer papers like Raft). The goal in discovery mode is to find alternative solutions, opportunities for optimization, or new ways to think about a problem. The most intellectually gratifying mode for me is curiosity mode. Here, I'll read papers that just seem interesting to me, but aren't related to anything I'm currently working on. I'm constantly surprised by how reading broadly has helped me solve problems, or just informed by approach. For example, reading about misuse-resistant cryptography primitives like GCM-SIV has deeply informed my approach to API design. Similarly, reading about erasure codes around 2005 helped me solve an important problem for my team just this year. I've found reading for discovery and curiosity very helpful to my career. It has also given me tools t