Thorsten Ball is a distinguished software engineer, author, and educator renowned for demystifying the internals of programming languages through his "Monkey" series. Over a decade of professional experience at companies like Sourcegraph and Zed, he has synthesized a philosophy of "recreational programming" and "romanticism" that champions simplicity, fearlessness, and deep technical curiosity.

Part 1: The Philosophy of Engineering & Romanticism

  1. On Romanticism: "There is a lot of romanticism in computing because there is a lot of irrationality. Irrationality is as much an engine of progress as reason." — Source:
  2. On Fearlessness: "Becoming fearless yourself is one of the best learning accelerators I've found. Dive into an unknown codebase or open a dependency without fear." — Source:
  3. On Code Malleability: "Code isn't chiseled in stone. It's malleable. It's written on a blackboard and you always have a sponge in hand to wipe it all off." — Source:
  4. On Writing 'Stupid' Code: "Ask yourself: 'Is this code stupid enough?' Stupid code is code that works exactly as intended in the most simple, straightforward way possible." — Source:
  5. On Elegance: "Starting with 'write stupid code' is more likely to lead to an elegant solution than trying to achieve elegance directly." — Source:
  6. On Renewal: "Every line you write or change is a fresh shot to write something great, regardless of the technical debt that came before." — Source:
  7. On Perfectionism: "Perfectionism is based on a lie. Accept that there is no perfect, ship it, and continue building." — Source:
  8. On the Joy of Building: "Programming is like playing Lego without gravity." — Source:
  9. On Being Romantic: "How can you not be romantic about programming?" — Source:
  10. On Success Despite Flaws: "I've learned to appreciate programs that succeed and provide value despite their internal flaws and technical debt." — Source:

Part 2: Compilers, Interpreters, and Language Internals

  1. On Learning by Building: "The best way to understand how a programming language works is to build one from scratch, starting with zero lines of code." — Source:
  2. On Pratt Parsing: "Pratt parsing is a powerful technique for handling operator precedence in a way that remains readable and easy to implement." — Source:
  3. On Tree-Walking Evaluators: "A tree-walking evaluator is the most direct way to turn an Abstract Syntax Tree (AST) into a working program." — Source:
  4. On Lexing: "A lexer's job is to take source code and turn it into a stream of tokens that the parser can understand." — Source:
  5. On Bytecode: "Bytecode is the bridge between high-level language constructs and the raw execution speed of a virtual machine." — Source:
  6. On Virtual Machines: "Building a stack-based VM provides a deep look at machine code, opcodes, and how functions are actually executed on a CPU." — Source:
  7. On the REPL: "A Read-Eval-Print Loop (REPL) is not just a tool; it’s the heartbeat of an interactive programming experience." — Source:
  8. On Compiler Performance: "A compiled language with a VM is often significantly faster than a tree-walking interpreter because it minimizes the overhead of traversing the AST." — Source:
  9. On Self-Sufficiency: "Avoid third-party libraries when learning language internals; you want to see every gear turn." — Source:
  10. On Symbol Tables: "The symbol table is the brain of your compiler, keeping track of where every variable and function lives in memory." — Source:

Part 3: The Craft of Software Engineering

  1. On Code Mass: "Code has mass. Every additional line of code you don't need is ballast that weighs your codebase down." — Source:
  2. On Confidence-Inspiring Tests: "Write tests that give you confidence that the system works as it should. Don't fight over whether they are 'unit' or 'integration' tests." — Source:
  3. On Fast Feedback: "Ideally, your tests should run with 3 keystrokes and in less than 1 second." — Source:
  4. On Deleting Code: "The less code you need, the better. If you’re unsure, delete it; you can always restore it from version control." — Source:
  5. On Shipping and Maintenance: "Code needs to be read, tested, kept compatible, secure, and working. It’s an ongoing cost, not just a one-time build." — Source:
  6. On Building for Now: "We don't know the future. Build what we know we need right now rather than building for possibilities that may never happen." — Source:
  7. On Rolling Up Sleeves: "The most important trait in developers is rolling up their sleeves because a task has to get done, even if it's not glamorous." — Source:
  8. On Working in Public: "Demonstrating competence through published work and open-source contributions is a powerful way to differentiate yourself." — Source:
  9. On Documentation: "Learn to write well because communication is just as important as the code itself." — Source:
  10. On Abstractions: "Know at least one level of abstraction beneath the one you usually work in." — Source:

