Reflections on 8 months and 66 thousand words

Starting on October 1, 2025, I have worked, with decent consistency, on School of E (schoolofe(dot)org). It’s a collection of lectures written entirely by me, in the form of a website, on subjects that, in my opinion, make computer systems engineers¹ what they are from first principles.

Fast forward eight months and there are more than sixty-six thousand words written down (in around twenty lectures). Leaving aside graphics, formulas, and code snippets, and not remarking that it’s approximately the number of words that goes in a novel of fiction (if I ever write one), nor mentioning that the website is, at this time, not live yet — in other words, despite the strikingly unfinished nature of the site — I feel like it’s a good time to pause for some reflections and lessons learned from this bulk of work.

Let me start with the obvious.

Technical writing is demanding. I mean it in a physical sense: it’s exhausting. In nontechnical pieces, it feels as though it’s OK when some interpretation is left to the reader. Just look again at the previous sentence: it’s anything but scientific. In a technical text, on the other hand, just like in computer code, I wish readers (learners) didn’t need to interpret the paragraphs, because I want each sentence to have one, and only one, meaning: the correct one.

As an almost direct consequence of this, the weight and impact of every grammatical typos are amplified. I know very well because, no matter how many times I proofread them, my lectures do (and will) contain typos. Just imagine: a guy sitting in his living room typing away sixty-six thousand words in a few months, with nobody else checking on it. Oh, and American English is not that guy’s first language either. I try my best, checking and double checking, but, as it’s often the case, it will take time (and more re-reading) before my best is enough. Unfortunately, even the simplest typos, like an extra ‘s’ that makes a single bit become a few bits, can lead to miscommunications in technical (scientific) writing.

What’s more interesting, to me, is how the static act of sitting down for a few hours and typing on a keyboard can be physically demanding. I believe that I don’t ever feel like that while writing computer code². I have, unfortunately, little-to-none experience with writing educational text with a learners-first approach, therefore I attribute this “fatigue” to the lack of practice.

The next two thoughts are somewhat less obvious.

Too many books are written to satisfy the ego of the writer. I have also written this in a lecture, or two; if you’ve read those, forgive me for repeating myself. I never intended to write a book about the subjects of the lectures; what use would it be? First, it would take such a long time for me to write it, and for you to read it, that by then you’d have (hopefully) moved on to something more productive. Second, there are many good books out there, and plenty of horrible books. I know the former ones, because they are the classics, those I learned from during college. I was, perhaps, fortunate enough to have professors who didn’t need to push their own books, and instead had us go with the timeless classics³. I am also familiar with the second group of books, the horrible ones, because every now and again I purchase one out of curiosity, and I keep riffling through the pages while hoping to find something useful. To be sure, everyone has a different spin on any subject, and everybody may legitimately add something new to it, or simply have a different way of explaining that subject. A certain author’s writing may resonate more to some learners than some other authors’. I think that of myself too (shamelessly), because I’ve been told by coworkers that my occasional explanations of engineering concepts are good.

On the other hand, if a book takes 50% of the pages to show off about some differential calculus results that have been known since the 1800s, or it takes twenty pages to discuss yet another variation of quicksort, then I’ll take one of the timeless books (CLRS in this case, or TAOCP⁴) every day, no matter how “harder” they seem to be, because practice is supposed to be hard. And in a second instance, after the classics, I’ll still take my straight-to-the-point lectures. Despite their typos, and despite their brisk pace.

Which leads me to the next reflection.

Knowledge ought to be breadth-first. That’s why the pace in my lectures is brisk. I think institutions and policy-makers have got this mostly right, at least in the Western world, and as far as I know. We learn a wide variety of things first (elementary and middle school, where I am from), then we take again the same subjects but a bit more in depth (high school) and then, at last, we “specialize” in a subject (university/college). The problem here is that, when we finally come to the last step, some subjects are not “just one subject”, and computer engineering definitely isn’t. So they have us do a third iteration of what we’d done in elementary, middle and high school, but even more in depth. The result is classes such as organic chemistry in a first year of computer engineering. To be sure, knowing about chemistry is great. And forgive me for bragging, but I did get an A+ in that class. The problem is that instead of showing (and, thus, teaching) us the methodologies and the systems behind chemistry, they made us memorize techniques on how to solve a million “reductions” as if they were Sudokus. Techniques are not systematic methodologies. Systems and methods are the core of learning. Techniques and tools aren’t. The result? After that first year class, I haven’t seen a single chemical formula again⁵, and it’s been nearly 20 years of engineering study/practice, and I don’t remember anything about chemistry. That’s my fault, of course, but I can’t help but believe that if I had learned some whys instead of just the hows, then I’d remember some of it.

