Unpopular opinion: Programmer time is more valuable than machine time. Maintenance is 90% of the life of a system. Therefore, just know the concepts for each .md file, be able to describe their general properties, and be able to work with existing implementations in the real world. Formal complexity is rarely useful, because on cheap hardware very inefficient code scales very well. Certainly, don't re-implement basics like sort, graph traversal or queuing algorithms unless there is a pressing need.
For example, it is infinitely more useful (faster implementations, more proven code, less maintenance overhead, free upgrades) to be familiar with iconv and the data available in the Unicode database than to memorize random facts about encodings.
> Unpopular opinion: Programmer time is more valuable than machine time. Maintenance is 90% of the life of a system.
That's actually the popular opinion.
Unpopular opinion: programmer time is more valuable than machine time up until the product starts to scale and/or outlives the savings. A programmer spending a week longer on doing something right might cost you a couple thousand dollars up-front, and would repay itself only in a decade. Then you scale 200x, and suddenly that suboptimal code is bleeding you those thousands of dollars a week.
Very unpopular opinion: the above examples is a good case; if your AWS bill gets too large, somebody in the company will start asking questions. What usually happens is that performance is externalized to end-users. It's their CPUs that burn through fossil-fuel-generated electricity that much faster and can no longer run more than a few apps at the same time; it's their mobile phones that need to be replaced a year early because of the aggregate bloat. It's their sanity that's being assaulted by laggy, constantly acting up devices. But it doesn't manifest itself as a separate line item on the company's books, so nobody gives a damn. Instead, laziness and shoddy craftsmanship is explained away by economic self-interest.
There's more craftsmanship nuances between being lazily obliviousness to real-world impact and prematurely optimizing everything. Build something that works and is useful first, make it not suck and then try to make it awesome with what time is left. IOW, pull model of development from the real world rather than pushing through arbitrary/unprioritized development obsessed with using particular technological fashions. Yes, reuse optimized libraries that are best at solving common problems but don't deploy Hadoop to make an Arduino toaster, e.g., apply engineering discretion long learned from much trial-and-error and then verify it works and is correct with proper testing and benchmarking.
When you study you will learn a lot of stuff that seems useless for a Software developer at his daily job.
When you only know practice you will be able to use the tools but probably do not understand what most of them do, how they do it and why. Of course this may seem useless in many cases but on certain occasions like optimization some more theoretical knowledge may help you to dramatically improve your code or architecture (It could be the other way around of course).
In the end I think no matter if it is practical or theoretical know how you may gain something from it in the future even if it is not a (typical) topic of your field of work.
A very important insight for me is that you can learn as long as you breathe and it helps you to age more gracefully while being better at what you do.
For example, it is infinitely more useful (faster implementations, more proven code, less maintenance overhead, free upgrades) to be familiar with iconv and the data available in the Unicode database than to memorize random facts about encodings.