Part 4: The Go Programming Language

  1. On Go's Simplicity: "Go is a great choice for implementing interpreters because its simplicity lets you focus on the language you're building, not the quirks of the host language." — Source:
  2. On the Standard Library: "Go's standard library provides almost everything you need to build a compiler without reaching for external dependencies." — Source:
  3. On Pragmatism: "Go is a tool for people who want to get things done without the overhead of complex type systems." — Source:
  4. On Concurrency: "Go's concurrency model (goroutines and channels) makes it natural to think about parallel execution from the start." — Source:
  5. On Interfaces: "Interfaces in Go are powerful because they are satisfied implicitly, encouraging decoupled and testable code." — Source:
  6. On Readability: "Go code is often criticized for being verbose, but that verbosity makes it incredibly easy to read and understand months later." — Source:
  7. On Performance vs. Productivity: "Go strikes a rare balance: it’s fast enough for systems work but simple enough for rapid web development." — Source:
  8. On Tooling: "The `go fmt` tool ended the debate over code style, allowing teams to focus on the logic of their software." — Source:
  9. On Composition: "Composition over inheritance is a core tenet of Go that prevents the complex class hierarchies found in other languages." — Source:
  10. On Error Handling: "Explicit error handling in Go forces you to think about what could go wrong at the moment it happens." — Source:

Part 5: Career Development & The First 10 Years

  1. On Long-term Collaboration: "Nothing helped me improve as much as working with the same group of people on the same codebase over multiple years." — Source:
  2. On Seniority: "Seniority is seeing how your decisions play out three years later when a colleague tries to modify your code." — Source:
  3. On Company Types: "There is a massive difference between a software company and a company that just happens to employ developers." — Source:
  4. On Winging It: "I don't think any company has it all figured out. Everybody's winging it to some degree." — Source:
  5. On Professional Growth: "I feel like I signed a contract when I started as an engineer: you'll need to always be learning." — Source:
  6. On the First Decade: "The first ten years are about moving from 'how' to 'why' and understanding the trade-offs of every decision." — Source:
  7. On Self-Education: "You don't need a CS degree to understand systems programming; you just need curiosity and the willingness to dive deep." — Source:
  8. On Career Shifts: "The transition from music to software was driven by the realization that I loved the act of building as much as the act of creating sound." — Source:
  9. On Differentiation: "The best way to differentiate yourself as a junior is to show, not tell—build something and write about it." — Source:
  10. On Job Satisfaction: "It's a joy to work for a company in which leadership 'gets' software and how it's actually made." — Source:

Part 6: Engineering Management & Leadership

  1. On Coding Managers: "Managers should know how to code to understand the technical constraints and the reality of the work their teams do." — Source:
  2. On Product vs. Engineering: "Product and engineering should be partners in solving user problems, not separate entities throwing requirements over a wall." — Source:
  3. On Organizational Effectiveness: "Large organizations often squander effort despite having massive resources; the goal is to keep effectiveness high." — Source:
  4. On Technical Leadership: "A Staff Engineer's role is often about finding the 'glue' work that keeps the project moving but isn't always visible." — Source:
  5. On Remote Leadership: "Remote leadership requires intentional communication and creating spaces where people feel safe to share their progress and failures." — Source:
  6. On Hiring: "Hire people who are not just skilled, but curious. Curiosity is the engine that drives them to solve the hard problems." — Source:
  7. On Decision Making: "In management, you're often making decisions with 60% of the information; you have to be comfortable with that uncertainty." — Source:
  8. On Coolness in Education: "We need to make computer science 'cool' again to attract the next generation of creative builders." — Source:
  9. On Mentorship: "Good mentorship isn't about giving the answer; it's about helping the other person find the right mental model." — Source:
  10. On Team Momentum: "A manager's job is to protect the team's momentum by removing friction and clarifying priorities." — Source:

