[chrismarlow9]

I'm a dev who learned everything by experience. I'm in my 20's and have been doing this for ~20 years, so I have a bit of experience with both the new and the old world.

My take is that the code quality of whats allowed to be in production has gotten worse, that's it. It's an effect of an abundance of RAM and virtualization. The abundance of ram lets you just trash it and do things in a horribly inefficient way. Sure the extra memory can help with time memory trade off if you have something that doesnt need to scale a great deal, but processing things inline will still be faster. Developers have forgotten how to handle streams. Usually forcing a dev to learn a highly functional language that's immutable can fix these issues (it must involve a large dataset, where you know they will tax out the memory, and then code review to help).

I mention virtualization because a common pattern I've seen is to write poor code, and just put more boxes behind the load balancer when things start failing because the technical debt is so high it's an impossible mountain to climb. This obviously isn't the right approach and will leave your devops guys worn out chasing your everyday distributed systems problems that happen because it wasn't built right for distribution and the dev has never read the fallacies of distributed computing.

And while you're fixing this technical debt a team of competent engineers builds a competing product and trumps you hard (second mover advantage).

Maybe people paid a bit more attention when things cost 10x as much as they do now and every answer (both bad and good, and you can't tell the difference) wasn't a stackoverflow search away.....

[aaron_m04]

So you're in your late 20s and started working when you were in elementary school? :-)

[Varcht]

Good point. Currently I am working on parsing a 5.5 million line STEP file. I've learned more about memory usage and high level overhead in the last week then I had in the previous 10 years of .Net dev.