[vlovich123]

> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare.

This undercuts your claim a bit as someone has to be able to write the library in the first place. Yes it’s rare, but the software engineering industry is big enough that “rare” can be a “this happens all the time in domain X”.

Overall though I’d agree that it’s not useful for the majority of engineers and isn’t a good judge of programming ability just like math competitions aren’t either. They are “something” though.

[derefr]

Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge.

It’s not often that you’re writing such code “in anger”, under time-pressure to ship to fix downtime, with no time to get peer review.

This is in large part because the downstream client of an algorithms/data structures library, would almost-always prefer a robust but less-efficient option, over an alpha-quality implementation of a more-efficient option. Dataset-size scaling challenges that recommend algorithmic efficiency increases can, almost always, be temporarily put off by “throwing machines at the problem” until the more-efficient library becomes high-quality enough to be fully relied upon. Until then, the business logic will make do with the simpler/more naive algorithm.

And in most language runtimes, there’s a simpler/more naive algorithm or data structure to solve every problem already laying around in the core stdlib; so it’s not like you, as the library writer, have to implement that code “in anger” either. Your internal customers can upgrade from depending on stdlib types, to depending on your lib’s types, when using your lib becomes an unalloyed win for them; and until then, do nothing.

[DSMan195276]

> Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge.

I'll be honest, I think you're vastly overestimating how well these things are actually developed :) I agree with what you said, I just found this part a little bit funny.

[derefr]

What I really meant, without the fancy language, is that stdlib programmers are crotchety greybeards who don't like change-for-change-sake and so default-deny rather than default-accept random patches. That by itself creates a very different level of stability in these projects, where things only ever change if they really need to to fix a specific bug—and even then, the change is pared down to have as little architectural effect as possible.

[kamaal]

You most likely need strong grasp over OO, and design patterns to be a good library designer/programmer than Algorithms that you can easily look up online.