[OccamsRazr]

The first thing to know is your goal. Your goal could be things such as: to glean core concepts and methodologies, to determine how a paper relates to another research work (such as your own), to find an answer to a specific question (or determine that the paper does not answer that question), to be able to implement what is in the paper in code, or to develop the material further in your own research.

Obviously, how you should read dense technical material will differ greatly depending on your goal.

For instance, if you are looking only for an answer to a specific question, you might prefer to do a sort of DFS on the paper. Read the intro material to get an impression of where in the paper the answer might lie, then go read those parts (in descending order of likelihood of containing the answer). A similar approach might work if you already know the area and are simply looking to see if the paper contains a particular result. Sometimes this process will still require some investment in understanding notation and terminology, but time spent doing this should be kept to a minimum.

On the other hand, if you intend to master the material and develop it further, then you might take a totally different approach where you prepare your own set of detailed notes on the paper (taking care to expand, in places where your own knowledge is lacking, techinical terms and concepts that are used in the paper but not explained using secondary references). This might also include working out many examples or thought experiments to help you internalize the logic and concepts. For a significant paper this process will take a long time, but it will be worthwhile if you truely want to understand the paper comprehensively and be able to build on it in a substantial way.

No matter your goal and approach, the point is that reading a paper productively is a systematic thing. Skimming technical papers lacksidasically is often a waste of time that doesn't produce value.