What does it mean to know a programming language? Simply knowing how to code in it is not enough: with the only exception of leetcode-style interview challenges.
Building or maintaining a production system is nothing like cracking a two-sum or even a three-sum problem: that's for sure. But what does it consist of? To answer that question, I have written this article. Needless to say, the opinions and experiences are my own.
In my surrounding, I've known quite some people who were learning how to program as well as some experienced devs learning a new programming language. I've been in this position, too, at the start of my career.
I remember distinctly this feeling: I know how to code, but I have no clue how to build what I want to build! How do I display a map of my future turn-based strategy game? How do I make a web server? How can I persist data? How can I make sure that my program is usable by others? How, how, how...
I was learning most of the stuff on my own, usually discovering answers to my questions as time went by: in some book, in a random article on the Internet, sometimes in a lecture, in a conversation with friends. And, of course, there was a ton of stuff that I didn't know that I didn't know. I remember discovering and learning about regular expressions, git, SQL databases, NoSQL databases, HTTP, TCP/IP and UDP/IP network stacks, cryptography, MVC, MVP, tests, big O notation, software architecture, monoliths, microservices, bytecode, interpreters, compilers, debuggers, threads, processes, security vulnerabilities, cloud infrastructure, Software (Infrastructure, Platform) as a Service model, monitoring, "You Ain't Gonna Need It", API, REST API, GraphQL, sockets, websockets, containers, and many, many more.
As a side note, for people who don't have a software engineering degree: did I learn all this at University? The answer is no. Maybe like 5-10%: mostly either I learned something before it was taught in classes (which is always nice and useful) or it wasn't taught at all (or superficially). This has further supported my individualist core beliefs.
The truth is, when we build software, we stand on the shoulders of giants. Millions of engineer-hours have been invested into all the stuff that just works under the hood, into the building blocks of the software development world. Most of the problems that we can (easily) think of have already been solved fully or to some degree.
What is not solved are the particular requirements that we have in mind: this button should do that, these and these filters should exist and be reactive, a calculation should be done in such a way and stored in such a table in the database, and so on. These are typically called business rules. A typical job of a typical software engineer consist of implementing these business rules using the building blocks available: button, filters, calculation methods, databases and so forth.
Therefore, an engineer who knows the building blocks better (in-depth as well as in-width) has an advantage: they can rely on the work results of many, many engineer-hours to solve the particular problems that they have ahead of them. They don't need to reinvent the wheel, but instead, they can take a reliable, proven, scalable, maintainable and secure (depends on the particular case, of course) solution and simply apply and adapt it however they need to. This knowledge about the building blocks is by itself very precious.
Needless to say, knowing the building blocks is a requirement for being a senior engineer. Or, to put it the other way, it is a component in a key qualification for being a senior developer: being able to ship high-quality software under time constraints, autonomously. This isn't possible without knowing the surrounding technologies and concepts.
One can notice that none of the stuff I've listed above in the "Building blocks" part is tied to particular programming languages. Instead, they belong to the general software engineering knowledge, some basis that enables developers to understand what's what. I expect all seniors to be familiar with these topics (it's okay to miss out on a few, of course).
Opposite to the general software engineering knowledge is the programming language specific knowledge. It includes a lot of stuff typically found in books: syntax, runtime environment, features and so on. But one thing that's often disregarded is the language ecosystem: the typical application, useful libraries, methods, best practices, community, job market, sponsors, its trends and future.
There is one dangerous myth that when a senior software engineer wants to change career and, for example, wants to start with another language in the same field or even change the field, and, let's say, pick up mobile development instead of backend development then they have to start their way from scratch, all the way from the junior level...
It's simply not true though. Yes, they'll need to learn the new programming language and its ecosystem, but many fundamental concepts heavily overlap and should already anyway be known to the senior developer (not speaking of the soft skills that come with work experience).
The building blocks are learned the best by reading a lot about different topics. I think that's the only way to do it. It's hard, but it has to be hard.
Another question would be, how to optimize the learning process? One way would be to simply learn it at University; but it only works if you study in a good place with a solid software engineering program, which is not an option for most of the World's population. Another would be to randomly search for information online; but because of the unknown-unknowns, it would take time to make progress.
I think the ideal way is to have a guided learning experience: best of all is to have a mentor, but, otherwise, following a roadmap like this is also very nice.
Beware of the paid courses: if you decide on them, you should have an answer to a question like what's their business model? In my experience, beginner-oriented free courses tend to have far superior quality and success rates than paid ones.
Language ecosystems are typically far easier to pick up, but harder to find a guided learning experience for. If you know the fundamentals and the ecosystem for at least one programming language, then the others are kind of familiar from the get-go.
A publicly available guided learning experience is virtually non-existent aside from random articles on the Internet. A private one is typically done at the place of work, and it's quite expensive for the employer.
If you want to learn a new ecosystem from scratch on your own, then be prepared to put your systematic information gathering, processing and retaining skills to merit. Internet articles, community forums and chats, StackOverflow, GitHub statistics and popular repositories, YouTube channels (esp. recordings from conferences and talks) are a good place to start. Good luck!