
Code is Read
What separates code that teams maintain with confidence from code that becomes an unmaintainable legacy burden? Chris is joined by Daniel Schreifler — developer, consultant, and author of 10 Days to Become a Better Developer — to explore why readability is the most foundational quality in software.
The central argument: every act of development ultimately requires changing code, and you cannot change code you cannot understand. Therefore, the prerequisite for the most common activity in software development is the ability to read the code — making readability a first-class engineering concern, not an aesthetic preference.
Topics covered include:
- Cognitive load and “wet RAM” — why humans can hold only ~5–7 distinct facts in working memory at once, and what that means for naming, nesting, and method size
- The early-exit pattern — how returning or erroring early reduces the cognitive burden of tracking multiple conditions, with Go’s idiomatic error-handling as a worked example
- Descriptive vs intentional naming — the difference between a variable name that describes what a value is and one that captures why you computed it (e.g.,
shouldFlagForCreditLimitExceptionvsinvoiceTotal > 1000) - Domain-driven naming — using the language of the business domain in class and method names so code communicates intent to both developers and stakeholders
- Inner sourcing — why readable code is a prerequisite for teams sharing code across an organisation, and how unreadable codebases block contribution before a single line is changed
- TDD and Given/When/Then test naming — how readable tests build trust with non-technical stakeholders and serve as living documentation of acceptance criteria
- Psychological safety and evolutionary change — using coaching, pull request suggestions, and small experiments rather than mandates to move a team towards more readable habits
- The book: 10 Days to Become a Better Developer — a series of 30-minute exercises covering time management, intentional learning, team communication, and coding practices
Related Content

ToolUp Tuesday - #5
Chris and Matt refactor their Go player decisions API, restructuring packages and project layout. They compare the Gin and Gorilla Mux HTTP frameworks, explore Go interfaces and dependency injection patterns, and discuss unit testing and mocking strategies in Go.

ToolUp Tuesday - #3
Chris and Matt build the world events engine in .NET, connecting it to the Player State models via project references. They design a state machine architecture for the game engine, discuss action points as a game mechanic, and plan the player decisions API in Go for the next episode.

ToolUp Tuesday - #6
Chris and Matt wire up Dapr state management for their .NET player state service, configure VS Code debugging for multi-service development, and document game use cases covering player enrollment, world event ticks, and decision lifecycle.