Digesting Technical Content

As people who write code, we often have to know about a fairly large range of topics. Hell, just curating my newsletter takes me all across the software engineering spectrum. Some people find the amount of topics and information overwhelming, which I totally understand, and is one of the reasons why I wanted to share a bit about how I go about digesting it all.

At this point, it's pretty rare for me to find an article where I absolutely don't understand anything in regards to concepts or jargon (definitely still happens though), but in the beginning that wasn't the case. When I first started out on Morning Cup (the previous newsletter I worked on), Pek (the guy running it) would sometimes send me articles that left me scratching my head after the first read through. Abstract syntax tree (AST)? I'm more of an oak kind of guy.

Often times articles left me in this state because of the extensive jargon and abbreviations (pro tip if you're writing echnical content: try to minimze this, or at least don't use abbreviations without first defining them). A lot of technical articles assume some prior knowledge (fair enough), but it's not something I always had. So my first step was to always scan through the article and make a list of any jargon/abbreviations I didn't understand. Following that, I'd search up the terms and try to find a layman explanation of what they meant. Wikipedia is generally ok for this, but sometimes I had to find simpler articles because a) the wikipedia posts also assumed some prior knowledge and b) the rabbit holes you get sucked into there are dangerous.

Going back to the article armed with the newly acquired knowledge always made a huge difference. I could somewhat grasp the ideas being presented in the paragraph (whereas before it felt like the reading equivalent of in one ear and out the other). At this point, for especially difficult to understand concepts, I'd reread the sentences out-loud and try to visualize what they meant. Simplifying the words or rephrasing the concept and tying it to something I already knew also helped (it doesn't have to be 100% accurate). AST? A data structure that holds the elements of some code you wrote. Ok so I guess kind of like what you would store the HTML elements in if you were trying to render them.

This would definitely take a while, but with practice, it becomes a lot faster. Also everyone stores information differently, but in general, I think the more senses it's tied to the better you retain the information. That's why I would read out-loud and visualize. When starting to try to understand the ideas presented in the text, you want to reduce the amount of times you have to look something up again because it breaks the flow of the idea, so memorizing is helpful (it's hard to understand something when you have to stop halfway through, go lookup a term, then come back, only to find that you've already forgotten what you read at the start).

When I finished the article, I'd have to write a short summary for it, and which was a very powerful method for testing your understanding. The keyword is short. You can tell when you don't really understand something because explaining it in a sentence or two is VERY difficult. Writing a longer summary is much easier because you can just mostly regurgitate what you read.

After that I would just forget about it for a couple of days, to give it some time to settle in my brain, then come back to the article later and give it another read, focusing on the parts that were previously difficult to understand. If you know someone familiar with the topic, this is a good time to try to have a conversation with them about it and ask questions to clarify things. I can't remember exactly where I read or heard this, I think it might have been Richard Feynman or my semiconductors professor in college, but someone said that they test and grow their understanding by trying to solve edge cases. That approach has stuck with me, and I've found it to be very powerful when you have an expert to bounce ideas off of. Circuling back to the AST example, you could ask how the it differs for a scripting language as opposed to a compiled one? Does every language use it?

That's my general approach to digesting technically heavy content. For long-term storage, I'll use something like logseq. There are usually very few things I try to retain for the long-term though, otherwise I'd be spending most of my day documenting things. It's enough for me to just know the general idea of things, and when something problem or idea comes up, I'll reference the article again by searching it on this site.

What's your approach to digesting difficult concepts? Let us know in the comments.