In internet parlance, the term "meatspace" refers to the non-networked world. You know, good, old-fashioned reality reality--that messy place where we have to look people in the eye and remember our manners as we talk to them. Programmers, particularly those of the database/back-end kind of coding, too often have to be reminded of its existence...at least after the business rules have been codified in the software design/specs.
Don't get me wrong--even programmers who don't write web pages or phone apps. still have to contend with real-world constraints. For instance, on my last project, I ran up against the limits of a fairly slow processor on a cloud server.
Now, cloud hosting companies, as a rule of thumb, keep their hardware in matched sets. That keeps everything standardised. It's not an OCD thing--the apples-to-apples parity means that they can scale servers up and down by adding & removing processors and blocks of memory almost on the fly. Upgrades that would have taken days even fifteen years ago now can be done in a matter of minutes with mere seconds of downtime. That's a Big Deal.
But for all the benefits of hosting in a virtual private server environment, it does come with a downside, and that being that the hosting companies have a vested interest in commoditisation, which generally pushes them toward the low end of performance. In most instances, throwing more hardware at the code is all you need. After all, industrial-strength software such as the Apache web server or the MySQL database will spread out its requirements over multiple CPUs.
But woe betide the programmer crunching hundreds of thousands of records with a lowly script. In my case, the PHP executable can only use one processor at a time. In which case, 1 + 1 does not necessarily equal two. Simply because processing data in parallel means that separate processes are in constant danger of stepping on each other's metaphorical toes. So some extra protections (lock files, record flags in the database) had to be spliced into the code as insurance that, say, the same record wouldn't be processed twice.
But as I've side-stepped into physical computing, limitations are hammered home even more forcibly. For instance, the Arduino and the Raspberry Pi only have a limited number of pins to work with. Not to mention considerations like voltages (5 vs. 3.3 vs. ???) and number of milliamperes that can be squeezed through them. And now, picking up 3D modeling (in the form of OpenSCAD), I even have to take pesky things like gravity seriously...at least for anything that's going to be printed in plastic. (Which is everything--CGI isn't my bag.) See, printing plastic into thin air doesn't work so well. And that the tolerances aren't completely perfect. And, most importantly, that saving my notes from the Geometry/Trigonometry classes that I took a decade ago was a really good idea.
I suppose that there's a silver lining, though. As noted earlier, the vast majority of the code I've ever written is the below-the-waterline part of the iceberg. So having to respect the limits of things besides database normalisation and Boolean logic and all that is good for you. The same discipline applies, after all. Code is written to be re-used. Functions/modules are documented. Input is validated (where possible; OpenSCAD doesn't provide exception-handling). Code is checked into source control. Alas, there's no such thing as unit-testing, but you can't have everything, I guess...
