Je pense que cette question appelle une perspective historique.
À l'époque "d'antan" (dont je ne suis pas un témoin personnel, ce n'est donc que ma reconstruction de cette époque - n'hésitez pas à me corriger si vous avez vécu les choses différemment) L'espace matériel et les performances étaient nuls par rapport à aujourd'hui. Donc, tout ce que les gens écrivaient devait être très efficace. Ainsi, ils devaient réfléchir et rechercher pour inventer les meilleurs algorithmes pour atteindre les performances spatio-temporelles nécessaires pour faire le travail. Un autre facteur était que les développeurs travaillaient principalement sur ce que vous pouvez appeler l' infrastructure : systèmes d'exploitation, piles de protocoles, compilateurs, pilotes de périphériques, éditeurs, etc. Tout cela est beaucoup utilisé par beaucoup de gens, donc les performances font vraiment une différence .
De nos jours, nous sommes gâtés d'avoir un matériel incroyable avec des processeurs multicœurs et des gigaoctets de mémoire, même dans un ordinateur portable de base (diable, même dans un téléphone mobile). Ce qui signifie naturellement que dans de nombreux cas, les performances - donc l'algorithme - ont cessé d'être le problème central, et il est plus important de fournir une solution rapidement que de fournir une solution rapide. OTOH, nous avons des tas de frameworks qui nous aident à résoudre les problèmes et encapsulent un grand nombre d'algorithmes en même temps. Donc, même lorsque nous ne pensons pas aux algorithmes, nous pouvons très bien en utiliser beaucoup en arrière-plan.
Cependant, il y a encore des domaines où la performance compte. Dans ces domaines, vous devez toujours réfléchir à vos algorithmes avant d'écrire du code. La raison en est que l'algorithme est le centre de la conception, déterminant un grand nombre de structures de données et de relations dans le code environnant. Et si vous découvrez trop tard que votre algorithme ne se met pas à l'échelle correctement (par exemple, il est O (n 3 ), il avait l'air bien et rapide lorsque vous l'avez testé sur 10 éléments, mais dans la vraie vie, vous en aurez des millions), il est très difficile, sujet aux erreurs et prend du temps pour le remplacer dans le code de production. Et les micro-optimisations ne vont pas vous aider si l'algorithme fondamental n'est pas adapté au travail.