
On Bricks and Code - tbartel
http://tombartel.de/2016/09/24/on-bricks-and-code/
======
tbartel
Author here, comments welcome.

~~~
ebcode
I don't disagree w/ your attidude towards the LOC metric, and I especially
like your idea in the footnotes about each line of code being a tax on future
programmers who have to read the code. I'm afraid that the code example itself
is a bit hand-wavy though, since you introduce a "downloadAsync" function that
needs to be implemented differently for each example. So I thing your argument
could be strengthened with a more concrete code sample. Continuing the
money/tax analogy, if each line of code represents a tax to be paid each time
the code is read, then the cost of understanding the code with fewer lines
represents an "entrance fee" that would be a barrier to less-experienced devs.
I could see how even a technically-minded manager might appreciate the code
with the lower barrier to entry -- and justifying their continued use of the
LOC metric thereby.

~~~
tbartel
Thanks for your comment. I see your point with the missing implementation of
"downloadAsync()".

About the "entrance fee": Do you really feel that the shorter version is more
difficult for less-experienced devs to understand? The verbose version is
unlikely to be easily understandable, in my opinion.

In general, I don't think that more lines of code make something more
readable.

~~~
ebcode
The "entrance fee" in this case would be: understanding promises. When you
introduce a new feature into a language, my assumption is that a "less-
experienced dev", by definition, would not have experience using promises in
production. So if you're going to sprinkle in higher-level (or just _new_ )
concepts into your code, you're assuming a certain level of experience for the
devs who will come after you. If, instead, you sort of "spell everything out",
it will take more words to do that, but you aren't referencing an assumed set
of shared knowledge.

If anything, I think it would help to identify what assumptions are inherent
in our code, and at least point to references for a "less-experienced dev" in
the comments. A comment that said: "Hey you! This code uses promises, so if
you don't know about those, check out this ref: [URL]", would be extremely
helpful in this case.

