I see a lot of job postings that, if they aren’t putting a programming language directly in the title of a position they are hiring for, will put the name of the language as an important requirement somewhere in the job description. I believe this sort of practice is guided by a misconstrued perception of what the relationship is between people and their ability to develop software. There should be no “Java Developer” or “React Developer;” there should be only “Software Developer,” regardless of the languages a person will be interacting with in a job. People don’t know programming languages to the extent they should be labeled with them. It may even make more sense to say that people can’t “know” programming languages to begin with.
Languages are not separate enough from one another in a sense that warrants different job occupations for each one. If a technical divide must be drawn between different programming intensive jobs, it should be at a higher level, defined perhaps by the distance from the silicon within which a person is working. These could be low-level systems development, computer network development, and work with data in scripts, to name a few categories. Even with these broader categories, it is difficult to see why one would believe that the people capable of performing well in one role wouldn’t be able to perform well in the other, given that the problems requiring an experienced, human mind in one role are almost always the exact same problems arising in the others. These include the complexity of algorithms used, that is, if they are not taken straight from a library. Other shared problems include the issues that arise when programming concurrent processes and those that come with systems that are developed by large groups of people simultaneously, such as version control. This characteristic of programming work, that it does not vary much between mutually exclusive categories within it, no matter how you define them, is heavy at the low level of separation that are programming languages.
The most common response to this argument I see is that, regardless of the conceptual similarity that exists between problems in different languages, grokking the intricacies of a language, or even a framework within a language (e.g., React), is time consuming, at the expense of the organization that is hiring the individual. They would much rather hire a programmer who happened to have worked with Kotlin for a project at their previous job than hire what may be a more competent programmer who has never bothered to touch the language. This line of thinking is unfair not only to the programmer but to the organization that seeks to employ someone. The time that is spent reading and getting comfortable with what is different about a language to what the programmer is familiar with is, over the length of that person’s employment, outweighed by their ability to problem solve. As such, their value to the company is much higher in the long term, and this period of time is not long. I would estimate at most a year.
It is not difficult to understand why this view is so prevalent. Human ability to problem solve in software does not specialize to the extent that it does in many occupations that deal with the physical world. The trades, for example, may become so specialized as to deal with separate household appliances or components within a single home electrical system. Physicians will spend years focusing one particular organ within the human body. The reason for this is that these roles are more descriptive in their problem solving than they are constructive. A physician’s most valuable ability is their intricate knowledge of the human body as is knowledge of the workings of cars to the auto mechanic. The problems they face can be dealt with directly with this knowledge, and their ability to solve them scales directly with the amount of knowledge they have on the domain. This scaling does not exist in the realm of software.
The development of software does not benefit from the familiarity one has with the language they are working with, because the language is a tool, not the thing they are grappling with. The programmer is grappling with something much larger, which is the natural limits of what information is attainable in a limited amount of time and how it must be directed to achieve a certain outcome. This is not something with a structure that can be memorized and recited when confronted with a problem.
Not all occupations that deal with the physical world have this same characteristic, of scaling in solvability in relation to the knowledge of physical object that one has. Architects and other artists can know everything there is to know about their construction materials, environments, and canvases, without getting better at what they do. That is because the problems they are faced with are also constructive as opposed to descriptive. That is, in order to achieve the goal they want to accomplish, they cannot refer to the inner workings of what they are working with, but rather with the natural constraints set in place by the universe. They will move forward in their obstacle not by understanding the object within which the problem lies but rather by understanding the domain within which one can act. In software, and in all fields with constructive as opposed to descriptive problems, this domain is limitless. It is nature itself, and in particular, in software it is mathematical as opposed to physical.
I am often asked what programming languages I “know.” I know them all and I know none of them. I need only some documentation and some time and I will be as “fluent” as anybody is in the language at hand. Programming languages are not like natural spoken languages in that fluency is a tangible, easily measurable concept concept. “Fluency,” if the term must be used with regards to programming languages, should refer only to the amount of time it takes a person to ramp up to the point where the intricate details of a language, such as syntax, are easily manipulated. This is wholly different from the usage of the term with natural spoken languages, for which the term refers to an understanding of underlying structure that does vary at an extent much larger than in programming languages. Computers are significantly more homogenous than humans in the way we convey our thoughts to them.
This line of thinking is held in highest frequency by people who do not know much about the technical aspects of software development, who also happen to be those most likely to be doing the hiring in many organizations, especially in companies outside of Big Tech. It would benefit everyone to be more aware of this distinction of software from other types of jobs.