MvM & Complexity

reflecting over the past few years

Drafting this entry on the train is one of the first times in 7 years where I’ve put pen to paper and written something that was somewhat long form (more than say 100 words). These past two or three years I, along with many others have probably felt their intelligence slip away from them. Although I feel more raring and eager to learn, I feel the part of my brain that used to be responsible for intricate reasoning has shrunk somehow. I do try to exercise it as much as I can but it still feels like that my processing power is escaping me here.

Perhaps it’s due to the advent of the “brainrot” that is Instagram Reels and Youtube Shorts (personally this was my gateway drug), or maybe it’s the advent of LLMs. I feel that you no longer need to reason through “difficult” problems. These are the problems which are tractable but hard enough to elicit growth and learning. Now it seems to be a battle of your willpower to resist the temptation of AI, to resist that get-out-of-jail-free card thats always there at the low low cost of $20/month.

I imagine it like going to the gym, but every time a rep gets difficult and it’s likely the one that is going to help you progress you need to resist the urge to press some magical button that will grant you the strength to complete the rep. I am troubled with how the next generations will develop and if they will regress even. Perhaps I’m wrong and the trend of each generation being more intelligent than those that came before will continue, but for now observing the fine specimens that inhabit our primary and secondary schools (ai emdash!) I doubt it. Hopefully they have more willpower than me, I will not pretend I have not succumbed to the allure of Jean Claude Van Damme.

Alternatively, maybe I’m too old fashioned for today’s standards and we’re in that awkward transition. According to my current manager when Intellisense™ came out, many “hardcore” devs were saying “that shits for skrubz, git gud and VIMmaxx REAL devs dont need intelliSLOP”, maybe reasoning through easy problems will no longer be needed, maybe schools will teach wayyyyy more advanced topics since a lot of foundational knowledge sharing can be delegated to the AI who knows. I just have a sneaking suspicion that we are the frogs getting boiled at the moment.

back to analog

I think recently catching the train more and really introspecting with myself has opened my eyes to how pervasive technology is in our lives. Before I was some weeaboo on the train scrolling through my manga on MangaDex. For everyone else it was music, sometimes a book but never were there so many drones scrolling away at their video feeds. So to combat my regression into some troglodyte and thanks to the education allowance at work I have been reading lots of books during my commutes and free time. It’s actually perfect for dogshit tier Australian mobile network infrastructure that somehow always has a dead zone between Strathfield and Redfern (pretty much half my train ride).

Recently I finished reading Philosophy of Software by John Ousterhout. So I wanted to share some concepts I picked up from the books in my own words and limited thoughts as a way to organise my own thoughts and kickstart my blogging.

complexity, what and how?

The first topic that Ousterhout addresses is that of complexity which almost acts as the crux of the whole book. What it is, how it happens, what to avoid, how we can avoid it. But to introduce the concept I personally understand complexity in a software to be how much I need to reason to work in the code base. Can I understand how things work at different levels of granularity and scope? How much knowledge do I need for that? If the ratio of knowledge to understanding is high then it is complex, other wise uncomplex. (Well no shit Sherlock!) But that is probably the best way to describe it, unless you have some alternatives feel free to share by emailing me raymondlsyd@gmail.com. Ousterhout himself defines complexity as anything about the structure of software that makes it hard to understand or modify and suggests some different complexity smells.

1. Change amplification - How much code and how many places do we need to change in order to modify or implement some feature.
2. Cognitive load - I think for me it means how much RAM does a human need to work and reason properly with your code. Ousterhout gives the example of every malloc() must be followed by a free(), you must keep this information in your RAM every time you malloc.
3. Unknown unknowns - Is it clear where you are inside of a system, if not globally then at least locally. What are the dependencies?

Ousterhout provides two main culprits as the main sources of complexity.

1. Dependencies
2. Obscurity

The rest of the book describes the cause & effect of these sources, how they contribute to complexity and some suggestions are made on how to deal with this complexity.

I quite enjoyed reading the part on complexity and I think that it really helps early career folk navigate and build a taste for what is complex. Why it is complex and whether that complexity is needed. I think I agree with most of Ousterhout’s talking points but I will probably look at some dissenting views later on to help me build my own taste. I think my taste is not as refined as it could be and I see a refined taste being very important in the age of LLMs and delegating our coding. If not for taste, what do we even have now anymore.