It's Harder to Read Code Than Write It(matt-rickard.com)
matt-rickard.com
It's Harder to Read Code Than Write It
https://matt-rickard.com/its-hard-to-read-code-than-write-it
14 comments
I am reminded here of Harold Ableson's dictum that programs should be written for people to read, and only incidentally for machines to execute.
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.
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.
Maybe if you are starting out. But over the years I have found reading code to actually be easier. You don't need to solve any problem. You just read the (sometimes obfuscated, and incorrect) solution.
Writing code only appears easier. But once you factor in the cost of it becoming correct over time it's much harder.
Writing code only appears easier. But once you factor in the cost of it becoming correct over time it's much harder.
> This has implications on how we use large language models like GitHub Copilot to autogenerate code. Our ability to write code will even further exceed our ability to read it.
In other words, our ability to modify existing code will degrade.
In other words, our ability to modify existing code will degrade.
My experience says the opposite is true.
You must live in an utopia and/or are very good at reading code. My experience sees a lot of code around me get re-written because of poor comprehension skills.
I'm not sure it is fair to say that because we disagree I must live in a fantasy land.
I can read almost any block of code from almost any language and I bet almost everyone can as well.
You typically dont need to be able to even write code in a given language to understand it.
I can read almost any block of code from almost any language and I bet almost everyone can as well.
You typically dont need to be able to even write code in a given language to understand it.
I didn't say you lived in a fantasy land but in a different better situation.
Of course programmers can read code and understand the atoms but can they decipher a big system? Even 12 year old children can read English but what is their understanding of something complex written in English? In my experience, I've often run into peers who are not good at diving into systems. IE to clarify and try to get on the same page. I'm contending that the OP was talking about reverse engineering and I feel like a lot of developers are better at engineering than reverse engineering.
Of course programmers can read code and understand the atoms but can they decipher a big system? Even 12 year old children can read English but what is their understanding of something complex written in English? In my experience, I've often run into peers who are not good at diving into systems. IE to clarify and try to get on the same page. I'm contending that the OP was talking about reverse engineering and I feel like a lot of developers are better at engineering than reverse engineering.
Read the post again. The author is clearly talking about smaller blocks of code and speaks of edge cases and AI generated code blocks not large systems. By saying "of course programmers can read code" are you not essentially agreeing with me?
By the way, the very definition of utopia is that it is an imagined fantasy land and most often used in negative ways to suggest delusion.
By the way, the very definition of utopia is that it is an imagined fantasy land and most often used in negative ways to suggest delusion.
You could for example be working at a University and that might be a dream job / utopia. Maybe everyone does things the 'right' way. My anecdata is different than yours.
This is more in line with what I've experienced. https://www.joelonsoftware.com/2000/04/06/things-you-should-...
This is more in line with what I've experienced. https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Often mentioned and relevant to the subject:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
As someone whose job is mostly to read and debug others' code, thanks.
Reading code isn’t that bad but refactoring is without some good integration tests.
I always tell my trainees that they write code not for themselves, but for a murderous psychopath how knows where they live.