If you know an algorithm and writing out the code for it, that can be straightforward. Also if you're reading code for an algorithm that you already know that c

If you know an algorithm and writing out the code for it, that can be straightforward. Also if you're reading code for an algorithm that you already know that can also be straightforward. What's difficult is if you don't already know the algorithm. Still writing code that does what you want can be done incrementally without fully knowing an algorithm and building it up from parts and edge-cases. This can lead to code with accidental complexity. Reading this kind of code is indeed difficult. Code that's well written with any advanced or situation-specific algorithm can also be hard to read. Rewriting it won't help. It may not have been hard to write for the author who did know the algorithm. The best thing to do is document the approach, either in a PR description that can be found on GitHub from a git blame commit hash. Alternatively some choice comments can make it much easier to understand, e.g. before/after or loop invariants. The problem isn't 'reading code' or 'writing code' as each statement is easy enough to parse, but understanding the whole may not naturally follow from understanding the statements. So really 'writing code' is often spelling out what you already know, which is easy. Reading code to gain an understanding of an approach you don't already know is a different skill than writing, so will be more difficult without practice. More often than not however is that there is excess cognitive load from poor naming of methods, variables, classes, or subdivision of the problem.