10 ms·

The Programmer's Brain (2021)

140 points by rzk 2y ago

xerox13ster 2y ago
It's not often that clicking on a too-large-for-the-viewport image with small text makes the text smaller and harder to read. For some strange reason it was assumed that if you clicked the image, you wanted the image to shrink to fit in the viewport without any sort of zoom, readability be damned. Instead of zooming in on the image to reduce cognitive load. My brain responds in a predictable way when I encounter visual anti-patterns such as this: I close the page.
adamgordonbell 2y ago
This looks to be an in-depth summary of "The Programmer's Brain" by Felienne Hermans. I recently interviewed Felienne for my podcast and something a lot of people may not know is that this book was born out of her struggles to teach python to 12 year olds. Out of that struggle also came Hedy. A Multi-lingual learning language that functions as training wheels for Python*. The whole journey she went on is wild story about rethinking assumptions about programming languages and education and learning. https://www.hedycode.com/ https://www.hedycode.com/ https://github.com/hedyorg/hedy/blob/main/grammars/keywords-he.lark https://github.com/hedyorg/hedy/blob/main/grammars/keywords-...
- csours 2y ago
  Could you drop a link to the podcast episode if it's out?
  - adamgordonbell 2y ago
    Yep https://corecursive.com/hedy-with-felienne-hermans/ https://corecursive.com/hedy-with-felienne-hermans/
- jdbernard 2y ago
  The idea of a multi-lingual programming language is so interesting. The fact that there is a lingua-franca for programming is, ironically, both a huge boon for accessibility and a large hurdle. With a single programming language any programmer only has to learn one language to gain access to the vast majority of programming languages and codebases. But if you are not already a native speaker, learning that common language can be a significant barrier to entry. This isn't new, of course, we've had several eras of different lingua-franca in science, for example (Latin, German, etc.). Looking at it more, Hedy looks like it solves the latter problem reducing the barrier to entry. I wonder if something like this could be used to also keep the benefit of a common language. It looks like it allows you to choose at the beginning what language to use for authoring code, but could you use it's mapping of keywords across languages to allow a reader to choose the language they view the code in? Would that be sufficient? Maybe not because you still have variable names, function names, etc. that wouldn't have such a mapping. But I wonder how far that kind of auto-translation would get you. And how effective AI-based translation of the remainder would be, especially if paired with some sort of AST-based tooling that helps the AI to use consistent naming for the same symbols, etc. Interesting!
  - adamgordonbell 2y ago
    My understanding is they can do AST based translation and then use natural language translation to change variables. So they can switch the language, but its limited to the quality of natural language translation of variable names. The RTL langs and the different numbering system, from our interview, seemed like the hardest parts she had to tackle.
    - foobarchu 2y ago
      I wonder how such a translation system would handle variables like i/j counters. If the target language is anything with a non-latin writing system then I can't imagine what you would substitute. I'm sure there's converse examples too, of single-character variables that have no translation to English. Similarly, I wonder how one handles non-obvious shorthand like "rsp"
- certyfreak 2y ago
  Thanks for sharing hedycode. I've been searching for a tool like this to teach kids coding in Ghana. I'm truly grateful.
apantel 2y ago
Seeing all this stuff I can’t help but think that if programming doesn’t just come naturally to your brain such that you would need all this stuff, then you’re probably better off pursuing something that does come naturally.
- n4r9 2y ago
  I had a similar reaction. Also it looks like a lot of the advice pertains to software development rather than programming (e.g. variable/method naming, onboarding newcomers...). Has anyone here used flashcards to help them learn a new language?
- mistermann 2y ago
  I agree, but I think a more important distinction is that while 90% (wild guess) of people could get it via pure System 2 thinking (perhaps via an unpleasant grind of working through it slowly), only a small percentage can think this way intuitively and quickly in System 1. I think there's value in having non-programmers (or experts of any kind) having worked through some non-trivial examples as it may solidify in their mind that what the experts are telling them is legitimate (though, this rests on the requirement that what they are telling people actually is legitimate...which I think is is very much the same problem, but more refined). A classic example of this is COVID, but not only the vaccines aspect. I think this general idea (a much more sophisticated interpretation of it than I'm giving here) has very broad applicability and importance to advanced societies.
