> A cello player is a cello player everywhere. They can use the same instrument, same reflexes, and what they used to play in a different environment.
But programming is exactly the same. A programmer knows how to program, and they can program all sorts of different things, with different languages, without having learn how to program from scratch each time. Most programming languages/projects are more similar to the rest, than different.
> A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM.
In your developer example, it would be more fitting to compare it to that they could build CRUD apps, or desktop applications, and it wouldn't be that much different. Plenty of programmers work in multiple "fields" at the same time, just like a Cello player might.
Respectfully, no. You're right about picking up programming languages, but missing the nuance about developing different genres of software.
I develop utilities, material simulation systems (think finite element, boundary element, etc.), and used to develop an AI system (a multi-agent collectively intelligent system, an autonomous marketplace).
The knowledge required in each one of these is vastly different. First one requires OS knowledge and is generally I/O bound, so you try write good code, talk sensibly with the OS, but you don't need to optimize beyond the obvious pain points.
Writing simulations is completely different. I do care about the language, how it behaves, how I can extract every bit of performance from the CPU, while implementing numerical differential equations which needs to be exact, accurate and precise, while not compromising the performance of the codebase. I benchmark memory and CPU separately and as a whole, while not deviating from ground truth values. Otherwise things go very bad.
AI system was latency sensitive. I needed to make it fast while not bogging down the system as a whole, it needed to scale while being intelligent about what to do, and be flexible enough. This required strategies, self-tuning, etc. It was no neural net, so it was a completely different beast.
System programming is similar. Latency sensitive, talking correctly with the OS, and not bogging the system down while doing useful work.
Learning programming languages is easy. Implementing differential equations with demoscene levels of optimization while being exact and accurate is not.
Heck, even the usage patterns for the same programming language is different between different genres of software.
I feel like you're mixing the domain which you are programming in, versus "programming" as a concept, while I'm focusing purely on programming.
I do understand that different domains require different skills, that much is evident in itself. But then we're moving on from just discussing programming to also discussing programming domains, which detracts a bit from the core discussion.
My first comment already had domains in "pivoting" parts, so I didn't change the scope from comment to comment.
So domains is at the core of the discussion since the beginning, as the programming itself. At least that's how I formed my comment, and that's my intention while writing that comment.
> But programming is exactly the same. A programmer knows how to program
That approach works much better for more experienced senior devs. It takes time to go from knowing a particular language for a particular type of software to recognizing the universal patterns and picking up new languages and types of software project quickly.
I've been in it for around 15 years and feel pretty comfortable picking up a new language and jumping around between stack, frontend/back end/db, and languages. That takes time though and I still have plenty I could learn. 5 or 10 years ago I may have felt confident in that bit I'm not so sure I'd have been able competitive if the industry all went into the job market post-LLM layoffs (hypothetical?).
> That approach works much better for more experienced senior devs.
I don't think we're talking about junior developers here since the counter-example is a Cello player in orchestras and symphonies, those have to be considered "senior" as well no?
> I've been in it for around 15 years and feel pretty comfortable picking up a new language and jumping around between stack, frontend/back end/db, and languages.
Yeah, but that's comparing it to a musician switching instrument, instead of just a musician switching the place they play. The comparison then would be that a desktop app programmer does a todo app, or they do a calendar app. Both involving still the same instrument/area of programming, but different environments of sorts.
I do agree with your points here, but they don't align with the original quote I was responding to.
> But programming is exactly the same. A programmer knows how to program.
This would be akin to saying a cello player knows how to orchestra, and changing instruments wouldn't be a problem.
Software development in the frontend, backend, database, etc are very different skills especially when at a non-junior level. Expecting someone to jump between them without much to any training is like expecting a cellist to jump over to the violin.
I don't see the point. If/when that happens, programmers start doing the thing that comes next. The thread was about skills, ASM skills aren't irrelevant for doing C, C skills aren't irrelevant for doing Python and so on.
One-trick ponies aren't good programmers in the first place.
Many things that come next isn't programming as we know it.
Already today, see SaaS products for content management, CMS and no-code frontend.
There is zero programming, what one ends up doing is configuring SaaS products to connect among themselves, plug data sources, have AI algorithms process marketing data, export a generated UI into Vercel/Nelify and that is about it for 90% of customers.
But programming is exactly the same. A programmer knows how to program, and they can program all sorts of different things, with different languages, without having learn how to program from scratch each time. Most programming languages/projects are more similar to the rest, than different.
> A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM.
In your developer example, it would be more fitting to compare it to that they could build CRUD apps, or desktop applications, and it wouldn't be that much different. Plenty of programmers work in multiple "fields" at the same time, just like a Cello player might.