For example, if your language lacks a CopyTagedMatrix then you just write one, it gets the correct size, allocates the memory if necessary, copy the elements and return the new matrix. Now you can use it without remembering the implementation details, and it’s much clearer than the 10 lines that necessary to get the bounds and the fors to iterate over the matrix.
An extreme example is the GMP bignum library. You use each function as magic, and never read the implementation details. (Unless it’s in a very tight loop in a very hot part of the most important feature of your program, but I doubt that it’s good to use GMP in that place.)
Gates had a complete sense in his head of how his program worked at the level of machine language. But not at a lower level of CPU microcode, or transistors. So even he, even then, was not claiming to have "total" understanding in the sense I think you mean.
Likewise if the Linux kernel (or your distributed web app) is organized into a reasonable set of "chunks", then it is possible to have usefully complete sense of how it works. The implication being that if it's not organized -- or organizable -- like that, you have a problem.
This one struck me. Today the public methods of a class would check to make sure the inputs are valid. Back then the programmer would just know the location of every single caller and make sure the calls are always valid in the first place.
It's clear that the modern approach is a winner, especially with enterprise-size codebases, and really especially when developers churn every few years and nobody is around from when the code was originally written.
And of course Amazon is the ultimate success story of taking this idea to the extreme with a completely service-oriented architecture. Coding super defensively to minimal interfaces has been proven to work.
Personally, I would use the second option even today, with the caveat that there should be few, if any invalid inputs, what with type systems and OOP. If your method takes a string as a parameter, and can't handle every string that ever existed, then you really should be deserializing it into a data object of some kind, so that the compiler does the validation for you. If I'm developing some kind of API for public consumption, then I'll do input validation at the service boundary so that the consumer knows why it didn't work, but otherwise I'm a big proponent of the "just don't pass null" approach. Input validation on every function call bloats the code base, and is annoying to read through.
> You’ve got to have somebody who’s super smart. A great programmer thinks about the program on a constant basis, whether driving or eating. That method takes an incredible amount of mental energy.
> Before I sit down to code something, most of the instructions have already run through my head.
> Programming takes an incredible amount of energy, so most programmers are fairly young.
It may be a bit anachronistic to look at statements like these in the light of subsequent revolutions in software development such as XP and Agile. But I can't help thinking as I read this that he's doing it wrong. All the talk about using lots of mental energy to "have a complete grasp" of the program is fairly useless when faced with ever increasing complexity and code base size. Test Driven Development and clean code organization goes a long way towards breaking large problems down into easier to manager parts.