- agniikaii 2y ago
  not so sure i agree here unfortunately. i think even if something doesn’t come naturally, if you have passion for it and put in work, then you can learn to think in that way. everything takes practice to get good at and although some things may come naturally, at a certain point hard work beats out raw talent
  - fluoridation 2y ago
    That's assuming that while the passionate untalented person has been working hard at it, the talented person has just been sitting on their laurels, which doesn't really match my experience. People who are naturally good at an activity tend to perform that activity more, since people tend to enjoy succeeding. An untalented programmer who has worked their way to competency would probably make a good teacher, because they can impart all the things that didn't work for them, but they're unlikely to be as good as a talented programmer, given equal cumulative hours of practice for each one.
HarHarVeryFunny 2y ago
From the "Programmer's Brain" title, I was expecting something else. It seems this might better be titled "How to think like a programmer", or "Skills programmers need to know" or somesuch. I was thinking this was going to be about what programming (for a long time) does to your brain - how a programmer's brain works, and how that is different from how non-programmers think (about life in general). I used to joke that programming is a disease, not a career...
- agmater 2y ago
  The full title is: The Programmer’s Brain: What every programmer needs to know about cognition
sesm 2y ago
To me the most common confusion when reading the code is the lack of documented intention behind the code. You can think of deciphering intention from code as a backwards problem, which is exponentially harder then forward problem (checking if given code is actually doing what's intended). Deciphering intention also gets much harder when there are bugs in the code, and you can't be sure if they are bugs or intentional behavior.
- open_ 2y ago
  This is quite a valuable comment that I agree with 100% and from what I understand, a highly unpopular opinion. I hope more people see this.
  - nerdponx 2y ago
    The idea that code should communicate intent, whether by comments or other means, is popular and common. It ends up being somewhat difficult to execute. In practice, you have to write code like you write prose. Keep your audience in mind, and be aware of the contextual information available to that audience, and write code that will make sense to your particular audience, ignoring the needs of non-audiences. The tricky part is when your audience includes people in the future. But even how you account for a future of missing design docs and broken links will vary based on things like team composition, business/problem domain, is this open-source or not, etc.
  - lilfrost 2y ago
    There is consensus documenting why you did something is good (which is what root comment is talking about). Documenting what you did is commonly thought to be a crutch for writing unreadable code.
    - dabraham1248 2y ago
      While I _absolutely_ agree with those sentiments, I have seen nothing like consensus on them myself (in mostly tech startups, but also fintech, and financial (yes, those are different things)). If I limit it to programmers I respect, the percentages go up, but to _maybe_ 75% tops.
ysofunny 2y ago
one of the main things I've generalized from programming: that we must think about everything as if it were two completely disjointed things: what we or the user or the interface does, and how it works... and the potentially completely 'unrelated' reality of what the computer is actually doing consider for example, git. git has a lot of subcommands we seldom use directly, but all commands we use a lot are always combinations, or rarely scripts, of multiple of them seldomly used git (sub?)commands the point being, how the mind of the programmer is all about saying and thinking about "git commit" but actually knowing and considering that it really is many runs of "git hash-object" and lots of other git subcommands behind the scenes.... and so on given how there's gonna be syscalls and eventually assembly instructions moving AND COPYING bits all over the computer
- sanderjd 2y ago
  I really love this framing of it. I think this is exactly what I spend most of my time doing. Although I might say there are three levels I'm thinking about all the time: There are the interface and the "what will the computer actually do" levels, but also a really important one in between of thinking about the future reader of the code. What's interesting, now that you've got me thinking about this, is that I'm not only doing this exercise while programming, but that it's also what I'm doing during all the other parts of my work. While in meetings discussing what to do and how and in what sequence, it's this same exercise of thinking about how we'll need to interface to the human world, and then how we'll get the computer to do what we need, and then how we'll do both those things in a way that will be comprehensible and maintainable. So I think you've really hit the nail on the head here. To me, this is the job.
deleted 2y ago
[deleted]
bloopernova 2y ago
Why is it that this book sits on my shelf gathering dust while I devour books on world war 2 naval history? It vexes me greatly.
- Dalewyn 2y ago
  Born too late to ply the seas and too early to ply the stars, but just in time to ply the tomes.
- plasticchris 2y ago
  Have you read Facing Fearful Odds? It was recommended to me by one of the marines who survived.
  - tmoertel 2y ago
    Thanks for the recommendation. Just ordered a copy!
  - bloopernova 2y ago
    Interesting! I haven't read much on Wake island yet, there's so much to read and learn!
- paganel 2y ago
  > world war 2 naval history? Mind to share some titles? As I’m also interested in naval history and strategy, and for better or for worse I’ve stopped reading programming books a good while ago. Also, and for what it’s worth, I found out that good books on military strategy are also really valuable when trying to apply them to many higher-ish-level programming tasks, so in that respect I’m hitting two birds with one stone.
  - bloopernova 2y ago
    These 2, in this order: Incredible Victory by Walter Lord[1]. The story of Midway, fairly balanced. Shattered Sword by Jonathan Parshall and Anthony Tully[2]. also about Midway, but more research on Japanese sources. Has updated information about some things that are taken as "truth" about Midway. Amazing book. EDITED to add: James Hornfischer has some great books about the Pacific Naval war: The Last Stand of the Tin Can Sailors: The Extraordinary World War II Story of the U.S. Navy's Finest Hour[3]. 6 small escort carriers, and a handful of destroyers and destroyer-escorts vs the heavyweights of the Japanese fleet: Battleships and cruisers. Jaw-dropping descriptions of courage under fire. Fantastic book. Neptune's Inferno: The U.S. Navy at Guadalcanal[4]. Covers several naval battles, but not much on the ground conflict. Really good book too. The Fleet at Flood Tide: America at Total War in the Pacific[5]. The late Pacific war, with the invasion of Saipan, and the naval aircraft battle of the Philippines, leading up to Hiroshima and Nagasaki and the end of the war. ---- [1] https://www.amazon.com/Incredible-Victory-Battle-Midway-Classics-ebook/dp/B0078X73G6/ https://www.amazon.com/Incredible-Victory-Battle-Midway-Clas... [2] https://www.amazon.com/Shattered-Sword-Untold-Battle-Midway/dp/1574889249/ https://www.amazon.com/Shattered-Sword-Untold-Battle-Midway/... [3] https://www.amazon.com/dp/0553381482 https://www.amazon.com/dp/0553381482 [4] https://www.amazon.com/Neptunes-Inferno-U-S-Navy-Guadalcanal/dp/0553385127/ https://www.amazon.com/Neptunes-Inferno-U-S-Navy-Guadalcanal... [5] https://www.amazon.com/Fleet-Flood-Tide-America-1944-1945/dp/0345548728/ https://www.amazon.com/Fleet-Flood-Tide-America-1944-1945/dp...
ayberk 2y ago
This was one of the best books I've ever read. I'll actually go ahead and say this is probably the only book I can confidently say that every professional programmer* should read. You know how sometimes you can "smell" something doesn't seem right? Or seems a lot harder [to understand] than it should be? Yeah all those little intuitions we develop through experience is explained using "brain science" in this book. *: More specifically anyone that writes code in a collaborative environment.
dang 2y ago
Related: Book Review: The Programmer's Brain - https://news.ycombinator.com/item?id=30896120 https://news.ycombinator.com/item?id=30896120 - April 2022 (54 comments) The Programmer's Brain - https://news.ycombinator.com/item?id=27734473 https://news.ycombinator.com/item?id=27734473 - July 2021 (101 comments)
paganel 2y ago
Slightly related, has anyone managed to get some “joy of programming” (for lack of a better word) back after starting to learn a new (human) language? I’m asking because I used to get that in the past (let’s say 10 to 15 years ago) by becoming interested in new programming languages every once in a while, but nowadays I can’t really do a “let’s discover Lisp/Scheme/Erlang” again, and as there are no new interesting programming languages that I know of (with the exception of Rust, which I might consider but it’s not really in my programming interests ballpark when it comes to its use because I’ve never been a C/C++ guy) trying to learn a new actual human language is the closest I can get when it comes to satisfying that intelectual itch.
- jasfi 2y ago
  I found Nim to be refreshing, too bad it's not more popular.
- andoando 2y ago
  I haven't had the energy to sit down and learn something new in a long time. Its all similar enough and after 10+years of seeing code, I don't imagine any wow moments learning anything. Maybe you'd be interested in trying to write your own language or something at this point.
- rramadass 2y ago
  The problem you mention is rather common to senior/experienced developers. One way to get back the "joy of programming" is to study the programming language domain as a whole including Programming Language Theory, Formal Methods, Programming Paradigms and Techniques etc. Most people just focus on the needed mechanics of Programming (because job) without really bothering to look behind the curtain and hence quickly get bored/disillusioned. You have to really motivate yourself to dig deeper. But once you do this, you will begin to look at programming languages in a whole different light. I found the following useful to get back (ongoing) my "joy of programming"; 1) Advanced Programming Language Design by Raphael Finkel. 2) Concepts, Techniques, and Models of Computer Programming by Peter Van Roy and Seif Haridi. 3) Understanding Formal Methods by Jean-Francois Monin. 4) Design Concepts in Programming Languages by Turbak and Gifford.
