Ch3nDogg

A Stanford computer science professor has been teaching the same software design class for more than a decade, and every quarter the seats fill faster than almost any other course in the department. Students from Google, Meta, and Apple sneak back onto campus to audit it. Most of them have been writing code professionally for years. I read the book that came out of the class in a week and walked away seeing every codebase I had ever worked on through completely different eyes. His name is John Ousterhout. The book is called A Philosophy of Software Design. Almost everyone in tech eventually hits the same wall. You learn to code. You get good at it. You ship features. 6 months in, you cannot find anything in your own codebase. 12 months in, you are afraid to change things. 2 years in, you start wondering if the problem is you, because everyone around you seems to be drowning at exactly the same depth and nobody is willing to admit it. Ousterhout's argument is that the problem is not you. The problem is that nobody ever taught you what software was supposed to look like. Here is the story almost nobody tells you. Ousterhout was already a legend before he became a teacher. He invented the Tcl programming language, which has been used inside everything from Cisco routers to NASA spacecraft. He built systems companies. He served as a senior fellow at Electric Cloud and as VP of research at Sun Microsystems. By any normal measure he had earned the right to coast. He went back to Stanford instead. The reason he gave in interviews is the part that should make every senior engineer pay attention. He said almost every brilliant engineer he had hired in 30 years of running teams had the same gap. They could implement anything. They could solve any algorithmic problem. They could ship code that compiled, ran, and passed tests. And then 6 months later their own code would start to suffocate them, and they had no idea why. Nobody had ever taught them what good software was supposed to feel like to maintain. Universities taught data structures and algorithms. Bootcamps taught syntax and frameworks. Companies taught company processes. But the actual craft of designing software so that you would not hate yourself in two years was being passed down by accident, in code reviews, by the few senior engineers who had figured it out the hard way. Ousterhout decided to teach it on purpose. He built a class called CS 190 at Stanford, A Philosophy of Software Design. The structure of the class was unusual. Students did not just write code. They wrote code, threw it away, and rewrote it from scratch after detailed feedback. Sometimes 3 rewrites per assignment. The point was not to ship a project. The point was to feel, in your own hands, the difference between a system designed well and a system designed badly. Most students had never felt the difference before. After the class, they could not stop seeing it. He turned the lectures into a small book. It is around 190 pages. The first edition came out in 2018. It costs less than a textbook. It has quietly become one of the most-shared engineering books inside senior teams at Google, Meta, Stripe, OpenAI, and Anthropic. Senior engineers buy copies for their juniors. Tech leads send specific chapters to their teams during code reviews. The argument inside the book is brutally simple. Complexity is the enemy. Not bugs. Not slow performance. Not missed deadlines. Complexity. A system too complex to hold in your head is a system you will break by accident. You will not know which line broke it. You will fix the symptom and miss the cause. Over time, complexity compounds. The codebase becomes a place engineers fear to touch. New features take longer. Old features break for unrelated reasons. Eventually the team starts whispering about a rewrite. The rewrite usually fails for the same reasons the original did. Ousterhout argues that complexity comes from two sources. Dependencies, which are pieces of the system that affect each other across boundaries. And obscurity, which is information about the system that you cannot see from where you are reading. Reduce one, you almost always reduce the other. The deepest insight in the book is about what good modules actually look like. Most engineers are taught to build small, simple modules with lots of small, simple methods. Ousterhout calls these shallow modules and he says they are the disease, not the cure. A shallow module has a small interface and an even smaller body. The interface barely hides anything. To use the module, you have to understand almost everything inside it. Building software out of shallow modules creates the illusion of organization while the actual complexity stays exposed. Good modules are deep. A deep module has a small interface that hides a large amount of functionality inside. You use the module without understanding how it works internally. The interface gives you exactly what you need and nothing else. The complexity is contained. Files have file names, sizes, modification dates. You read and write them. You do not need to know about disk sectors, file allocation tables, or buffering strategies. The Unix file system is a deep module. Most modern abstractions are not. This is the part of the book that makes engineers stop reading and look at their own code with horror. Most production codebases are full of shallow modules disguised as good engineering. Tiny classes. Tiny functions. Long parameter lists. Wrapper layers that wrap other wrapper layers. Every layer leaks information about the layer below it. Every interface forces the caller to understand internals. Engineers wrote it that way because they thought small was good. Ousterhout argues that small is not good. Hidden complexity is good. The module should be doing a lot. The interface should be revealing very little. The second insight that landed hardest for me was about comments. Most engineers are taught that good code does not need comments. The code should be self-documenting. Variable names should be descriptive. Functions should be small enough to read top to bottom. Comments are a sign of failure. Ousterhout argues this is wrong, and that the people who say it have never actually maintained a large system over many years. Comments are not a failure of the code. Comments are how you write down the things the code cannot say. Why a particular approach was chosen. Why a tempting alternative was rejected. What invariants the function depends on. What the caller is supposed to know. None of these things can be expressed in code itself. If a future reader has to read every line of your function to understand what it is doing, you have not finished writing it. The job is not done when the tests pass. The job is done when the next engineer can pick up the file and understand it without asking you a question. The third insight is the one that hit me hardest, because it is the one almost no engineer is taught to think about until it is too late. Strategic versus tactical programming. Most engineers are taught to be tactical. You get a task. You finish the task. You move on. You take the shortest path between the current state of the codebase and the new feature. Each individual decision is reasonable. The combined effect, over years, is a codebase that has been hacked into shape by hundreds of small reasonable decisions, none of which made the system better as a whole. Strategic programming is the discipline of asking, every time you make a change, whether the change is leaving the system better than you found it. Sometimes the smallest task should pay for a refactor that makes the next ten tasks easier. Sometimes the right move is to pause for an hour and redesign the abstraction before you add the feature. Tactical programmers always feel like they are moving fast. Strategic programmers actually move fast. The difference becomes obvious around the two-year mark. Ousterhout's rule is the one I think about almost every day now. The best engineers do not write code faster than bad engineers. They delete code faster. Every line you add to a system is a permanent tax on every future reader. Most of the job of being a senior engineer is deciding what not to write. The book is short. Around 190 pages. You can finish it in a weekend. Reading it once will not make you a better engineer. Reading it twice, then watching yourself catch your own bad habits in real time, then forcing yourself to redesign one module per week using its principles, will measurably change how you write software in less than a year. Almost every engineering team I admire has at least one person who has read this book carefully and has been quietly nudging the rest of the team toward what it teaches. Most teams that do not have someone like this end up rewriting the same system every two years and never understanding why. Ousterhout is still teaching the class at Stanford. The course site is public. The book is around twenty dollars. The single most useful book about how to actually design software is sitting one click away from you. Most engineers will spend a decade learning the hard way what 190 pages would have taught them in a weekend.

South Africa's Exchange Control Regulations of 1961 are rules from the apartheid era. Since then, the US, the UK, France, Spain, Finland, Taiwan, Singapore and many more countries have abolished their exchange controls and prospered. Nelson Mandela explicitly envisioned a South Africa without exchange control regulations. As president, in his 1996 State of the Nation Address, he declared: "In order to improve the investment climate, our monetary authorities are reviewing, on an on-going basis, the timing and pace of lifting existing exchange controls. For us, it is not a matter of whether, but of when, these controls will be phased out." That was thirty years ago. Former Reserve Bank Governor, the late Tito Mboweni, said in 2005, “For all intents and purposes exchange controls have become purposeless." Even Dr Gerhard de Kock, who served as Governor of the South African Reserve Bank during the late apartheid era, said exchange controls "keep more money out than in and work when you don’t need it, and not when you do.” VALR will always abide by the law. And we will work with the regulators to find a framework that works for South Africa. But my sincere wish would be for South Africa to be emancipated from these regulations that were meant for a previous age.

There is a human process in creativity that cannot be prompted away.