That's easier, not simpler. When part of the stack breaks you're even less likely to know how to fix it than 15 years ago.

http://www.infoq.com/presentations/Simple-Made-Easy

The procedure that I use is simple, regardless of the underlying complexity that makes it simple.

Eating is simple, even though the body is complex. I'm glad I don't have to explicitly operate my pancreas.

30 years ago you could actually "understand" the whole computer. While 64 KiB is quite a bit of RAM for human to keep track of, it was still possible to quite easily remember how the address space was laid out and what exact addresses were used for storing individual pieces of variables used by the OS/environment and what addresses to PEEK/POKE to interface with the OS services. People really knew how the machine operated at hardware and software level. Inside out.

20 years ago it was much harder to understand the whole machine or it's operating system. While there was direct access to low-level services(BIOS/DOS interrupts on PCs), some APIs started emerging, including OpenGL and soon DirectX to make things more complex. People had hard time understanding the exact inners of the hardware and especially software, although specialized understanding was still very relevant for many.

10 years ago it had became quite useless to try to deal with hardware directly. Compilers started being so good that hand-written assembly started having bad benefit/cost ratio. People stopped caring about optimizig code or really understanding about the hardware details. Software became already quite complex to truly understand, focus shifted from understanding the environment to understand the tools and some libraries.

Today understanding the hardware is essentially impossible. You can't really deduce what exactly the CPU is doing when you read the instructions, many programmers don't even know what an instruction or a register is, let alone understand branch predictors or memory caches. Lots of code run on virtual machines rather than directly on real machines. Operating systems have virtual layers here and there and programming culture(at least to some extent, my own observation) has opted some perverse idea that you should not optimize or even consider optimizing code, because "PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL!!". Programming work requires very little understanding of the system or platform, and many skills are very short-living and focus on specific technologies/libraries. Most programming problems are researched from the Internet via StackOverflow. There's very little room for truly understanding the environment, things change so fast and are so complex that it's just not important.

Things get more and more complex at exponential rate. I find this quite sad because I for one love low-level tinkering with stable interfaces and problems/domains which require extensive studying and investigating to come up with creative solutions to uncommon problems, rather than running into problem X and asking on Stackoverflow about what pattern to use or what library call to make to get around the issue.

If you work on low-level software, you can and will use tools like VTune and cachegrind to understand where the performance bottlenecks are for your code.

If you are working with a lot of people who tell you not to optimize, you're probably working on high-level software where the focus is on getting it out the door as fast as possible. Try working for a company like Intel or NVidia. You'll write plenty of assembly language there if you want. There's also things like compilers, virtual machines, and storage software.