- 2y ago
rramadass 2y ago
Related: 1) Applying Cognitive Load Theory to Computer Science Education by Juhani Tuovinen et al. - https://www.researchgate.net/publication/250790986_Applying_Cognitive_Load_Theory_to_Computer_Science_Education https://www.researchgate.net/publication/250790986_Applying_... 2) Application of Cognitive Load Theory in Programming Teaching by Xiaoqing Li - https://articlegateway.com/index.php/JHETP/article/view/4418 https://articlegateway.com/index.php/JHETP/article/view/4418 3) Cognitive Load During Problem Solving: Effects on Learning by John Sweller - https://mrbartonmaths.com/resourcesnew/8.%20Research/Explicit%20Instruction/Cognitive%20Load%20during%20problem%20solving.pdf https://mrbartonmaths.com/resourcesnew/8.%20Research/Explici... Also see - https://news.ycombinator.com/item?id=40572984 https://news.ycombinator.com/item?id=40572984
thelinuxfan 2y ago
Types should have been included in the examples. That is very helpful for comprehension.
addisonschultz 2y ago
Very cool to see this on GitBook!

140 points by rzk 2y ago

It's not often that clicking on a too-large-for-the-viewport image with small text makes the text smaller and harder to read. For some strange reason it was assumed that if you clicked the image, you wanted the image to shrink to fit in the viewport without any sort of zoom, readability be damned. Instead of zooming in on the image to reduce cognitive load. My brain responds in a predictable way when I encounter visual anti-patterns such as this: I close the page.

