header logo

How to read technical, math heavy, material

Photo credit to Pixabay

There is no royal road to geometry. - Euclid to Pharaoh Ptolemy I Soter

Articles on this blog are technical though none of the writing is beyond the level of an undergraduate STEM student in a quantitative discipline. Nonetheless, for many people, reading the technical material on this blog can be overwhelming. I personally struggled with reading this type of material much more than my peers but it is a skill which can be learned. When I encounter material that stretches my abilities, here is how I approach it.

  1. read through the document uncritically. At first I assume the author is always right, the math is perfect, and I never double-check a single thing. The goal is to learn what the author wanted me to know - the big picture stuff. If there is some header summary (in academia, this is the abstract; in the more complex articles on this blog, it is under the heading "goals of this article" at the top of the page), I make sure the author and I agree on what the big picture stuff in the article is. If we do not, it is either because the author dedicated undue focus to unimportant pieces of their subject or because I misread or misunderstood parts of the article. My instincts about which description of the situation is accurate depends on my knowledge of the subject (have they written anything I know for sure is wrong or at least poorly described) and my respect for the author. Most of the time I do not so much as look at any equations in a derivation except the starting point and the ending point. This is both the quickest and most useful read through.
  2. determine if the author had anything of value to say. If I am reading something because I am trying to solve a problem, this is especially important. If I am reading recreationally, it is slightly less important because I only need to consider if the ideas are engaging. When I am reading something because a boss told me to or a professor assigned it, it is far less important (what am I going to do? not read it?). Part of the skill of technical reading lies in quickly deciding if an article addresses the problem at hand, and discarding it if it does not. Do not be afraid to read five sentences of a technical article before abandoning it for something more promising. If the article is promising, proceed to step 3.
  3. review the details. For example, let us say an article has an equation \(\frac{dx}{dt} = kx-m\) and a while later there is an equation \(e^\text{something}\). Unless it is important for me to recreate this work, I do not need to verify every step of the derivation. It is enough to know it is a first-order separable ordinary differential equation and it has an exponential result therefore nothing is weird. If the next equation a while later was \(\tan(\phi)\) then I would have to go back because somewhere a change of variable happened, or a new equation and a new thought started, and I missed it.
  4. consider limiting cases as you review the details. For example, in the article on the continuous solution to the loan equation, I eventually solve for "fraction of payment put to interest" \(\phi\) vs "fraction of the way through the loan term" \(\tau\). Intuitively, we know some things about what that equation has to look like. \(\phi\) cannot be negative because how can one pay a negative percentage? It cannot be greater than 1, because 130% of a payment can not go toward something. \(\phi(\tau =1)\) must be 0 because if the loan is divided into infinitesimal payments, the final payment must be all principle. As the interest rate increases, \(\phi\) must increase for all \(\tau\). The point is, we know a lot about what this equation should look like and we can check and see if it behaves appropriately.
  5. double-check the figures and review the derivations. If the subject matter lends itself well to graphical presentation, the figures ought to contain all of the major conclusions. They are the most visually appealing part of the article and, if they are well designed, require the least effort to comprehend. Well designed figures should be the primary focus after determining whether the writing is worth taking the time to fully understand. Often this is the end of the process; if you read the article on the continuous solution to the loan equation and you fully understood the assumptions made, the parameters I solved for and why, and the parameters I graphed (and why), then all that is left to do is appreciate how those thoughts are expressed graphically, appreciate the limiting cases of the relationships plotted, and make a mental note about where to find the information should the need to reference it arrive later.
  6. if warranted (if you need to reproduce or apply the results personally), reread the details as you attempt to apply them. Let us say you are reading the loan article and you need to reproduce part of the plot. As you attempt to troubleshoot your code, refer to the article, and more than just the portion relevant to what you are plotting.
  7. never be afraid to reread. When a technical article is dense and bountiful, I often catch new insights on the third to fifth reread. "Dense and bountiful" is a standard relative to your personal current working knowledge of the subject matter. The section on loans will be more dense and bountiful for those with less working knowledge of differential equations because there is more unfamiliar stuff there.
  8. read supplementary sources to fill in gaps. Let us again take the loans article as an example. Suppose you read it and realize you have forgotten everything about differential equations or never learned any of it to begin with. You can either (1) trust me or (2) review differential equations in another resource (because articles on this website are not a differential equations course). How necessary this is depends on how deep an understanding of the article you need and how far out of your current circle of competence the material is (90% of the time, if you can understand the graph, you can understand the important points in my articles).
Follow @domesticengine7

© MC Byington