Breadth-first knowledge is mostly about the whys, and then, time permitting, about the hows. The nice thing about the whys is that they teach in what circumstances an idea applies. In what situations a concept is relevant. And, which is equally useful, when a method is the wrong solution to a problem.

As engineers, we know this mental framework well, and we call it pattern-recognition. It’s perhaps the single most important skill to acquire, and it’s best acquired with a breadth-first approach to learning. First, get yourself familiar with most of what a domain is about. For example, the Poisson distribution can model random arrival of people in a queue. Forget about the exponential and its derivative and its integral! Of course, if you’re working on a PhD thesis in statistics, by all means, close this browser tab and go learn something. But if you aren’t, if you are an engineer and don’t know what problems you will have to solve next month, it’s more productive for you to be able to spot patterns, instead of knowing by heart the product rule of the derivative function.

At the bottom of this reasoning there’s an optimistic assumption. That, after having spotted a pattern, you (and I, hopefully) will be able to go deep into it, and into its technicalities. This ability, of course, comes from a very solid background in foundational subjects (be it calculus for an engineer, or sentences’ analysis for a linguist). That’s why I talk, perhaps too much, about foundational subjects in School of E, and they are the only ones I intend to write (and re-write) about. It may be controversial for some, or maybe you just don’t like to hear it, but here’s the hard truth: learning this tool or that technique won’t give you the same knowledge, and won’t make you as good of an engineer, as learning the methods (although, of course, it will give some knowledge). Yes, I know, I got the prompters among you mad with this bold statement.

In fact, speaking of prompters, now would seem the best time to go on a rant about programmers who learn the new fancy web framework (or, these days, some AI prompting) without knowing what a byte is. But that would be unfair, and, essentially, a mistake. And here’s why.

Learning should be goal-driven. I say “should” because learning for the sake of learning is fun, and if that’s your thing then go ahead, don’t mind me. In fact, I am with you on this one. But it’s important to notice that it isn’t most people’s thing. Therefore, like with many endeavours in life, it’s important to have a plan. There is no plan without a goal; in fact planning starts with a goal. Do you need an example? Let’s take fitness: “I want to (pick one) run a full marathon/lose 15 kg/walk 20K steps in a day”. That’s the goal, assuming that you’re currently not able to do it. With the goal, there comes the plan. The plan is how you go from here to there in so many steps (or weeks, or years).

I am making a point that learning should be goal-driven, which, really, all it means is that there must be a purpose behind the countless hours spent learning. Perhaps your goal is straightforward: to “know everything about a subject”. I respect that (though I would warn you that it’s rarely attainable!). Somebody else’s goal, equally straightforward, may be to “get a paycheck every month for the next twenty years”. There’s, after all, a certain beauty in the practical matters of life, and nothing is more practical than a paycheck.

I will write, on School of E’s welcome page, what’s your goal?, because how you read anything, including my lectures, depends on your goal. How you learn is the plan that will take you to your goal, from where you are today. You may be in a hurry to get a paycheck, and therefore browse the lectures to acquire a superficial knowledge of what things engineers should know; that’s fine, because, frankly, nobody ever questioned me about those things on the job⁶. Superficial knowledge is still useful for pattern recognition. Perhaps you will spend an additional fifteen minutes to make a mindmap of the concepts. Fifteen minutes sounds like a worthy time investment in this instance. Or, perhaps, you are not in a rush and can enjoy the sweet pleasure of timeless, profound ideas. Then you already know what to do.

As for me, one day after fifteen years of practice in enterprise software⁷, I suddenly thought: oh sh*t, have I forgotten the important stuff? That’s when I decided to make the website. My goal is to be the first student of the school.

I have more than sixty-six thousand words on paper (metaphorically), and who knows how many more to write. I will probably have more thoughts after another forty thousand or so.