Frequently [Occasionally] Asked Questions

More about the author

How can I contact you?

If you purchase a physical copy of the book, you can use the email address listed there to get in touch- the book is free, but the email address requires a purchase 😉. This helps reduce bot scraping and spam.

I’d love to hear your thoughts, though I may not be able to respond to every email.

What is your background as a programmer?

I took a couple classes at the local university while I was in high school, and I was a shockingly bad programmer.

I got my first programming job at 18, working as an intern for a small startup. I learned a lot.

Since then I have worked for four different companies in a variety of roles, mostly doing internal tool development. I like making internal tools: you can get rapid feedback, and interact directly with “customers.” If you’re willing to pay attention, you can learn quite a bit from the experience.

Over my career, I developed a strong interest in the art of programming. I read a lot of books, watched a lot of lectures, and (critically) wrote a lot of code. I took the concepts and approaches that resonated with me, tried to understand why they resonated, and distilled (some) of them into this book.

What are some of the influences on your thinking?

Oh man, there are some great contributors to this industry that I recommend.

I think Miško Hevery’s lectures at Google changed the way I think about programming more than any other influence.

I deeply respect the ideas of Rich Hickey, Dave Thomas, Kevlin Henney, Ryan Dahl, Jonathan Ousterhout, and many others. If you’re not familiar with them, check them out.

I also recommend the following reading material:

Why did you put TEOC online for free?

My main goal is to provide a resource for programmers, not to make money. If it were to make money, writing a book is one of the worst ways for a programmer to do that.

I truly hope that readers find my book helpful, and I’d prefer to reach as wide an audience as possible rather than get a few more sales.

About writing TEOC

Why write a book? Aren’t there enough books on programming?

There’s a lot of good books out there, to be sure. When I would mentor new programmers, though, it was difficult to find a resource I could point to that could concisely and practically explain the critical bits of coding that were likely glossed over during their education.

Most programming books are heavy on theory and light on code. This means that inexperienced developers, even if they agree with the contents of the book, are often unsure how to implement the ideas.

I wanted to create a resource for programmers that not only identified the key goals of good code, but also gave clear and concrete instructions on how to achieve those goals.

What software did you use?

I set unusual requirements for myself that made things harder than for most authors, I think.

I wanted to write the contents once, and then generate the appropriate outputs from that source, including:

The website
A standard 8.5x11 PDF
Multiple PDFs for hardcover and paperback print editions, with configurable margins/gutter depending on the publisher
An EPUB file

I looked at a lot of different options, and in the end used:

Hugo for static site generation, markdown to html, including useful things like shortcodes for custom elements
SASS for styling
A custom Python program that uses playwright and pymupdf to convert the HTML into a PDF and EPUB (multiple formats/sizes and TOC generation, etc)
just for the command runner (so I could run just hardcover and the like)

I may clean up and release the Python program at some point. It proved to be a really useful tool, and I would use it again if I were ever to write another book.

What did you learn from writing a book?

The biggest learning for me what how much of the process is revision and editing.

I initially assumed that writing the rough draft would constitute about 70 percent of the overall effort. In reality, it was closer to 30 percent.

Revising, rewriting, rereading, repeat. Many iterations, first by yourself, and then again when you have beta readers and an editor. The process involved enough critique and practice that it noticeably improved my writing.

Once there is something resembling good content, turning that into a publishable work is another heavy lift. When you self-publish, you take on the work of the publisher: ensuring correct font, good typesetting, layout, margins, etc. Learning how to do that, and then doing it well, was a process in itself.

About the content of TEOC

You left out the most important topic $TOPIC! Why??

Purely to spite you, dear reader.

…In reality, there are a few reasons.
Perhaps that topic is more about design, and this book is about code construction.
Perhaps I couldn’t squeeze it in.
Perhaps I am unaware of that topic.
Or perhaps I didn’t think it was that important- and perhaps I am wrong.

Feel free to shoot me an email about it.

I disagree with you about that one part.

I don’t expect everyone to agree with me about every part, but if you do disagree, I’d love to hear about it (see the question about contacting me).

There’s always more nuance than could possibly be expressed in 130 pages, which means it is certainly possible to find cases where the listed rules are not applicable.

I do strongly believe, though, that the contents of the book are broadly correct and useful.

Which chapter is your favorite? Why?

I like all my chapters equally.

But maybe I like if more equally than the others…

I encountered idea that conditional logic is often used as a stand-in for the language’s type system from a lecture Miško Hevery gave at Google as part of the Clean Code Talks. It was totally novel to me, and I felt that a bunch of things suddenly made sense.

When you see an if statement, and know it could be an indicator of structural problems, you think about the code layout and interactions differently. Even if you decide it’s clearer to leave in the conditional logic, by thinking about it in the context of types, you will have a clearer picture of the code and how it should operate.