Book Review: The Programmer's Brain | Hacker News Reader

Book Review: The Programmer's Brain

shkspr.mobi

159 pointsedent54 comments

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

There's a lot of this type of "bro-science" in the language learning community as well. And what you'll often find when you dig into any of these topics (programming, linguistics, weightlifting) there is usually solid science somewhere that everyone just kinds of ignores for the types of rules that just seem to "make sense" in some way.

And I think at the heart of it too is when you interrogate certain topics too much the answer will often boil down to "We don't know" and that's something that's really hard for people to grapple with if they're not used to admitting it.

What is bro-science?

Stuff that people in a community/scene tell each other and treat as facts that sounds like it could be a thing, regardless of it actually being true or not.

https://www.urbandictionary.com/define.php?term=broscience

What a terrible word. Either using gender purely as a pejorative modifier is ok or it isn't. Try "sistas-science" or even "wives-tales" as synonyms and see what that looks like.

There's plenty of alternatives. "Fake-science, Barnum-science, garbage-science, non-science, nonscience, TED-talk..." It's fertile ground to go all poetic too.

"Either using gender purely as a pejorative modifier is ok or it isn't."

This is binary thinking, language is more flexible than this.

What's more, bro-science isn't purely pejorative, it's /descriptive/ of something that is happening as we speak on bodybuilding forums.

Afaik the term was invented by 'bros' for 'bros' as a way to caution against being too credulous when folks were discussing their personal training regime, supplement 'stack' or what have you with steroids and testosterone.

The closest term for it here in this forum would be 'trading anecdata' or 'Why we chose X to build Z-corp'.

For obvious reasons, they organically settled on 'bro-science' and it's fine for it to be that way.

Programmers often do the the same thing (replace 'supplement stack' with 'tech stack'), and for much the same reason as the gym 'bros', good data is hard to come by, but you need to muddle on and choose /something/.

Language is even flexible enough to be binary where that is appropriate. As indeed it is here.

> What's more, wives-tales isn't purely pejorative, it's /descriptive/ of something that is happening as we speak among married women.

Gentlemen who do body building, ladies who are married are not being described here. Choosing something better from the multitude of possibilities is hardly a blow for freedom, liberty and justice. The sun is gonna rise tomorrow. I can't see any reason not to do it and think it worthwhile if only to exercise our minds as to following principle. YMMV.

I don't think you understand language as much as you think you do. There are nuances terms acquire through usage that make them make more salient points than general terms such as "pseudoscience."

For example the term "wives-tales" isn't just about gender. It brings forth to mind ideas that are incorrect and passed down through generations as correct knowledge. The full phrase is generally used as "old wives tale"

The reason I used "bro-science" instead of a term like "pseudoscience" (or the other alternatives you mentioned) is because it came to mind first as it fits the nuance I'm going for. Which that nuance is not "Gentlemen who do body building." (As if only "gentlemen" do body building, ironically half of the body-builders I know are women). The nuance, if you're familiar with the term, is that it brings to mind something like "regular people who share opinions as if they're facts when they're actually opinions" (and they might be facts, but it's unknown). Or additionally it also brings in another nuanced meaning which is "an opinion that is shared by someone who expresses it strongly and reacts negatively if you question it"

Your alternatives may share some of this, but not in the same way. If you want to invent a new-term and get it into the lexicon I'd be happy to use it.

> The nuance, if you're familiar with the term, is that it brings to mind something like "regular people who share opinions as if they're facts when they're actually opinions"

I can't help you, sorry. I wonder what we did for all those centuries before "bro-science" was coined and heard by some of us here for the first time. I expect wives-tales was popular for some of it.

I guess some of us are unfortunately born as лох

You don't understand language as well as you think. The 'wife' in 'old wive's tales' doesn't refer to 'ladies who are married' at all. Your view that /either/ of the terms is purely pejorative exists only in your head.

I think the term originated out of bodybuilding communities and is used in a humorous/self-deprecating way to label those "just trust me, bro" types of arguments. It's a bit weird seeing it used as a general term to refer to pseudo-science, but it feels appropriate under the original context.

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

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

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.

Studies that nobody talks about are probably a lot less likely to be replicated.

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.

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

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.

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.

This problem can be solved by increasing compile time.

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.

I once spent a whole bunch of time trying to debug and iterate on an issue in a dependency library my application was using. No matter what I tried it just didn’t seem to help with the issue - even though I was certain of the fix. I was going crazy trying different things with none of them making any difference.

I eventually realized I was running into a bug in my build environment. It wasn’t detecting the library had any code changes so it was “optimizing” my build by skipping that library. It was one of a dozen or so dependencies so it wasn’t immediately obvious. Eventually, I set a breakpoint somewhere else in the library code and realized it wasn’t being hit because the source code didn’t match the symbols!

I felt pretty dumb once so figured this out even though rationally I know it wasn’t my fault.

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.

I find that the strategy of writing for a week or two without compiling works well for me too. At least when the goal is big and clear.

Doesn't work with clients who aren't quite sure what their own requirements are, of course. Then it's more of a few days at most, so revisions can be done early.

If I'm interfacing with a library that I'm not familiar with, I'll usually do trial and error in a blank project, separate from the actual project, first. Then write cleanly in the real project. Iteration times on the learning process are faster that way.

Sometimes I'll just write long drafts or snippets in notepad at first, just to stay clear of IDE distractions. It's a fast way of figuring out the structure of things without the need for everything to compile at all times.

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.

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.

Is any of it OSS? I'm always eager to see high-quality codebases like what you've described.

I keep this account (and all social accounts anonymous) so I can’t share my OSS code. I think self-hosting meta language compilers would be the closest similar code base.

My code is targeted to experienced functional programmers, and others of the same skill level seem to have no trouble with it, but the less experienced will bounce off it. My thinking is that those people should get more experience and come back instead of optimizing my codebase to a lower common denominator for ease of hiring. This has made hiring difficult as anyone who can work on my code base can probably get a high paying job at a FANG. But as a solo dev the productivity gain is enough that I still have no trouble competing in my niche.

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

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

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.

Seems like a spiritual successor to "Pragmatic Thinking and Learning: Refactor Your Wetware"[0].

[0]: https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-...

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.

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

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.

snake_case for life!

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?

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.

Yes! I found that really interesting. It bemuses me that studies show $VariableName is more readable than $variable_name!

There is at least one study that supports snake case being more readable:

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...

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

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.

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.

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

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.

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?

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.

The spacebar is huge and under both thumbs, because you use it a lot. - is far away under one fourth finger or pinky, it's bad to type. Shifted letters are common.

Seems like it should be shift+space inserts a variable-split-token and different editors can display it as a - _ or caps of the next character as desired. Like tab characters being configurable as a number of spaces.

or just use Nim which is style-insensitive: case except for the first letter is ignored, as are underscores.

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.

I just do what my linter tells me.

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

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

Reply on news.ycombinator.com