book

The Programmer's Brain

by Felienne Hermans

September 2021

Intermediate to advanced

256 pages

8h 1m

English

Manning Publications

Read now

Unlock full access

forewordprefaceacknowledgmentsabout this bookHow this book is organized: A roadmapliveBook discussion forumabout the authorabout the cover illustration
1.1 Different kinds of confusion in code1.1.1 Confusion type 1: Lack of knowledge1.1.2 Confusion type 2: Lack of information1.1.3 Confusion type 3: Lack of processing power1.2 Different cognitive processes that affect coding1.2.1 LTM and programming1.2.2 STM and programming1.2.3 Working memory and programming1.3 Cognitive processes in collaboration1.3.1 A brief dissection of how the cognitive processes interacted1.3.2 Cognitive processes regarding programming tasksSummary
2.1 Quickly reading code2.1.1 What just happened in your brain?2.1.2 Reexamine your reproduction2.1.3 Reexamining your second attempt at reproducing code2.1.4 Why is reading unfamiliar code hard?2.2 Overcoming size limits in your memory2.2.1 The power of chunking2.2.2 Expert programmers can remember code better than beginners2.3 You see more code than you can read2.3.1 Iconic memory2.3.2 It’s not what you remember; it’s the way you remember it2.3.3 Practice chunkingSummary
3.1 Tips for remembering syntax3.1.1 Disruptions play havoc with your workflow3.2 How to learn syntax quickly with flashcards3.2.1 When to use the flashcards3.2.2 Expanding the set of flashcards3.2.3 Thinning the set of flashcards3.3 How to not forget things3.3.1 Why do we forget memories?3.3.2 Spaced repetition3.4 How to remember syntax longer3.4.1 Two forms of remembering information3.4.2 Just seeing information is not enough3.4.3 Remembering information strengthens memories3.4.4 Strengthen memories by actively thinkingSummary
4.1 Why it’s hard to understand complex code4.1.1 What’s the difference between working memory and STM?4.1.2 Types of cognitive load as they relate to programming4.2 Techniques to reduce cognitive load4.2.1 Refactoring4.2.2 Replacing unfamiliar language constructs4.2.3 Code synonyms are great additions to a flashcard deck4.3 Memory aids to use when your working memory is overloaded4.3.1 Creating a dependency graph4.3.2 Using a state table4.3.3 Combining dependency graphs and state tablesSummary

5.1 Roles of variables framework5.1.1 Different variables do different things5.1.2 Eleven roles to cover almost all variables5.2 Roles and paradigms5.2.1 Benefits of roles5.2.2 Hungarian notation5.3 Gaining a deeper knowledge of programs5.3.1 Text knowledge vs. plan knowledge5.3.2 Different stages of program understanding5.4 Reading text is similar to reading code5.4.1 What happens in the brain when we read code?5.4.2 If you can learn French, you can learn Python5.5 Text comprehension strategies applied to code5.5.1 Activating prior knowledge5.5.2 Monitoring5.5.3 Determining the importance of different lines of code5.5.4 Inferring the meaning of variable names5.5.5 Visualizing5.5.6 Questioning5.5.7 Summarizing codeSummary
6.1 Using models to think about code6.1.1 The benefits of using models6.2 Mental models6.2.1 Examining mental models in detail6.2.2 Learning new mental models6.2.3 How to use mental models efficiently when thinking about code6.3 Notional machines6.3.1 What is a notional machine?6.3.2 Examples of notional machines6.3.3 Different levels of notional machines6.4 Notional machines and language6.4.1 Expanding sets of notional machines6.4.2 Different notional machines can create conflicting mental models6.5 Notional machines and schemata6.5.1 Why schemata matters6.5.2 Are notional machines semantics?Summary
7.1 Why learning a second programming language is easier than learning the first one7.1.1 How to increase the chances of benefiting from existing programming knowledge7.1.2 Different forms of transfer7.1.3 Already knowing something: Curse or blessing?7.1.4 The difficulties of transfer7.2 Misconceptions: Bugs in thinking7.2.1 Debugging misconceptions with conceptual change7.2.2 Suppressing misconceptions7.2.3 Misconceptions about programming languages7.2.4 Preventing misconceptions while learning a new programming language7.2.5 Diagnosing misconceptions in a new codebaseSummary
8.1 Why naming matters8.1.1 Why naming matters8.1.2 Different perspectives on naming8.1.3 Initial naming practices have a lasting impact8.2 Cognitive aspects of naming8.2.1 Formatting names supports your STM8.2.2 Clear names help your LTM8.2.3 Variable names can contain different types of information to help you understand them8.2.4 When to evaluate the quality of names8.3 What types of names are easier to understand?8.3.1. To abbreviate or not to abbreviate?8.3.2 Snake case or camel case?8.4 The influence of names on bugs8.4.1 Code with bad names has more bugs8.5 How to choose better names8.5.1 Name molds8.5.2 Feitelson’s three-step model for better variable namesSummary
9.1 Why code with code smells creates a lot of cognitive load9.1.1 A brief intro to code smells9.1.2 How code smells harm cognition9.2 The influence of bad names on cognitive load9.2.1 Linguistic antipatterns9.2.2 Measuring cognitive load9.2.3 Linguistic antipatterns and cognitive load9.2.4 Why linguistic antipatterns cause confusionSummary
10.1 What is problem solving?10.1.1 Elements of problem solving10.1.2 State space10.2 What is the role of the LTM when you solve programming problems?10.2.1 Is problem solving a cognitive process on its own?10.2.2 How to teach your LTM to solve problems10.2.3 Two types of memories that play a role in problem solving10.3 Automatization: Creating implicit memories10.3.1 Implicit memories over time10.3.2 Why automatization will make you program quicker10.3.3 Improving implicit memories10.4 Learning from code and its explanation10.4.1 A new type of cognitive load: Germane load10.4.2 Using worked examples in your working lifeSummary
11.1 Different activities while programming11.1.1 Searching11.1.2 Comprehension11.1.3 Transcription11.1.4 Incrementation11.1.5 Exploration11.1.6 What about debugging?11.2 Programmer interrupted11.2.1 Programming tasks require a warm-up11.2.2 What happens after an interruption?11.2.3 How to better prepare for interruptions11.2.4 When to interrupt a programmer11.2.5 Some thoughts on multitaskingSummary
12.1 Examining the properties of codebases12.1.1 Cognitive dimensions12.1.2 Using CDCB to improve your codebase12.1.3 Design maneuvers and their trade-offs12.2 Dimensions and activities12.2.1 Impact of dimensions on different activities12.2.2 Optimizing your codebase for expected activitiesSummary
13.1 Issues in the onboarding process13.2 Differences between experts and novices13.2.1 Beginners’ behavior in more depth13.2.2 Difference between seeing concepts concretely and abstractly13.3 Activities for a better onboarding process13.3.1 Limit tasks to one programming activity13.3.2 Support the memory of the onboardee13.3.3 Read code togetherSummary
Some words to close this book

Content preview from The Programmer's Brain

12 Designing and improving larger systems

This chapter covers

Examining what effect different design decisions have on the understandability of codebases
Exploring trade-offs between different design decisions
Improving the design of existing codebases for better cognitive processing

So far in this book, we have discussed how to best read and write code. To do so, we have examined how cognitive processes play a role when reading and writing code. For larger codebases, however, it is not just small parts of code that influence how easy it is for people to comprehend it. The way in which you organize code also greatly influences how easily other people can interact with the code. This is especially true for code in libraries, frameworks, and ...