You should read it especially now when more and more code is written by LLM. The important thing is not the code itself but your mental model of the software you're building. Sadly we seem to be moving away from it. We're accumulating more and more code that we don't understand or haven't even read.
Most of my posts have aged terribly in the age of AI (especially the ones I didn't finish...so long, extended discussion of how to use a lab notebook when debugging, we hardly knew ye. Claude fixes our bugs now) but one job that engineers still have is the collection and retention of context that AI doesn't have and can't easily get.
The only reason I recommend this paper is because I encounter so many people that have a very myopic view of the software that they’re building. They are focused on individual features and how to quickly made them happen regardless of what happens to its cohesiveness. You start to talk about interfaces and contracts and they’re like a deer blinded by a car’s headlights.
I wouldn't start to think of someone as a real developer unless they've at least designed & written something of at least 10K LOC or so of complexity from scratch a few times. At least, you're not going to be able to understand these lessons and characterizations of programming in the large unless you do have at least that level of experience.
The larger and more varied projects that you have designed from scratch, the more you start to understand what programming/designing is really about.
You should read it especially now when more and more code is written by LLM. The important thing is not the code itself but your mental model of the software you're building. Sadly we seem to be moving away from it. We're accumulating more and more code that we don't understand or haven't even read.
I wrote a series of blog posts about this a few years ago: https://creating.software/essays/theory_of_a_program/, some of the few I ever actually finished, lol.
Most of my posts have aged terribly in the age of AI (especially the ones I didn't finish...so long, extended discussion of how to use a lab notebook when debugging, we hardly knew ye. Claude fixes our bugs now) but one job that engineers still have is the collection and retention of context that AI doesn't have and can't easily get.
The only reason I recommend this paper is because I encounter so many people that have a very myopic view of the software that they’re building. They are focused on individual features and how to quickly made them happen regardless of what happens to its cohesiveness. You start to talk about interfaces and contracts and they’re like a deer blinded by a car’s headlights.
I wouldn't start to think of someone as a real developer unless they've at least designed & written something of at least 10K LOC or so of complexity from scratch a few times. At least, you're not going to be able to understand these lessons and characterizations of programming in the large unless you do have at least that level of experience.
The larger and more varied projects that you have designed from scratch, the more you start to understand what programming/designing is really about.