Hello everyone.

So, people have asked me recently about

book recommendations

for how to get better in their career

and and so on and so forth. One of the

books that I recently listened to as an

audio book is called The Programmer's

Brain.

Uh this book is written by Dr. Felienne

Hermans. I think I'm pronouncing that

correctly. And so, this video is kind of

my review for that book. I found it

genuinely useful and interesting.

If I had to boil the book down to its

essence, or at least what I think what I

learned and extracted from the book,

it would be an awareness that tasks like

software engineering are difficult

because of the limitations of the human

brain.

And understanding those limitations can

allow you to approach

problems

in a way that takes responsibility for

those limitations, rather than running

into a brick wall and not really knowing

why there is a brick wall. I'm sure some

of you have had a day where you stare at

a 20-line pull request and you keep

staring for 2 hours. You've forgotten

how everything works and you're starting

to feel like maybe you might be stupid.

The early part of the book talks about

different types of memory,

and not computer memory, uh the memory

in your brain.

And it draws analogies between the

memory that you have in your brain and

the memory that you might have uh in a

computer. So, you've got your long-term

memory, your short-term memory, and your

working memory. And you can think of

long-term memory as your hard drive.

You can think of your short-term memory

as

the cache in the processor, in the CPU.

And you can think of your working memory

as RAM.

Once you understand that you have these

different kinds of memory in yourself,

then the game becomes how do I manage my

working memory so that it's not

overloaded?

How do I respect the limitations of my

short-term memory and write my code in a

way that it doesn't get overloaded? And

for long-term memory, how can I take

more information and knowledge from my

short-term memory and place it into my

long-term memory so that I can do things

automatically. This is the kind of thing

that makes learning new frameworks or

data structures or algorithms something

that's either difficult or easy. When I

say easy, we're talking relative.

These tasks are still

challenging, but it's a lot more

challenging if you try to tackle a task

or learn something

and you can't remember it because you've

mismanaged your short-term memory and

your long-term memory, and you have

overloaded your working memory, and you

can't think through the problem anymore,

and you can't remember it anymore. For

me, that was the most useful learning

out of the book. Some of the other

things that the book goes into is this

idea of deliberate practice of reading

code, which

not a lot of people do.

It breaks down the activities that we do

during coding like the transcription of

code, reading code, comprehending code,

searching code,

and uh there's another one called

incrementing code. So, if you already

know what you're doing, then you can

transcribe code quite easily, and this

is actually a task that's very good for

LLMs. If you know exactly what you are

about to construct, you just tell it

what to construct and off it goes and

you don't have to do any typing.

Fantastic. Another thing that LLMs are

quite good at is

uh code searching. Obviously, I think

that's their greatest strength,

actually.

And part of reading code faster is not

only making sure that you do deliberate

practice to read code

every now and then,

but also to be consciously aware of how

concepts are chunked together. So, when

you're looking at a function and its

name is something like process and it

has 50 lines, you can't chunk that

function. You have to read the function

body to understand what it does.

But if you give that function a a good

name

and it does what it says it does,

then you can

effectively chunk that piece of code

into one small thing, which means that

your short-term memory can hold more.

Whereas, if you had to read over the

function body and you had to remember

there's a variable called user on line

13 and then that user is passed into a a

for loop and then we're checking the

properties of that user, blah blah blah

blah.

This is a lot for your your your mind to

hold one time. Whereas, if you just have

the function is called enumerate user

pictures or picture links or something

like whatever. It doesn't have to be

anything in particular.

It tells you what it's doing, so that

you don't have to hold things in your

brain. You just have to hold that

function name and that's it. That might

seem like something that's sort of

contrived, but when you're trying to

debug many things uh uh like a trace a

path through a code base and trying to

debug.

It's the kind of thing where it gives

you a small amount of cognitive capacity

back so that you can actually debug that

problem without getting super

overloaded. Uh anyhow, I went to the

website of the author and I found this

kind of graphic

um that's about the book and sort of

summarizes it.

But, I would highly recommend buying

this book. I I prefer physical copies.

Um

but I actually have just the audiobook.

When I listened to the audio audiobook,

it took me probably 10 listens.

I used to listen to it while driving in

my car, but after a certain amount of

time I started to absorb uh that

information. I think reading would

probably be better.

But, you can head to the author's

website, um see this graphic, see what

it's about. So, yeah, in summary, why

should you buy this book? For me

personally, it was one of the more

engaging books in my career, maybe

because it was an audiobook, I'm not

sure, but

I recommended this book to some of my

colleagues as well and they found it

quite interesting. Um it basically

gave me a good understanding of how my

brain works, but also an understanding

of how other people's brains work in the

exact same way so that when I'm writing

code or making some kind of a system, I

have to understand that when people are

exposed to this new code base or new

system, that they don't have all of the

pieces in their long-term memory,

whereas as someone who built it,

I was able to develop a mental model as

time went on

and slowly store that into my long-term

memory. So, I have this

advantage and perhaps curse of knowledge

where it appears like everything is

really super easy,

but for the person who just joined my

team, everything is really hard and

really complicated. So, it's about

respecting that human limitation

and and thinking about how can I shape

things so that they play nice with this

new developers

working memory and short-term memory.

How can I structure my code base in a

way where they can easily search and

[snorts] hold individual pieces like

functions and modules in their

short-term memory and to slowly allow

them to build up that long-term memory

of the system. So, that when they go and

need to add a feature or debug

something,

they're not

completely overloaded uh because once

your working memory fills up, you

basically have this experience where you

just cannot think anymore. It's like it

just it's impossible and it makes you

feel stupid, but you're not stupid. You

just you're trying to solve something

with limited capacity and as humans,

that's

that's what we have to deal with.

So, that is why I would recommend that

book because I believe it's going to

give you that understanding of yourself

and that's also going to help you and

your colleagues. So, if you want to buy

that book, I've placed

an Amazon link in the description. That

is an affiliate link where I will get

paid a 2% commission.

Uh just so that you're aware,

but I am genuinely recommending that

book

uh because it's helped me and I found it

interesting.

Anyhow,

that is my review.

I'll be doing another one on uh another

book which is actually called A

Philosophy of Software Design.

I'll upload that uh shortly.

Thanks. See you.