[HN Gopher] Book Review: The Programmer's Brain
___________________________________________________________________
Book Review: The Programmer's Brain
Author : edent
Score : 124 points
Date : 2022-04-03 11:39 UTC (11 hours ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| __mharrison__ wrote:
| I read that book at the end of last year. It seems like there is
| something to intentional action, not just going through the
| motions. (Had a similar thought listening to a recent Huberman
| podcast where the guest said that you would make more gains by
| imagining the muscles working during a workout.)
|
| I tried to apply this to my last attempt at doing the advent of
| code. I tracked every error I made with every solution. It was
| interesting because a few days in I would think, "I don't want to
| do this because it leads to this bug".
|
| If I were really meta, I would go back and analyze it.
| qwertox wrote:
| > when debugging, many programmers prefer to make small changes
| to their code (tweaks) and run it again to see if the bug is
| fixed rather than spending the energy to create a good mental
| model of the problem
|
| Then there's the feeling you get after you have done a dozen of
| fixes to your code and none of them fixed the problem which got
| you started until you realize that you were debugging the wrong
| file. There was so much room for improvement.
| dhzhzjsbevs wrote:
| Brute force problem solving is a technique like any other. Has
| its pros and cons, places it excells and places it doesn't.
|
| I can only expend so much energy learning a problem domain so
| many times a day, sometimes, using instinct and learned
| heuristics to find a fix without building a mental model of the
| wider picture is good enough.
|
| I should also add it depends greatly on your codebase. Some
| code bases are so rotten your heuristics won't work but if you
| have clean abstractions or even just code that generally limits
| the amount of weird and unexpected shit it does you should be
| fine brute forcing a few things saving brain power for later in
| the day.
| WJW wrote:
| So true. I'll add that sometimes there is not really a mental
| model to be built for the code because there wasn't one when
| the code was built; too many programmers over the years, each
| with their own style.
| ilaksh wrote:
| Or like the other night when I fixed something in the code,
| still saw the problem when deploying, then unfixed and tried
| something else, repeat for two solid hours, then finally
| realize I forgot to copy the file into my `web` directory.
| Would have been nice if I just had it outputting to the right
| place from the start.
|
| But that sort of dumb deployment thing is what gets me when I
| am tired, more often than something really complicated.
| cjbgkagh wrote:
| I sometime go weeks without compiling. Background type checking
| and a defensive coding style works well for me. When I do run
| code I expect it to work the first time. I do white box test it
| to be sure. I find other developers to be rather cavalier about
| bugs, bugs are a valuable learning opportunity to me and each
| one goes into a ledger so that lessons are not lost.
| w0m wrote:
| What field do you work in? It's rare I'm able to work on the
| same project for weeks at a time; let alone compile.
| cjbgkagh wrote:
| It's my own software that I sell licenses to. I'm a solo
| dev but I have had contractors help me from time to time. 6
| years of dev time with over 500K LOC of a wide variety of
| languages. It's mostly really dense functional code. It's
| an extremely stable code base - once something is built
| it's unlikely I'll ever have to touch it again. One of my
| primary motivations to do solo dev was to have the freedom
| to do things properly without ill-informed program managers
| rushing me into bad decisions.
| chrisweekly wrote:
| Is any of it OSS? I'm always eager to see high-quality
| codebases like what you've described.
| jalino23 wrote:
| I found the topic on implicit knowledge and deliberate practice
| super helpful.
|
| I turned off intellisense in vscode and just practiced writing by
| copying open source code side by side.
| rg111 wrote:
| I have read a similar book some months ago that was very helpful:
| _Pragmatic Thinking and Learning: Refactor Your Wetware_ by Andy
| Hunt.
|
| I highly recommend it.
| jarmitage wrote:
| The author of this book is also the creator of the fantastic Hedy
| gradual programming language https://hedycode.com/
| laerus wrote:
| Read the first half and I'm loving it. Metacognition is a must
| for programmers that want to improve, especially for late
| bloomers like me.
| onebot wrote:
| snake_case for life!
| rmk wrote:
| Meh. Really depends on the language. You'd be like a fish out
| of water if you stuck to that convention in Javascript or Go,
| whereas you'd be perfectly conventional in Python and C.
| ok123456 wrote:
| I just do what my linter tells me.
| factotvm wrote:
| I'm here for this, but not to declare empathically my position.
| Rather, I'd like to ask a question: Say I'm learning a new
| language that is opinionated about casing. Suppose it _was_
| easier to read one style, but the language in question adopted
| another style. Would you buck the trend of that ecosystem and
| adopt it, or follow convention?
| pmontra wrote:
| You follow convention because the other developers have to
| read and work with your code. You also follow the formatting
| conventions of the language and of the project.
|
| As a polyglot developer it feels a little weird but it can't
| be helped. The mix of camel cased and snaked cases languages
| in the same project or in the same file is inevitable
| sometimes. Think a JS script tag and Ruby <% %> inline code
| in an html.erb file.
| edent wrote:
| Yes! I found that really interesting. It bemuses me that
| studies show $VariableName is more readable than
| $variable_name!
| NateEag wrote:
| There is at least one study that supports snake case being
| more readable:
|
| http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru.
| ..
| _dain_ wrote:
| >One main difference is that subjects were trained mainly
| in the underscore style and were all programmers.
|
| so in this study, where the subjects were trained in
| snake_case, they found snake_case was better.
|
| and in the other study, where the subjects were trained in
| camelCase, they found camelCase was better.
|
| I bet if we did another study of programmers who used
| kebab-case they'd find that kebab-case is better.
|
| I don't think there's any reason to believe any particular
| case style is better than any other. personally I like
| snake_case and kebab-case because I find the word
| boundaries easier to recognize, but that's just a
| preference on my part. I have no idea if it's objectively
| better.
| jpcfl wrote:
| Studies show CamelCase is easier to type, which is what the
| book references. But, studies also show that snake_case is
| easier to read.
|
| Code will be read more than it will be written, so it should
| be optimized for the reader.
| edent wrote:
| The study referenced -
| https://ieeexplore.ieee.org/abstract/document/5090039 -
| says that coders and non-coders find CamelCase easier to
| _read_.
|
| But I'm eager to find counter examples.
| gls2ro wrote:
| I cannot access the study, but I find it odd that they
| say in abstract:
|
| > Results indicate that camel casing leads to higher
| accuracy among all subjects regardless of training, and
| those trained in camel casing are able to recognize
| identifiers in the camel case style faster than
| identifiers in the underscore style.
|
| What does it mean:
|
| > those trained in camel casing are able to recognize
| identifiers in the camel case style faster than
| identifiers in the underscore style.
|
| It is not normal if you train in reading something => you
| are good in recognizing that things that you are trained
| than something else than you did not train for?
|
| If anyone has access to the study, how many among 135 are
| programmers that were trained in camel case and how many
| in snake case?
| drakmaniso wrote:
| It's more complicated than that. The study referenced in
| the book found that snake_case makes _variables_ easier to
| read, but the whole program harder to parse (my guess is it
| 's because of the visual similarity between the underscore
| and a space). With camelCase, it's the other way around.
|
| I vote for kebab-case, but I didn't find any study where it
| was included...
| _dain_ wrote:
| is it easier to type? I can give an objective reason why
| kebab-case may be easier to type: you don't have to press
| shift at any point.
| servytor wrote:
| Seems like a spiritual successor to "Pragmatic Thinking and
| Learning: Refactor Your Wetware"[0].
|
| [0]: https://www.amazon.com/Pragmatic-Thinking-Learning-
| Refactor-...
| dtech wrote:
| The author of the book once made a Turing machine in Excel [1],
| which was called out by Microsoft when they made the Excel
| formula language Turing complete [2].
|
| [1] https://www.felienne.com/archives/2974
|
| [2] https://www.microsoft.com/en-us/research/blog/lambda-the-
| ult...
| MrJohz wrote:
| > The results of Binkley's study show that the use of camel case
| leads to higher accuracy among both programmers and non-
| programmers
|
| Quotes like this always make me nervous about trusting a book,
| because these sorts of studies tend to be pretty difficult to
| replicate, or have very small effect sizes, or just be examples
| of poor research. Yet I see a lot of people use these sorts of
| studies to back up their opinions about what code should look
| like without really acknowledging how difficult it is to test
| these sorts of comparisons. As others in the comments here have
| pointed out, there are other studies that seem to say the
| complete opposite to the one quoted here, and I strongly suspect
| that there are far more important measures of readability, the
| effects of which would completely dwarf any discussion about
| case.
| ilaksh wrote:
| Well.. but to me this one is easy to put in the "possible
| bikeshedding" category without throwing out all of the other
| ideas. Such as, even if someone _really_ proves one way or the
| other, is it really going to be such a big difference?
|
| I prefer camel case but I am very skeptical about snake case
| being so much different. Anyway, that's really another type of
| thing from advice about making small tweaks versus
| comprehensive models (for example.).
| diego_moita wrote:
| > Quotes like this always make me nervous about trusting a
| book, because these sorts of studies tend to be pretty
| difficult to replicate, or have very small effect sizes, or
| just be examples of poor research.
|
| That is precisely the main reason I got rid of my copy of Steve
| McConnell's "Code Complete".
| doliveira wrote:
| I do wish we all would wait until a study is replicated to
| quote it. Or at the very least critically analyzed by the
| relevant expert community.
| sva_ wrote:
| Studies that nobody talks about are probably a lot less
| likely to be replicated.
| zephrx1111 wrote:
| Nope. This book is pretty disappointing. The author seems not a
| experienced programmer.
___________________________________________________________________
(page generated 2022-04-03 23:01 UTC)