4 ms·

A lot of the software engineering approaches from that era (refactoring, TDD, patterns) make more sense in the world I grew up in: large pre-compiled code bases

A lot of the software engineering approaches from that era (refactoring, TDD, patterns) make more sense in the world I grew up in: large pre-compiled code bases where everything other than the base OS layer is under the engineer's control. If you have to ship your SW as an installable which will end up on someone's machine far away your mindset will be more defensive. In this day and age of vastly distributed systems where distribution and re-distribution is relatively cheap we can afford to be a little less obsessive. Many exceptions still exist, of course, I would think that the teams developing my car's control system might warm up to TDD a bit more than someone putting together a quickie web app.

buscoquadnary 4y ago
I think you make an important point. It used to be I'd have to worry about the OS layer, and that was it. Now I have half a dozen layers running between my code and the actual die executing instructions and as consequence of that I've lost a considerable amount of control. The funny thing is I end spending just as much time trying to debug or figure out the other layers, looking at you AWS IAM, that I don't feel I am that much more productive, I've just taken what my code needed to do and scatterred it to the 4 winds. Now instead of dealing with an OS and the code I'm fighting with docker, and a cloud service, and permissions and network and a dozen other things. Honestly this feels like the OOP hype era of Object Database and Java EE all over again, just this time substitute OOP for tooling.