It's easier to write code than to read. This isn't a fact but it is generally accepted by many. It doesn't seem obvious at first why but "reading code" isn't like "reading".

https://jonathanfries.net/code-is-still-harder-to-read-than-...

It's also called the law of "Uphill Analysis, Downhill Invention" which states "It is much more difficult to guess the internal structure of an entity just by observing its behavior than it is to actually create the structure that leads to that behavior."

Been reusing and repeating this one quite a lot, since I saw it mentioned in one of this year's RubyConf keynotes: https://blog.jessitron.com/2019/11/05/keynote-collective-pro...

(There is a blog-post version behind this link as well, in case anybody wanted to skim the contents rather than watch video of the entire talk to find out how it fits in.)

Uphill Analysis, Downhill Synthesis is a major point in the book Vehicles. [0]

Fascinating thought experiments.

Here’s an introduction on YT [1], though it really only scratches the surface.

[0] https://www.goodreads.com/book/show/483485.Vehicles

[1] https://m.youtube.com/watch?v=A-fxij3zM7g

Fancy algorithms or one liners are not all that difficult to understand, because all the information is right there. It's when you're writing convoluted code inside a big system that issues of understanding begin to arise, because the incoming developer is unlikely to have all of the context that made the code make sense to the person who wrote it.

It's hard to write a concise example because it really takes a big application to make the point, but consider:

    featureFlag(10, false);
    processOrder();

What's flag 10? I have to go figure it out, wastes time, oh turns out it was to disable tax, why are we doing that? Okay in the function that called this one we checked if we were processing a subscription order.

versus

     if(order->isSubscription)
        processOrderWithoutTax()

Imho this is a fallacy.

I would argue that in order to fully and truly understand some code you have to be able to re-create it from scratch. E.g. to explain weird constants, data structures, design decisions, estimations on complexity. Hence, in my eyes, the intelligence required to perform those tasks are the same.

But, there is a backdoor. Solving problems needs immense creativity. Not everyone that easily grasps a piece of code (a domain expert, savant, MIT wizard) could have written it. To my eyes, that doesn't mean that the savant is necessarily of inferior intelligence, but likely less creative in this area.

It's not about working with an existing solution, but about spotting the error in it.

yeah no. this is not imitating something. This is troubleshooting something that does not behave as expected. The issue is that it works on the normal case/flow but it does not in other edge cases. You're in trouble when you no longer understand why you did things is a certain way when you thought you were "clever"