4 ms·

I suspect that the ones of today would have a mental agility and/or capability to discover things on the fly that simply weren't possible all those decades ago.

I suspect that the ones of today would have a mental agility and/or capability to discover things on the fly that simply weren't possible all those decades ago. I think it's only at the real low-level or hardware/assembly or, for instance, a bit above the stack, say, optimizing a data model or fine-tuning a DB engine for a given domain, that the old timers would really shine. I see it in my daily life: my dad was a Fortran programmer way before I was born, so, maybe you know... 1970s or something like that. He was actually very good at his job, getting a research position doing some serious programming work that was seen as groundbreaking at the time, doing some finite element modeling on extremely resource constrained environments, probably what we would call data-oriented programming today, but taken to its extreme.... However, he didn't really keep up with programming after a few years, shifting to MATLAB based tasks for some university courses he lectures... and I feel that the complexity of today is just too much for him to grasp as it was. It's just too many moving parts and too many layers of abstraction to sift through. By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc.

com2kid 4y ago
> By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc. I've done both. I've gone from high level C# to counting clock cycles for embedded, and then back again. There is a transition period, but it is perfectly do-able. It is helpful if you have someone to show you the ropes, but after that it isn't too bad. Heck I've met some teenagers who are into disassembling JVM/CLR stuff. (Which is actually, IMHO, much easier than raw assembly). Have you ever done scaling calculations for AWS services? Same sort of logic applies to writing code for embedded, there is just a different number of mhz and instead of gigabytes of memory you are talking kilobytes of memory, but other than order of magnitudes, the reasoning is actually not that dissimilar.
davedx 4y ago
My first couple of jobs from late 90s on were C++ and Java: homogeneous giant code bases with no agile, scrum, code review or anything. I do just fine with modern code bases and their complexity. I know I also have the experience to understand when the complexity is there for the sake of it and when it’s because of the business domain. I’ve left projects where the first kind was too high because I’ve seen enough to know I don’t have time for that BS anymore :)

com2kid 4y ago

> By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc. I've done both. I've gone from high level C# to counting clock cycles for embedded, and then back again. There is a transition period, but it is perfectly do-able. It is helpful if you have someone to show you the ropes, but after that it isn't too bad. Heck I've met some teenagers who are into disassembling JVM/CLR stuff. (Which is actually, IMHO, much easier than raw assembly). Have you ever done scaling calculations for AWS services? Same sort of logic applies to writing code for embedded, there is just a different number of mhz and instead of gigabytes of memory you are talking kilobytes of memory, but other than order of magnitudes, the reasoning is actually not that dissimilar.

davedx 4y ago

My first couple of jobs from late 90s on were C++ and Java: homogeneous giant code bases with no agile, scrum, code review or anything. I do just fine with modern code bases and their complexity. I know I also have the experience to understand when the complexity is there for the sake of it and when it’s because of the business domain. I’ve left projects where the first kind was too high because I’ve seen enough to know I don’t have time for that BS anymore :)