My fifth book, Computer Science from Scratch: Building Interpreters, Art, Emulators, and ML in Python was recently published by No Starch Press. It’s a great book for intermediate or advanced Python programmers who have some gaps in their CS knowledge and want to learn from a code-centric, project-focused approach. It includes seven fun, educational projects like building a BASIC interpreter and an NES emulator. You can learn more about the book itself on computersciencefromscratch.com. In this post I’m going to tell you about the development process. Everything from selecting the topics, to writing the manuscript, finding a publisher, and getting it through to the finish line is covered here.
My most successful prior book was Classic Computer Science Problems in Python which was published by Manning in 2019. That book sold tens of thousands of copies around the world and was translated into eight different languages. I think it hit a gap in the market. There were many great introductory books in Python. There were not many great intermediate books in Python. It was designed for people who already knew Python and wanted to learn some ideas from the world of computer science. It covered some data structures and algorithms topics like graph algorithms and several topics from the world of artificial intelligence like adversarial search and neural networks. All of the topics came with fully working code built from scratch in Python with no external libraries.
After Classic Computer Science Problems in Java was published (my 4th book), I thought, “Do I have anything new to say?” I realized I did. I had accumulated interesting personal projects and projects that I used while teaching CS in a college setting that would make a nice compilation of introductory material to other realms in CS. They were less about classic algorithms than the Classic Computer Science Problems series and more about the layers of the software stack. I also thought I should build on my success with a previous intermediate Python book. So, what was originally titled Fun Computer Science Projects in Python, was born. It would be for the same general audience as Classic Computer Science Problems in Python but would have no direct content overlap. It would feature larger, more fun, projects. Eventually, before release, the publisher, No Starch Press, came up with a better title: Computer Science from Scratch. How does a programming language work? How does a computer interpret instructions? These are the kinds of questions I want to answer for my intermediate Python readers.
I started writing Computer Science from Scratch four-and-a-half years before it was published. Before I wrote any of the text, I started writing the code for several of the book’s projects. As I mentioned, I adapted projects from my college teaching career or personal projects for many of them. Most of the projects were not originally written in Python, so I found myself porting them and cleaning them up.
For example, I taught a class called Emerging Languages at Champlain College in which we used modern languages like Go, Swift, and Clojure as a lens to teach some programming language theory. One of the projects was building a Brainfuck interpreter in Clojure. Another was building a Tiny BASIC interpreter in Swift. I ported those projects to Python to create Part I: Interpreters.
One project in the book actually went the other direction. Chapter 3 is about building a program called Retro Dither that can take modern photographs, dither them so they look okay in black and white, and convert them to MacPaint format for display on a 1980s black & white Mac. Along the way you learn about dithering algorithms, file formats, and run-length encoding. I actually ended up porting that program from Python to Swift and releasing it on the Mac App Store. I wrote a blog post back in 2021 about that process as I was writing the book.
Chapter 4 is also connected to Swift. About a decade ago I became very enamored with Michael Fogleman’s Primitive project that turns photos into abstract vector art. I ended up writing an iOS app that does the same thing using a simpler algorithm of my own design. That program got ported to Python as Impressionist for Chapter 4 of the book. I think it’s amazing how cool some of the abstract art comes out. You’d think something sophisticated like a neural network must be behind it, but really it’s just some stochastic hill climbing.
Chapters 5 and 6 are projects from the world of emulation. Writing an emulator really helps you understand the hardware/software interface and how computers work at a lower level. You certainly learn something about instruction sets and computer architecture. I had been writing emulators in Swift, C, & C++ out of personal interest over the past decade. I ended up porting two of those projects, a CHIP–8 VM and an NES emulator, to Python for the book. Before porting the NES emulator to Python, I rewrote my C version with the simplest possible Picture Processing Unit (PPU) implementation since graphics were what really tripped me up when I was learning to write an NES emulator myself. It’s not super compatible, but its simplicity helps you understand what’s going on at a high level. I think the NES emulator chapter is the crown jewel of the book (it’s also the longest and hardest). To my knowledge, Computer Science from Scratch is the first book to cover how to write an NES emulator, although of course there are tutorials (of varying quality) online. By writing it in Python we make this popular hobbyist programming project accessible to a wider audience. However, it also means we don’t achieve full 60 FPS performance. We leave using Cython or something like it to achieve full performance as an exercise for the reader.
I will admit that I didn’t originally intend the last two chapters (7 & 8) on introductory machine learning using the KNN algorithm for the book. But as I was shopping the book around to publishers (I come up with all my book ideas myself and then shop them to publishers) it was suggested to me that any book introducing a reader today to the world of CS should have at least a little machine learning content. Actually even my book Classic Computer Science Problems in Swift from 2017 had two chapters in this vein (one on K-Means and one on neural networks). Luckily I had been teaching introductory artificial intelligence at the undergraduate level for the past few years and already had the perfect introductory ML project in mind. The code for naive KNN is basically trivial but it did save me some time to already know the project around it was pedagogically sound from having used it in the classroom. Like Impressionist from Chapter 4 it’s amazing that an algorithm as simple as KNN can get as great results as it does in these chapters, achieving 98% accuracy at classifying handwritten digits on a classic dataset.
I approached getting a deal for the book in what is generally an unusual way in the world of technical publishing. Instead of writing some of the book and getting a publisher on board before finishing it, I finished an entire first draft of the book and then shopped it around. Ultimately I had two offers. One from a very large, highly respected academic and trade publisher, and the other from No Starch Press. The very large publisher seemed as interested in me doing a video series about the book as in the book itself. No Starch Press, being much smaller and much more niche, was on the other end of the spectrum. They didn’t want video at all, just the book. Plus their royalty deal was better, I liked some of their prior books, and they were the best-selling publisher in the world of Python. So I went with them.
These shopping around processes can be intense. Some publishers take weeks or even months to get back to you. Unfortunately, I didn’t get to hear back from all of the publishers that were still considering the book and had to pull out of a couple of the processes to make a decision on time for the two that had already made offers. I also received a couple rejections. One niche technical publisher turned down the book because the first project, Brainfuck, has the F word in it. Hey I didn’t name the language… that’s just what the programming language is called! Another, very well known programming book publisher said they were interested but only if I would add LLM prompting content to each chapter. I had no interest in that as I thought it would get stale quickly.
I said I started working on the book four-and-a-half years before it was published. While that’s true, the whole book was actually written in several short bursts of activity for a couple months at a time. I’m a pretty fast writer. In fact my manuscript was done in July 2024 when I was shopping it around to publishers. It took over another year to get it out. That’s just what the publishing process with traditional publishers takes. A lot of that work was converting from markdown to Word templates, development editing, technical review, copyediting, making an index, and final layout. Tedious work that sometimes feels like busy work. Much of it done by the publisher with a ton of back-and-forth with the author. I will say the development editing on this book was particularly fruitful. My development editor, Nathan Heidelberger, really improved the book by taking the perspective of an intermediate Python programmer himself. Also thanks to technical reviewer Michael Kennedy of Talk Python fame who had some good technical catches.
Now that it’s done would I do anything differently? Well, I’m very satisfied with the result. I wrote every line of code and every word in the book by hand. I didn’t use any LLMs. In fact, widespread LLMs didn’t exist when I started the book. Of course it could have been written much faster if I started using one as the book progressed, but I think it wouldn’t have sounded as authentic if it had been. And I think authenticity in writing still comes through and connects with people. Another issue is that I considered self-publishing. I may still do that on a future book, but I ultimately decided against it for a few reasons: the legitimacy that comes from a traditional publisher vetting it (at least in my circles working in higher ed), the marketing power of a traditional publisher, and the style choices they would help with. Ultimately I think those style choices did make a difference: I like the title they came up with, the cover they came up with, and the stylistic changes the development editor suggested. But working with a traditional publisher also comes with a lot of bureaucracy, nitpicking, and giving up the majority of the profits from the book. You lose full control. So it’s a tradeoff for sure and not a clear cut decision even if you are fortunate enough to have an offer for a book deal.
If you read this far and you are an intermediate or advanced Python programmer please check out the book! It’s available now from Amazon, No Starch Press, and you can learn more about it on the website I created for it.