Part 7: AI, Coding Agents, & The Future

  1. On the Scarcity of Code: "The most fundamental constant of software industry has changed: the scarcity of code. Code is no longer hard-to-extract oil; it's rainwater." — Source:
  2. On Implementation Constraints: "When coding becomes cheap, implementation stops being the primary constraint for software products." — Source:
  3. On AI Curiosity: "I don't understand how you can be a programmer in 2024 and not be the tiniest bit curious about LLMs." — Source:
  4. On AI Beauty: "I started to find beauty in AI as I understood the underlying mechanisms; it's not just a slot machine." — Source:
  5. On Autonomous Agents: "In the future, a lot of code will be written while nobody is watching." — Source:
  6. On Agentic Programming: "We are moving from writing code ourselves to managing agents that write the code for us." — Source:
  7. On the Death of 'Old Software': "The old software we knew is dead—not gone, but its era has ended, much like rock & roll is 'dead'." — Source:
  8. On Decoupling for Agents: "To make code accessible to AI agents, we must decouple logic in ways that allow the agent to understand small, isolated parts." — Source:
  9. On LLMs as Tools: "LLMs are not just another developer tool; they are a fundamental shift in how we interact with computers." — Source:
  10. On Finding Your Pain: "AI tools should be used to find and automate 'your pain'—the parts of development that feel like a slog." — Source:

Part 8: Productivity, Focus, & Tools

  1. On Momentum: "Momentum isn't something that just happens; it's something you consciously create by starting with small, achievable tasks." — Source:
  2. On the Typing Bottleneck: "Typing can be the bottleneck. Proficiency in typing reduces friction between thought and code." — Source:
  3. On Presentations: "Tell the audience what problem is being fixed and why you did what you did. Keep it shorter than you think." — Source:
  4. On Organizing Work: "Organize your work to allow for continuous satisfaction of checking off todo items." — Source:
  5. On Screencasts: "Avoid visual distractions in screen recordings; call out the details that actually matter." — Source:
  6. On the Cost of Context Switching: "Deep work requires long blocks of uninterrupted time; protect your calendar aggressively." — Source:
  7. On Productivity Hacks: "There are no silver bullets for productivity; there is only finding a system that works for your specific brain." — Source:
  8. On Terminal Mastery: "Mastering your terminal and your editor is like a musician mastering their instrument; it makes the tool disappear." — Source:
  9. On REPL-Driven Development: "A REPL allows for a feedback loop so tight that you can experiment and learn at the speed of thought." — Source:
  10. On shipping 80%: "Aim for 80% and consider the other 20% optional. The last 20% is where most of the delay happens." — Source:

Part 9: Learning, Curiosity, & Education

  1. On Continuous Learning: "The industry moves so fast that standing still is effectively moving backward." — Source:
  2. On Recreational Programming: "I love 'recreational programming'—solving puzzles and building tools just for the sake of understanding." — Source:
  3. On Learning New Languages: "Learn more programming languages, even if you won't use them at work. They change how you think about code." — Source:
  4. On Bugs as Benefits: "Bugs are not just errors; they are signals that your mental model of the system is incorrect." — Source:
  5. On CS Fundamentals: "You don't need to know everything about CS, but knowing how the stack, heap, and memory work will make you a better dev in any language." — Source:
  6. On Self-Correction: "Be willing to unlearn things. Some practices that were 'best' five years ago might be 'worst' today." — Source:
  7. On the 'Why': "Don't just copy-paste solutions; understand the 'why' behind the implementation." — Source:
  8. On Staying Curious: "Curiosity is the only thing that keeps the job from becoming a slog after ten years." — Source:
  9. On Systems Thinking: "The best engineers understand how their code fits into the larger system, from the UI down to the kernel." — Source:
  10. On Failure: "Persistence in the face of failure is the most important skill in debugging." — Source:

Part 10: Writing, Blogging, & Public Work

  1. On Thinking by Writing: "Writing is thinking. I like sitting down and ordering my thoughts in order to write something." — Source:
  2. On Blogging as a CV: "I started blogging to show what I could do as a junior; it's a living resume." — Source:
  3. On the 'Register Spill' Newsletter: "The newsletter is a way to share the 'Joy & Curiosity' I find in the industry every week." — Source:
  4. On Sending It: "Don't be a perfectionist with your writing. Just send it. Don't pretend to be someone you're not." — Source:
  5. On Writing Discipline: "Setting a time limit—like 60 minutes every Sunday—helps maintain consistency without burnout." — Source:
  6. On Sharing Pride: "Blogging should be about sharing things you are genuinely proud of building." — Source:
  7. On Technical Communication: "If you can't explain a complex topic simply, you probably don't understand it well enough yet." — Source:
  8. On Public Feedback: "Writing in public invites corrections and conversations that accelerate your own learning." — Source:
  9. On the Impact of Writing: "Books and blog posts have a much longer shelf life than the features you ship at work." — Source:
  10. On Purpose: "The goal of writing about software is to help others find the same joy and curiosity that kept you in the field." — Source: