> No, reading code is far easier than writing it.

I'm gonna say I think that's flat out wrong in most cases.

Obviously there's a grey area for trivial stuff.

For a one word docs grammar patch, it could be true (and not always, there).

For anything more than a one character code patch, there's so much more complexity that goes into a good review than most people appreciate.

Not to mention the weighing of potential maintenance costs, changelog messaging, etc., even if it may just be a tiny tweak or small parameter change.

You're getting a lot of downvotes for a good reason.

The opposite of this: "code is much harder to read than it is to write" is held up as a ten-commandments style law of programming.

Here's why: When you write code, you as the author know exactly what it does, so you have exactly one copy of the code in your head.

But as you read code, you repeatedly run into "forks", where you encounter something you aren't sure of the meaning of. Even at a very small rate, like understanding 95% of what you're reading, and being unsure about 5%, it adds up. At every one of these points, you create multiple hypotheses of what the program actually does. Each one of these hypotheses is a full "copy" of the program, running in your head. Frequently to __really__ read code, you have to rig it up and test these hypotheses to keep the mental burden low (since directly testing it and confirming one of them collapses/nullifies all the other ones). (This is a huge reason why software that can be inspected live (lisp, javascript, etc) has a fairly high value, and why companies like MS have built fancy IDEs to enable the same thing with compiled software like C++, C#, etc. Past a certain point, you need to poke it with an inspector to test what parts of it do, in order to "read" the code.)

If you just "read code" and think you know what the program actually does — specifically by skimming over those parts where it's like "yeah, I'm not sure, but it probably does XYZ", it's a very juvenile, dangerous mindset. I don't have a polite way to put it, but it's in exactly the same bucket as the usual brogrammers who think their software has no security holes, for no reason other than that they trust their own work. This is where "programming as craftsmanship" breaks down; like other fields like structural engineering, it's better to build a bridge and know it will hold up because you did the actual material calculations (i.e. to not trust your own judgement, but to verify it externally). As opposed to building one, and simply having a hunch that it's sturdy enough to hold for no reason other than that you've built a lot of stuff, and your gut says it's solid.

I don't think the downvotes are for a good reason, as we are speaking within the context of PRs.

If you're the maintainer, then you already have knowledge of how the system works. The PR just has to fit into your mental map of how things should be.

Writing code is easy. Writing understandable, maintainable and documented code that is easy to read, is hard.

What I mean is perhaps best summarised as 'reading and writing are both easy, but a good job of either is preceded by understanding, which is hard'.

So I start with them equal, but then I think understanding can be harder to ascertain from the PR than the initial investigation, or if the solution didn't follow the same lines as you might've chosen yourself.