adamgordonbell 2y ago

This looks to be an in-depth summary of "The Programmer's Brain" by Felienne Hermans. I recently interviewed Felienne for my podcast and something a lot of people may not know is that this book was born out of her struggles to teach python to 12 year olds. Out of that struggle also came Hedy. A Multi-lingual learning language that functions as training wheels for Python*. The whole journey she went on is wild story about rethinking assumptions about programming languages and education and learning. https://www.hedycode.com/ https://www.hedycode.com/ https://github.com/hedyorg/hedy/blob/main/grammars/keywords-he.lark https://github.com/hedyorg/hedy/blob/main/grammars/keywords-...

csours 2y ago
Could you drop a link to the podcast episode if it's out?
- adamgordonbell 2y ago
  Yep https://corecursive.com/hedy-with-felienne-hermans/ https://corecursive.com/hedy-with-felienne-hermans/
jdbernard 2y ago
The idea of a multi-lingual programming language is so interesting. The fact that there is a lingua-franca for programming is, ironically, both a huge boon for accessibility and a large hurdle. With a single programming language any programmer only has to learn one language to gain access to the vast majority of programming languages and codebases. But if you are not already a native speaker, learning that common language can be a significant barrier to entry. This isn't new, of course, we've had several eras of different lingua-franca in science, for example (Latin, German, etc.). Looking at it more, Hedy looks like it solves the latter problem reducing the barrier to entry. I wonder if something like this could be used to also keep the benefit of a common language. It looks like it allows you to choose at the beginning what language to use for authoring code, but could you use it's mapping of keywords across languages to allow a reader to choose the language they view the code in? Would that be sufficient? Maybe not because you still have variable names, function names, etc. that wouldn't have such a mapping. But I wonder how far that kind of auto-translation would get you. And how effective AI-based translation of the remainder would be, especially if paired with some sort of AST-based tooling that helps the AI to use consistent naming for the same symbols, etc. Interesting!
- adamgordonbell 2y ago
  My understanding is they can do AST based translation and then use natural language translation to change variables. So they can switch the language, but its limited to the quality of natural language translation of variable names. The RTL langs and the different numbering system, from our interview, seemed like the hardest parts she had to tackle.
  - foobarchu 2y ago
    I wonder how such a translation system would handle variables like i/j counters. If the target language is anything with a non-latin writing system then I can't imagine what you would substitute. I'm sure there's converse examples too, of single-character variables that have no translation to English. Similarly, I wonder how one handles non-obvious shorthand like "rsp"
