“Code was never the hard part” is an insult to all programmers

Sometimes coding is hard. There are two types of hard things: algorithms and architecture. LLMs are good at algorithms, not good at architecture.

Most of the time coding is not very hard, it’s filling in the blanks, implementing the business logic, writing boilerplate code. LLMs are good at this too.

This has nothing to do with any intrinsic difficulty with coding and more to do with the industries penchant to rewrite everything every couple of years. The reason you don't see people who went to management become ICs again, is because you have to spend time learning the new, correct™, way to do read and write code.

From the constant API churn for something like React, or even the 20 million updates to write "modern" C++, someone who has had those minute decisions abstracted away will struggle to write code.

"A similar idea [to libraries] is the Collected Algorithms published by ACM years ago in an ALGOL-like publication language. I remember when I was a kid in 1968 looking up algorithms for sorting and searching in my first programming job. However, what every manager learns is that reuse under these circumstances requires a process of reuse or at least a policy. First, you need to have a central repository of code. ... Second, there has to be a means of locating the right piece of code ... It does no good to have the right piece of code if no one can find it. Classification in the world of books, reports, magazines, and the like is a profession, called cataloging. Librarians help people find the book. But few software organizations can afford a software cataloger, let alone a librarian to help find the software for its developers. This is because when a developer manager has the choice of hiring another developer or a software librarian, the manager will always hire the developer."

He talks about a few reasons for why this is, one of them being simply that plenty of code for your project will just have to be new / different enough from existing code, so there's not much reuse benefit there. He qualifies that with performance concerns, but that's just one reason why it would have to be different.

Another thing I was reminded of, from the intro of Etudes for Programmers:

"Programming is a craft, and programmers must attain a standard of craftsmanship. Much programming is done in cottage shops -- that is, in small shops with meager tools, much work done by hand, and learning attained from other laborers, by chance, and often not at all. ... the academics have also discovered that a craft cannot be taught well by teachers alone; the guild apprenticeships had considerable merit. In a classic apprenticeship the candidate spent many years doing menial tasks while absorbing fundamental techniques of the trade from more experienced workers in the shop. Gradually the apprentice was given more technical responsibility and, after a formal test of skills, eventually became a journeyman certified competent for all ordinary jobs in the trade. The journeyman traveled the world and, if the muses allowed, one day presented a masterpiece to the guild and became a craftsman of the highest rank -- a master of the guild."

Seeking for the average to be that of journeyman, rather than apprentice, seems like a worthwhile goal for the industry. You sound like a journeyman to me, and I can generally trust other journeyman programmers. We don't all need to be masters to have an industry, and that's probably not possible anyway. You say you can't implement TCP congestion control -- but you can build networked applications. Building networked applications is an ordinary job of the trade, and I'm sure you know how to do it in a number of ways. I also suspect that if you had to create some custom UDP protocol for something, you would be able to implement some form of congestion control for it in not too much time -- even if that involves searching for and copying a known algorithm, or if you're lucky finding and using a pre-built library flexible enough for your custom needs. That highlights two more reasons for why we don't hire librarians over developers. First is that, if you're at a journeyman level, then you can be trusted to handle the rather common scenarios where you have to do something for which there's no perfect matching library or framework or SDK you can just use. Whether you have to roll up your sleeves and go low level, relying on very little, or just need to be able to tie enough separate preexisting things together with some minimal glue to handle the new/different stuff, they're both activities that require a programmer rather than a librarian. (I guess this is just further elaboration of the already mentioned "there will be custom code not eligible for replacement by something reusable" reason.) Second, the task of a librarian to find software has been made much easier since the 90s with things like search engines, massive communication channels to share and find out about stuff, and massive open source repositories. It's so easy now that developers themselves can do a decent job at it among their other duties.