On the business logic side, speaking mainly from experience in enterprise software consulting (and some related research work): the domain is often complex enough, and the knowledge of how the business actually works (as opposed to what your TOGAF/Zachman diagrams tell you) is tacit and distributed enough, that the code you're writing is often the first time that everything in a particular process/subdomain has been made explicit. (This is especially true during 'digital transformation' at e.g. old manufacturing companies, where individual IT systems have been pretty nicely decoupled at a technical level and work together only via people systems.)
In these situations, certain 'core' parts of the code quickly become the only accurate spec. (Whether or not it's worth updating the spec docs is a management decision. But the test scripts will pass if the code is correct, and under sufficient time and money pressure etc..) Other developers then treat these 'core' parts of the code (usually some fairly high-level classes, but usually something more concrete than an interface) as the true documentation of the business requirements. If the company respects developers enough, this means that the developers that worked on those 'core' bits of code are also treated as domain experts in future business discussions.
On the purely technical side: sheesh, how much heat is generated by horrifyingly algorithmically inefficient or vastly I/O-wasteful or just redundant design (for instance religious/unnecessary use of immediate-mode GUI) -- stuff that quite possibly the IT managers don't care about at all (because of e.g. cheap horizontal scaling and inadequate measures of software project success)? The heat is bad for ecological reasons (locally at least), but also intrinsically (why are you destroying information, O Information Worker?? -- and again e.g. Toffoli gates fix this only locally). Based on code I've seen and, sadly, written (laziness, time pressure and all that) -- there must be many, many orders of magnitude of unnecessary heat/information-destruction happening because of purely technical decisions that on-the-ground developers (not even architects/designers, I mean the people that write the stuff that gets compiled/interpreted) make. @OP if you know some way of measuring this I'd love to hear more.
Thanks. You describe pretty much one of the points I want the book to make: the code is the description of the solution and often you have to address problems in code that no one else has considered. I think that’s a hard concept for non-devs to grasp.
In these situations, certain 'core' parts of the code quickly become the only accurate spec. (Whether or not it's worth updating the spec docs is a management decision. But the test scripts will pass if the code is correct, and under sufficient time and money pressure etc..) Other developers then treat these 'core' parts of the code (usually some fairly high-level classes, but usually something more concrete than an interface) as the true documentation of the business requirements. If the company respects developers enough, this means that the developers that worked on those 'core' bits of code are also treated as domain experts in future business discussions.
On the purely technical side: sheesh, how much heat is generated by horrifyingly algorithmically inefficient or vastly I/O-wasteful or just redundant design (for instance religious/unnecessary use of immediate-mode GUI) -- stuff that quite possibly the IT managers don't care about at all (because of e.g. cheap horizontal scaling and inadequate measures of software project success)? The heat is bad for ecological reasons (locally at least), but also intrinsically (why are you destroying information, O Information Worker?? -- and again e.g. Toffoli gates fix this only locally). Based on code I've seen and, sadly, written (laziness, time pressure and all that) -- there must be many, many orders of magnitude of unnecessary heat/information-destruction happening because of purely technical decisions that on-the-ground developers (not even architects/designers, I mean the people that write the stuff that gets compiled/interpreted) make. @OP if you know some way of measuring this I'd love to hear more.