certyfreak 2y ago
Thanks for sharing hedycode. I've been searching for a tool like this to teach kids coding in Ghana. I'm truly grateful.

apantel 2y ago

Seeing all this stuff I can’t help but think that if programming doesn’t just come naturally to your brain such that you would need all this stuff, then you’re probably better off pursuing something that does come naturally.

n4r9 2y ago
I had a similar reaction. Also it looks like a lot of the advice pertains to software development rather than programming (e.g. variable/method naming, onboarding newcomers...). Has anyone here used flashcards to help them learn a new language?
mistermann 2y ago
I agree, but I think a more important distinction is that while 90% (wild guess) of people could get it via pure System 2 thinking (perhaps via an unpleasant grind of working through it slowly), only a small percentage can think this way intuitively and quickly in System 1. I think there's value in having non-programmers (or experts of any kind) having worked through some non-trivial examples as it may solidify in their mind that what the experts are telling them is legitimate (though, this rests on the requirement that what they are telling people actually is legitimate...which I think is is very much the same problem, but more refined). A classic example of this is COVID, but not only the vaccines aspect. I think this general idea (a much more sophisticated interpretation of it than I'm giving here) has very broad applicability and importance to advanced societies.
agniikaii 2y ago
not so sure i agree here unfortunately. i think even if something doesn’t come naturally, if you have passion for it and put in work, then you can learn to think in that way. everything takes practice to get good at and although some things may come naturally, at a certain point hard work beats out raw talent
- fluoridation 2y ago
  That's assuming that while the passionate untalented person has been working hard at it, the talented person has just been sitting on their laurels, which doesn't really match my experience. People who are naturally good at an activity tend to perform that activity more, since people tend to enjoy succeeding. An untalented programmer who has worked their way to competency would probably make a good teacher, because they can impart all the things that didn't work for them, but they're unlikely to be as good as a talented programmer, given equal cumulative hours of practice for each one.

HarHarVeryFunny 2y ago

From the "Programmer's Brain" title, I was expecting something else. It seems this might better be titled "How to think like a programmer", or "Skills programmers need to know" or somesuch. I was thinking this was going to be about what programming (for a long time) does to your brain - how a programmer's brain works, and how that is different from how non-programmers think (about life in general). I used to joke that programming is a disease, not a career...

agmater 2y ago
The full title is: The Programmer’s Brain: What every programmer needs to know about cognition

sesm 2y ago

