Earlier quoted context omitted.
Every programmers should know something about memory, because software are becoming bloat [1] [2] because of a new generation of programmers who doesn't optimize their code. So, of course, you had a wonderful career, but it doesn't prove that you write efficient code [1] http://www.rntz.net/post/against-software-development.html [2] http://tonsky.me/blog/disenchantment/
Is it better for my company if the software is delayed to market by 6 months because we were writing the most optimal code possible in low-level languages gaining us 5% more speed on our application? Most programmers are working for a business whose goal is to make money. Usually that involves adding more features or producing the product faster (as in development time). As far as optimal or efficient goes, all the c…
More than premature pessimization? Setting your project performance goals is plain good design. It's not premature optimization to suggest that your web server should be able to respond to queries within an average window of time. Working with any kind of service level object and agreement practically requires you to think about these goals at the design phase regardless.
I've come across teams with engineers who couldn't understand why their application was timing out. They had no idea how to work with data structures and memory layout to optimize access. Their response to business stakeholders was to weakly raise their hands to the ceiling and say, "It can't be fixed." Their customers would not have been happy with that answer; they had precious data and reports to deliver.
It's worth knowing, at least on a conceptual level, how memory architectures and data structures affect performances. Otherwise you end up paying people like me a lot of money. And you don't want that.