Reading for technical knowledge
Self-taught developers learn by doing. They build one project after another, make mistakes and slowly develop their sensibilities around software development. This is a familiar story if you taught yourself to code.
Not all developers expand their knowledge outside of what they need to meet today’s requirements. Some stick to blog posts, tutorials and stack overflow. While these are useful during day-to-day software development, they won’t help to build deep understanding of the software work with every day.
Reading to build technical knowledge gives you context. You understand the systems your programs work around in more depth. It helps you decide what to build rather than just how to build it. It gives you new ideas for things to create and sets the stage for diving into new fields you otherwise couldn’t access.
Reading for learning
Reading for learning isn’t the same as reading for pleasure. Novels are written so that you can read them in a single pass and enjoy the ride. Technical learning materials don’t work when read this way. You’ll end up getting a cursory knowledge of whatever it is you’re reading about rather than meaningful understanding that you can actually use.
Reading anything containing new knowledge will require multiple passes. You’ll probably need a text editor or pen and paper at the ready to make notes. If it’s the sort of material that lends itself well to experimenting with in code, you’ll want your development environment ready too.
In the first pass read the title, introduction, conclusion and section headings. If there are concepts or words in the text you’ve read so far that you don’t know, write them down so that you can look them up later. Write down questions that the text is supposed to help you answer. Get a good idea of the overall structure and aims of the text before you dive in.
Look up the things you’re not familiar with and find out just enough about them to understand the text you’re reading now. In some cases this might stop you in your tracks. If you don’t have some fundamental knowledge that the thing you’re reading now, you might need to focus on a smaller piece first before trying again later.
In your second pass work through each section carefully. Answer the questions you wrote using the text as a reference. This will help to highlight either parts where the text isn’t clear or where your understanding is still a bit vague. This is also a good time to try out any code samples or do any exercises within the text.
In your final pass, work away from the text. Can you answer the questions you wrote about the text in your own words? Reference the text as much as you need to reproduce the answers. Work towards being able to produce them on your own.
If you paid attention in school and were a good student, none of this will be new to you. This is a modified version of a reading method known as SQ3R. It doesn’t matter that you follow a particular method. It only matters that you can actually apply your new knowledge to technical problems.
Books
Reading published books can be the best way to get meaningful knowledge on a new topic. However, their quality can vary, so do research on what the best introductory book on a topic is before buying.
For topics that you might learn on a Computer Science course, it’s worth looking at undergraduate course syllabi and seeing what textbooks are commonly recommended. If you see that all “Intro to NLP” courses recommend the same book and it has high ratings on Amazon, that’s probably the one you want.
Avoid tutorial books like “Learn C++ in 24 hours”. They probably won’t give you foundational knowledge that you want to develop in a subject.
When in doubt, O’Reilly have a very good reputation for technical books. If there’s a topic like DNS or TCP/IP that you want to read up on, it’s likely that the default O’Reilly book on the topic will provide a servicable introduction.
Official documentation
We only read official documentation when we have a problem with a particular requirement. We fish for classes and methods in the Ruby standard library or look up the exact syntax of a particular type of SQL query.
Few developers set aside time to systematically study the official documentation of the tools they use before they need to. Reading all of the documentation pre-emptively equips you to better solve problems with whatever any technology.
Imagine you took a couple of hours to work through the documentation for the Ruby String class. You might work through the methods and write a little sample code to try each of them out.
You won’t need to memorize them to see the benefit of this. When you’re working on unrelated problems later on, you’ll quickly be able to tell if String has a method that will help. You’ll avoid writing complex code in situations where parts of the standard library would have handled the requirements for you.
This applies not only to String, but the entire standard library. You can’t use parts of the standard libarary that you don’t know exist. By reading through the official documentation just once, you’ll have a much better idea of how the standard library can help you implement things in Ruby. With a more complete reading of the documentation, you’ll also know where to find specific information when you come looking for it later.
This applies to any technology you might care to use. Postgres has tons of features that you would only know existed had you read the documentation. The Rust programming language has extensive, easily readable documentation about all of it’s features.
Especially for technologies you use every day and intend to continue using for the foreseeable future (ten years or more), it’s worth spending a few hours getting to know the documentation. The earlier you work through the knowledge they contain, the longer you’ll see the benefit.
Specs and RFCs
Specifications and RFCs are scary. If you’re not used to reading dry, technically dense material, they can be off-putting and difficult to glean useful knowledge from.
Work through the issues preventing you from reading them and you enjoy a lot of benefits. They represent a “canonical”, or “primary” knowledge that has the final say in how things are supposed to work.
Authors filter knowledge through their own emphasis choices and biases when they write books, tutorials and blog posts for you. When you read a “beginner’s guide” to HTML, you’re not getting a comprehensive treatment. There’s probably a lot more to HTML than the author is letting on, but they need to serve it to you in small chunks.
Read the HTML5 spec however and it doesn’t hold back. It goes through a step by step explanation of exactly what each HTML element does and how it should be used. It has to be very specific about this, because browser programmers will read this spec and use it to implement those features.
Reading specs like this exposes you to unfiltered knowledge. They’re a great deal harder to read than beginners guides, but your knowledge ends up being richer and more fertile for it.
If you read the HTML5 spec beginning to end you’ll know of esoteric elements that are exactly what you need three years later. If you read the HTTP RFC you’ll likely be able to take useful parts of it when trying to design APIs. If you read the language spec of any programming language you use you’ll have a much clearer idea of what it makes possible and why it breaks.
Try to eliminate things that are stopping you from reading material like this. Don’t expect to read documents like this from beginning to end and understand them perfectly. Remember that if you only understand 5% of a spec the first time you read it, you only have to read it twenty times to understand it fully.
Source code
Reading exemplary source removes you from the idea of how technology is supposed to work and brings you face-to-face with the details. Reading and understanding it gives you a starting point for writing your own mini-projects in the same subject.
Reading source code for understanding is just as hard as reading specs or technical documentation. This is compounded if the code is in a language you’re not familiar with. The decision to focus on a particular projects source is therefore one you won’t make lightly.
If you want to find out how web servers work though, it’s worth the time and effort to read for example, the nginx source code. The same applies to Redis, PostgreSQL, Ruby on Rails or anything else you happen to use on a regular basis.
Not only does reading the source code show you exactly how the software works, it also allows you to pick up software development pointers from established projects.
Academic papers
Reading foundational papers in any technical subject can give you a lot of context that you just can’t get otherwise. They’re another form of “primary” information, rather than explanatory content written after the fact.
If for example you want to learn about public key cryptography, a good foundational paper to read might be the New Directions in Cryptography. If you wanted to learn about why we use SQL and relational databases, you might read E. F. Codd’s A Relational Model of Data for Large Shared Data Banks.
This is like trying to learn physics by reading the original papers published by Einstein or Newton. It’s hard. But it provides richness and context that you won’t get via reading second-hand accounts of it. Reading original material like these allow you to be much better-informed about any technical topic you study.
The language these papers use is dry and perhaps deliberately difficult to read. You might feel uncomfortable attempting it, especially if you’re not from an academic background. But having a bit of practical development experience helps. You’ll probably surprise yourself at the level of understanding you have on the first try.
Summary
Reading for knowledge is harder than reading for pleasure. You’ll need to make multiple, progressively deeper passes over texts to really take any meaningful value from it. Instead of blog posts and tutorials, work through books, documentation, specs, RFCs, source code and academic papers. They’ll take more time to read but the knowledge you get will be of a much higher quality.
Don’t let fear stop you from diving into a subject you want to learn about. Take your time, read slowly and get a deeper understanding of whatever it is you want to learn. You’ll end much better equipped to make good technical decisions and contribute value to any team you find yourself on.