To me the most common confusion when reading the code is the lack of documented intention behind the code. You can think of deciphering intention from code as a backwards problem, which is exponentially harder then forward problem (checking if given code is actually doing what's intended). Deciphering intention also gets much harder when there are bugs in the code, and you can't be sure if they are bugs or intentional behavior.

open_ 2y ago
This is quite a valuable comment that I agree with 100% and from what I understand, a highly unpopular opinion. I hope more people see this.
- nerdponx 2y ago
  The idea that code should communicate intent, whether by comments or other means, is popular and common. It ends up being somewhat difficult to execute. In practice, you have to write code like you write prose. Keep your audience in mind, and be aware of the contextual information available to that audience, and write code that will make sense to your particular audience, ignoring the needs of non-audiences. The tricky part is when your audience includes people in the future. But even how you account for a future of missing design docs and broken links will vary based on things like team composition, business/problem domain, is this open-source or not, etc.
- lilfrost 2y ago
  There is consensus documenting why you did something is good (which is what root comment is talking about). Documenting what you did is commonly thought to be a crutch for writing unreadable code.
  - dabraham1248 2y ago
    While I _absolutely_ agree with those sentiments, I have seen nothing like consensus on them myself (in mostly tech startups, but also fintech, and financial (yes, those are different things)). If I limit it to programmers I respect, the percentages go up, but to _maybe_ 75% tops.

ysofunny 2y ago

one of the main things I've generalized from programming: that we must think about everything as if it were two completely disjointed things: what we or the user or the interface does, and how it works... and the potentially completely 'unrelated' reality of what the computer is actually doing consider for example, git. git has a lot of subcommands we seldom use directly, but all commands we use a lot are always combinations, or rarely scripts, of multiple of them seldomly used git (sub?)commands the point being, how the mind of the programmer is all about saying and thinking about "git commit" but actually knowing and considering that it really is many runs of "git hash-object" and lots of other git subcommands behind the scenes.... and so on given how there's gonna be syscalls and eventually assembly instructions moving AND COPYING bits all over the computer

sanderjd 2y ago
I really love this framing of it. I think this is exactly what I spend most of my time doing. Although I might say there are three levels I'm thinking about all the time: There are the interface and the "what will the computer actually do" levels, but also a really important one in between of thinking about the future reader of the code. What's interesting, now that you've got me thinking about this, is that I'm not only doing this exercise while programming, but that it's also what I'm doing during all the other parts of my work. While in meetings discussing what to do and how and in what sequence, it's this same exercise of thinking about how we'll need to interface to the human world, and then how we'll get the computer to do what we need, and then how we'll do both those things in a way that will be comprehensible and maintainable. So I think you've really hit the nail on the head here. To me, this is the job.

deleted 2y ago

[deleted]

bloopernova 2y ago

Why is it that this book sits on my shelf gathering dust while I devour books on world war 2 naval history? It vexes me greatly.

Dalewyn 2y ago
Born too late to ply the seas and too early to ply the stars, but just in time to ply the tomes.
plasticchris 2y ago
Have you read Facing Fearful Odds? It was recommended to me by one of the marines who survived.
- tmoertel 2y ago
  Thanks for the recommendation. Just ordered a copy!
- bloopernova 2y ago
  Interesting! I haven't read much on Wake island yet, there's so much to read and learn!
paganel 2y ago
> world war 2 naval history? Mind to share some titles? As I’m also interested in naval history and strategy, and for better or for worse I’ve stopped reading programming books a good while ago. Also, and for what it’s worth, I found out that good books on military strategy are also really valuable when trying to apply them to many higher-ish-level programming tasks, so in that respect I’m hitting two birds with one stone.
- bloopernova 2y ago
  These 2, in this order: Incredible Victory by Walter Lord[1]. The story of Midway, fairly balanced. Shattered Sword by Jonathan Parshall and Anthony Tully[2]. also about Midway, but more research on Japanese sources. Has updated information about some things that are taken as "truth" about Midway. Amazing book. EDITED to add: James Hornfischer has some great books about the Pacific Naval war: The Last Stand of the Tin Can Sailors: The Extraordinary World War II Story of the U.S. Navy's Finest Hour[3]. 6 small escort carriers, and a handful of destroyers and destroyer-escorts vs the heavyweights of the Japanese fleet: Battleships and cruisers. Jaw-dropping descriptions of courage under fire. Fantastic book. Neptune's Inferno: The U.S. Navy at Guadalcanal[4]. Covers several naval battles, but not much on the ground conflict. Really good book too. The Fleet at Flood Tide: America at Total War in the Pacific[5]. The late Pacific war, with the invasion of Saipan, and the naval aircraft battle of the Philippines, leading up to Hiroshima and Nagasaki and the end of the war. ---- [1] https://www.amazon.com/Incredible-Victory-Battle-Midway-Classics-ebook/dp/B0078X73G6/ https://www.amazon.com/Incredible-Victory-Battle-Midway-Clas... [2] https://www.amazon.com/Shattered-Sword-Untold-Battle-Midway/dp/1574889249/ https://www.amazon.com/Shattered-Sword-Untold-Battle-Midway/... [3] https://www.amazon.com/dp/0553381482 https://www.amazon.com/dp/0553381482 [4] https://www.amazon.com/Neptunes-Inferno-U-S-Navy-Guadalcanal/dp/0553385127/ https://www.amazon.com/Neptunes-Inferno-U-S-Navy-Guadalcanal... [5] https://www.amazon.com/Fleet-Flood-Tide-America-1944-1945/dp/0345548728/ https://www.amazon.com/Fleet-Flood-Tide-America-1944-1945/dp...

ayberk 2y ago

This was one of the best books I've ever read. I'll actually go ahead and say this is probably the only book I can confidently say that every professional programmer* should read. You know how sometimes you can "smell" something doesn't seem right? Or seems a lot harder [to understand] than it should be? Yeah all those little intuitions we develop through experience is explained using "brain science" in this book. *: More specifically anyone that writes code in a collaborative environment.

dang 2y ago

Related: Book Review: The Programmer's Brain - https://news.ycombinator.com/item?id=30896120 https://news.ycombinator.com/item?id=30896120 - April 2022 (54 comments) The Programmer's Brain - https://news.ycombinator.com/item?id=27734473 https://news.ycombinator.com/item?id=27734473 - July 2021 (101 comments)

paganel 2y ago

Slightly related, has anyone managed to get some “joy of programming” (for lack of a better word) back after starting to learn a new (human) language? I’m asking because I used to get that in the past (let’s say 10 to 15 years ago) by becoming interested in new programming languages every once in a while, but nowadays I can’t really do a “let’s discover Lisp/Scheme/Erlang” again, and as there are no new interesting programming languages that I know of (with the exception of Rust, which I might consider but it’s not really in my programming interests ballpark when it comes to its use because I’ve never been a C/C++ guy) trying to learn a new actual human language is the closest I can get when it comes to satisfying that intelectual itch.

jasfi 2y ago
I found Nim to be refreshing, too bad it's not more popular.
andoando 2y ago
I haven't had the energy to sit down and learn something new in a long time. Its all similar enough and after 10+years of seeing code, I don't imagine any wow moments learning anything. Maybe you'd be interested in trying to write your own language or something at this point.
rramadass 2y ago
The problem you mention is rather common to senior/experienced developers. One way to get back the "joy of programming" is to study the programming language domain as a whole including Programming Language Theory, Formal Methods, Programming Paradigms and Techniques etc. Most people just focus on the needed mechanics of Programming (because job) without really bothering to look behind the curtain and hence quickly get bored/disillusioned. You have to really motivate yourself to dig deeper. But once you do this, you will begin to look at programming languages in a whole different light. I found the following useful to get back (ongoing) my "joy of programming"; 1) Advanced Programming Language Design by Raphael Finkel. 2) Concepts, Techniques, and Models of Computer Programming by Peter Van Roy and Seif Haridi. 3) Understanding Formal Methods by Jean-Francois Monin. 4) Design Concepts in Programming Languages by Turbak and Gifford.
2y ago

rramadass 2y ago

Related: 1) Applying Cognitive Load Theory to Computer Science Education by Juhani Tuovinen et al. - https://www.researchgate.net/publication/250790986_Applying_Cognitive_Load_Theory_to_Computer_Science_Education https://www.researchgate.net/publication/250790986_Applying_... 2) Application of Cognitive Load Theory in Programming Teaching by Xiaoqing Li - https://articlegateway.com/index.php/JHETP/article/view/4418 https://articlegateway.com/index.php/JHETP/article/view/4418 3) Cognitive Load During Problem Solving: Effects on Learning by John Sweller - https://mrbartonmaths.com/resourcesnew/8.%20Research/Explicit%20Instruction/Cognitive%20Load%20during%20problem%20solving.pdf https://mrbartonmaths.com/resourcesnew/8.%20Research/Explici... Also see - https://news.ycombinator.com/item?id=40572984 https://news.ycombinator.com/item?id=40572984

thelinuxfan 2y ago

Types should have been included in the examples. That is very helpful for comprehension.

addisonschultz 2y ago

Very cool to see this on GitBook!