6 ms·

The intelligence required to write a piece of code =/= the intelligence required to understand it. Usually the second is a lot easier. Writing a fancy Haskell t

The intelligence required to write a piece of code =/= the intelligence required to understand it. Usually the second is a lot easier. Writing a fancy Haskell typeclass to structure a problem might require deep expertise or creativity. Working with such an existing solution isn't as hard. Even in math or science it's harder to create something new than it is to merely imitate it.

ehnto 7y ago
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()
jstimpfle 7y ago
It's not about working with an existing solution, but about spotting the error in it.
rantwasp 7y ago
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"
s_dev 7y ago
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-write-part-1/ https://jonathanfries.net/code-is-still-harder-to-read-than-...
- yebyen 7y ago
  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-problem-solving-in-music-science-art-and-software/ 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.)
  - gherkinnn 7y ago
    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 https://www.goodreads.com/book/show/483485.Vehicles [1] https://m.youtube.com/watch?v=A-fxij3zM7g https://m.youtube.com/watch?v=A-fxij3zM7g
yc_mat 7y ago
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.

ehnto 7y ago

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()

jstimpfle 7y ago

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

rantwasp 7y ago

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"

s_dev 7y ago

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-write-part-1/ https://jonathanfries.net/code-is-still-harder-to-read-than-...

yebyen 7y ago
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-problem-solving-in-music-science-art-and-software/ 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.)
- gherkinnn 7y ago
  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 https://www.goodreads.com/book/show/483485.Vehicles [1] https://m.youtube.com/watch?v=A-fxij3zM7g https://m.youtube.com/watch?v=A-fxij3zM7g

yc_mat 7y ago

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.