7 ms·

Book Review: The Programmer's Brain

159 points by edent 5y ago

jalino23 5y ago
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.
onebot 5y ago
snake_case for life!
- edent 5y ago
  Yes! I found that really interesting. It bemuses me that studies show $VariableName is more readable than $variable_name!
  - NateEag 5y ago
    There is at least one study that supports snake case being more readable: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&tp=&arnumber=5521745 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...
    - _dain_ 5y ago
      >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.
      - NateEag 5y ago
        Yeah, none of the study results I've seen have been strong. I don't trust them all that much. I prefer snake_case and believe it probably is mildly more readable than camelCase. The underscore comes closer to space-delimited words like we use in English, typographically speaking. It's hard for me not to think that must be easier to read that way. Obviously I can't prove it's better, but it both makes sense to me that it would be and fits with my subjective experience.
  - jpcfl 5y ago
    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 5y ago
      The study referenced - https://ieeexplore.ieee.org/abstract/document/5090039 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 5y ago
        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 5y ago
      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_ 5y ago
      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.
- factotvm 5y ago
  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 5y ago
    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.
- rmk 5y ago
  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 5y ago
  I just do what my linter tells me.
laerus 5y ago
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.
dtech 5y ago
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 https://www.felienne.com/archives/2974 [2] https://www.microsoft.com/en-us/research/blog/lambda-the-ultimatae-excel-worksheet-function/ https://www.microsoft.com/en-us/research/blog/lambda-the-ult...
__mharrison__ 5y ago
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.
jarmitage 5y ago
The author of this book is also the creator of the fantastic Hedy gradual programming language https://hedycode.com/ https://hedycode.com/
servytor 5y ago
Seems like a spiritual successor to "Pragmatic Thinking and Learning: Refactor Your Wetware"[0]. [0]: https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-Programmers/dp/1934356050/ref=sr_1_1 https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-...
MrJohz 5y ago
> 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.
- diego_moita 5y ago
  > 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 5y ago
  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_ 5y ago
    Studies that nobody talks about are probably a lot less likely to be replicated.
- ilaksh 5y ago
  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.).
qwertox 5y ago
> 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.
- gumby 5y ago
  > 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 This problem can be solved by increasing compile time.
- dhzhzjsbevs 5y ago
  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 5y ago
    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.
- cjbgkagh 5y ago
  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.
rg111 5y ago
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.
zephrx1111 5y ago
Nope. This book is pretty disappointing. The author seems not a experienced programmer.
harry8 5y ago
> Butler’s study found statistically significant associations between naming issues and code quality. "We found a statically significant association with cars that drive well and have their wheels properly fitted."
a_bonobo 5y ago
> The interesting thing is that people who multitask often feel very productive Identifying these 'feelings' is what turned my productivity around. There's a lot you can do at work that makes you feel productive - fiddling with LaTeX, answering emails, scheduling meetings - but that are not productive at all. It takes a bit of introspection and pain to realise that I wasted my day doing nonsense, in the worst case with emails I am creating work for others while wasting my own time. Realising when you're being fake-productive is a great skill to have.

159 points by edent 5y ago

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.

onebot 5y ago

snake_case for life!

edent 5y ago
Yes! I found that really interesting. It bemuses me that studies show $VariableName is more readable than $variable_name!
- NateEag 5y ago
  There is at least one study that supports snake case being more readable: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&tp=&arnumber=5521745 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...
  - _dain_ 5y ago
    >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.
    - NateEag 5y ago
      Yeah, none of the study results I've seen have been strong. I don't trust them all that much. I prefer snake_case and believe it probably is mildly more readable than camelCase. The underscore comes closer to space-delimited words like we use in English, typographically speaking. It's hard for me not to think that must be easier to read that way. Obviously I can't prove it's better, but it both makes sense to me that it would be and fits with my subjective experience.
- jpcfl 5y ago
  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 5y ago
    The study referenced - https://ieeexplore.ieee.org/abstract/document/5090039 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 5y ago
      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 5y ago
    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_ 5y ago
    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.
factotvm 5y ago
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 5y ago
  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.
rmk 5y ago
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 5y ago
I just do what my linter tells me.

laerus 5y ago

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.

dtech 5y ago

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 https://www.felienne.com/archives/2974 [2] https://www.microsoft.com/en-us/research/blog/lambda-the-ultimatae-excel-worksheet-function/ https://www.microsoft.com/en-us/research/blog/lambda-the-ult...

__mharrison__ 5y ago

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.

jarmitage 5y ago

The author of this book is also the creator of the fantastic Hedy gradual programming language https://hedycode.com/ https://hedycode.com/

servytor 5y ago

Seems like a spiritual successor to "Pragmatic Thinking and Learning: Refactor Your Wetware"[0]. [0]: https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-Programmers/dp/1934356050/ref=sr_1_1 https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-...

MrJohz 5y ago

> 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.

diego_moita 5y ago
> 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 5y ago
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_ 5y ago
  Studies that nobody talks about are probably a lot less likely to be replicated.
ilaksh 5y ago
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.).

qwertox 5y ago

> 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.

gumby 5y ago
> 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 This problem can be solved by increasing compile time.
dhzhzjsbevs 5y ago
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 5y ago
  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.
cjbgkagh 5y ago
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.

rg111 5y ago

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.

zephrx1111 5y ago

Nope. This book is pretty disappointing. The author seems not a experienced programmer.

harry8 5y ago

> Butler’s study found statistically significant associations between naming issues and code quality. "We found a statically significant association with cars that drive well and have their wheels properly fitted."

a_bonobo 5y ago

> The interesting thing is that people who multitask often feel very productive Identifying these 'feelings' is what turned my productivity around. There's a lot you can do at work that makes you feel productive - fiddling with LaTeX, answering emails, scheduling meetings - but that are not productive at all. It takes a bit of introspection and pain to realise that I wasted my day doing nonsense, in the worst case with emails I am creating work for others while wasting my own time. Realising when you're being fake-productive is a great skill to have.