Well put! At the end of the day, it's way more important to get your product out to customers/users rather than holding a microscope over every line of code you write and endlessly obsessing over big O numbers. It's fine if you're in academia, but it can be a death knell if you're working in a crowded domain. You can always go back and improve code later; customers/users are not going to come back later.
I'm all for striking the right balance with perf concerns, but in my experience that's not "just deal with it later". Giving no thought to performance is as bad as micro optimizing at the beginning.
It's not even an obsession. Those pieces of knowledge could be fully mastered in about a half hour. It's first principles knowledge, like chemistry or thermodynamics. I can tell in a minute that something like "Solar Freakin Roadways" is a scam, whereas so many people gave that scam literally millions of dollars. Knowledge is literally power, in a very concrete way that expresses itself directly as dollars!
Instead of having some basic first principles knowledge to spot such things ahead of time, benefiting from the collective experience of your field, you'd rather just labor in ignorance and run into everything for the first time and get out the profiler? Imagine scaling that up to the size of the Amazon or Google workforce?
I absolutely don't disagree with optimizing when it's obvious (two for loops instead of one, etc.) All I'm saying is that, when you have thousands of lines of code (millions?) and even more complicated/intricate connections in your head of different modules, all the while when trying to reach a deadline, things aren't as obvious. You have to make compromises, it's inevitable.
Amazon or Google did not scale up magically in one go by following established guidelines. I am very certain they had growing pains and I know that they had "hacks"[0] while figuring out the right solution for the problem at hand.
[0] As attested by a former Googler who works at my current workplace
What we disagree with, is the expansion of one's knowledge of what constitutes "obvious." Many people would say that the scam nature of "Solar Freakin Roadways" was far from obvious. Other people would smack their foreheads and ask why some people didn't pay attention in middle school and high school physics!
My conjecture is that a big fraction of programs could get significant performance boost noticeable by end users if they were developed by good developers who have some knowledges in algorithms. You don't need to be an expert, but knowing very basics on time complexity and fundamental data structures is necessary to every programmer IMHO.
In your highlighting example, instead of working with someone who will optimize, I'd much rather work with the guy who will realize we can just debounce the dialog, write a one line comment about the performance issue, and then move on to the next thing.
Maybe I'm biased though. I've worked with the performance guy; he was brilliant and the code was clever and highly performant, but he was also slow and didn't write clear, maintainable code. We didn't ship in time and I had to find a new job when the project got scrapped. Damned if it wasn't fast though.
As long as you are aware of the issue with naive string concatenation, you can use a string buffer or a mutable string – it is trivial to solve in a few more lines of code. What's more difficult involves deletion in the previous text. If this happens often, you will need rope or skip list, which is challenging if you implement from scratch. In the latter case, I would leave a comment without implementing the optimal solution and let the profiler decide later.
Sounds more like a project management issue to me, than a problem with that coder.
I'd rather see basic project management skills than basic knowledge of algorithms. Unfortunately, the former is much more rare.
From my experience: very frequently.
So it's useful at these corporations for all engineers to have this understanding, I think.
The biggest impact to our performance has been switching one JSON serialization library for another, no algorithmic knowledge needed, just basic benchmarking skills.
Knowing when you can just slap in the naive string concatenation and move on is also a useful result of the right skills. If you had better profiling tools/skills, I posit that you wouldn't have had to do the useless optimization.
True. And people who clutter their code by using some fancy "StringStream" class when they could've just used a concatenation are also part of the problem!
Saying that programmers don't need a basic knowledge of algorithms is like saying drivers don't need to know how to back up a trailer or do a 3 point turn. Over 90% of the time, you don't need it. But when you do, you really do!
Knowing the typical time and space complexity for an algorithm (without even understanding one bit about the implementation details) in a given category might be considered too trivial to be even basic, but I submit it's about the most "advanced" piece of knowledge for what a typical engineer really must know to write good, high quality and performant enough code.
Most can get by using a given language's library implementation of an "obvious" data structure and naive algorithms around it. For example, in Python, the "obvious" structure to map keys to values is a dict, and iteration over the keys or item tuples is a typical access pattern. An engineer doesn't need to know whether the dict insert or lookup is amortized O(1) or any other value, and he doesn't need to know the space required is O(n), etc. In almost every case he's likely to put it to use for the dict is fine.
I think we're both saying that it's generally a good level of 1st Principles knowledge for programmers to have.
It is about your base knowledge (which should include algorithms) and knowing those algorithms when its matters.
If you have the choice of two identical software engineers and one knows 1 algorithm more than the other, he/she wins.
For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenated in a given run, or the strings are huge, etc., relative to the compute environment. Does it really matter if one uses an O(n^2) solution when a few dozen (or even a few hundred) such operations are applied on "small enough" strings in a given execution on modern computer hardware? No, it just doesn't.
Select candidates who are keenly interested in and knowledgeable about algorithms for positions where it's important (i.e. part of the regular course of development), not because of that slight chance there is one edge case where one adjustment to a more efficient algorithm might possibly be useful at some indeterminate point in the future.