3 ms·

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. Consider a

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. Consider a developer versed in CRUD apps obsoleted by a code generator AI and, they need to pivot to something different. e.g.: UI, simulation, games or system. That pivot will require different languages, different mindset, different knowledge (simulation and games needs different sets of deep math, UI needs new tools and paradigms, system requires a different knowledge stack from hardware to lower levels of OS, etc.). They need to learn, get experience, go through hoops, etc. A musician can play in an orchestra pit in 2PM and play with a symphony at 8PM. They just need a little rest and a meal in between (had friends doing exactly that). If said musician is forced to change their instrument. e.g. from cello to tuba, or cello to timpani, the effect will be the same as software developer's. Some things would carry over, but others needs to be replaced completely.

diggan 2y ago
> 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.
- bayindirh 2y ago
  > But programming is exactly the same. 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.
  - diggan 2y ago
    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.
    - bayindirh 2y ago
      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.
      - diggan 2y ago
        But if you're talking about domains in the programmer's example, you'd have to do the same for the cello player's example. So in that case it would be that the cello player could seamlessly (without training) change between genres for example, which clearly isn't true.
        bayindirh 2y ago
        Changing genres are easy. Some of my orchestra mates were multi-genre (jazz/classic for example). I used to play metal and classic back in the day. What’s hard is changing instruments, which I have given as an example in one of my comments. Yes I did go thorough that one, too.
- _heimdall 2y ago
  > 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?).
  - diggan 2y ago
    > 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.
    - _heimdall 2y ago
      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.
- pjmlp 2y ago
  AI will replace programming languages, as optimizating compilers replaced Assembly programmers. Anyone that thinks code generation will stay as is, is fooling themselves.
  - whtsthmttrmn 2y ago
    Well yea, of course you can say that on an open ended timeline.
    - pjmlp 2y ago
      Well, some apparently still think code generation won't go away, like those Assembly devs when Fortran was new. Even if we consider a similar timeline, it means we have about 50 years to enjoy programming as we know it.
  - qsort 2y ago
    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.
    - pjmlp 2y ago
      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.
      - qsort 2y ago
        For all those SaaS products today, you see legions of consultants, system integration projects, a cottage industry for customizations... The skills aren't irrelevant.
mjr00 2y ago
> Consider a developer versed in CRUD apps obsoleted by a code generator AI and, they need to pivot to something different. e.g.: UI, simulation, games or system. That pivot will require different languages, different mindset, different knowledge (simulation and games needs different sets of deep math, UI needs new tools and paradigms, system requires a different knowledge stack from hardware to lower levels of OS, etc.). This is nothing new, though. There used to be very lucrative job titles like "webmaster" or "web developer" whose daily work consisted of creating bespoke, static websites created with raw HTML and CSS. Whenever a customer wanted their website updated, even if just textual content updates, they got to bill a few hundred bucks to copy and paste the text into their site and upload the updated files onto whatever shared web hosting they were using. Tools were invented: first WYSIWYG editors like Microsoft Frontpage, then content management systems so users could update their own websites, then full-on SaaS website designers like Wix, and now the current state of, well maybe your business doesn't even really need a website because you can just make a Facebook page instead. When I was going to university in 2005, I was heavily warned by (cough) "experts" that due to this, plus the imminent wave of outsourcing of "IT" to low-cost developers in India and Bangladesh, that learning web-based software development was a dead-end career path, and US software developer salaries would cap out at $75k unless you got into management... yeah. So, yes, you'll need to pivot as you always have in the industry. Any potential threat from AI isn't anything new. And it's not nearly as impactful as switching from playing cello to piano.
saltcured 2y ago
I feel like you're ignoring the amount of training that an expert musician does to learn a specific piece of music and maintain their proficiency in it. For the most part, they don't go to professional gigs and play something novel. Traditional musicians have a whole live or real-time performance aspect as do athletes, dancers, etc. I think the amount of time they spend preparing for this can be similar to the time we spend working on one programming task. Bigger problems take more preparation. The difference is we don't have to then do a live performance after we've figured out how to program it. We just accumulate a recorded artifact and ship it, rather than doing a live recital after we've figured out all the difficult bits. So it's difficult to draw parallels. Programmers have more in common with writers, painters, and sculptors who all work on a tangible artifact that is delivered after the fact and which acts as an accumulator of time-shifted work product. Some crafts, like glass blowing, are more like live music in that you develop a skill but then have to make a real-time performance each time you produce the artifact.
- zachwill 2y ago
  An insightful comment! Had never drawn those parallels before -- great call.
- bayindirh 2y ago
  Actually no. When you're learning a piece from scratch, you start with 60bpm or slower and slowly polish your performance and reach to the normal speed of the piece. If you're going to perform with an orchestra, you also rehearse a lot. We started 14 weeks before the actual concert date (used to play double bass in a symphony). Learning the instrument is akin to learning the programming language. Music theory is the same thing as programming languages / intro to computation courses. You pass through them once and revisit as needed. Not everyday. However, when you finish a piece, 95% of the skill required to play it again is permanent. You just rehearse it a couple of times and, viola. The performance is there. The constant exercise part is very on par with what programmers do every day. You either code (work) or playfight/practice (hobby projects). Also, composers and genres have similar structures in their pieces, so when you get used to them, you can just fly through them, even if you play for the first time. There are a couple of comments which say that we're talking about senior programmers here. Senior musicians can play what they see in the first pass, or just improvise/remix what they hear for the first time (see [0]). So, in most cases, the partitions in front of the musicians are cheat sheets. I remember just looking at the section and playing half (sometimes most) of it without even looking to it. The live/improvised performance is akin to "hacking" in programming. I had my mentor who taught me playing double bass had to improvise a bridge section of a piece because he forgot that specific part. He said that since he knows the motifs, he bridged the part on the fly, in a solo performance in conservatory, and he got a pass because how he handled it. This is how we hack something together when we're in a rough spot and dig our way out of it by knowing what we're doing, but improvising and trusting the process. So, I draw these conclusions from 10+ years of live concerts and 15+ years of professional sysadmin/programming/research work. [0]: https://www.youtube.com/watch?v=3pYHCGYJbw0 https://www.youtube.com/watch?v=3pYHCGYJbw0

diggan 2y ago

> 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.

bayindirh 2y ago
> But programming is exactly the same. 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.
- diggan 2y ago
  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.
  - bayindirh 2y ago
    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.
    - diggan 2y ago
      But if you're talking about domains in the programmer's example, you'd have to do the same for the cello player's example. So in that case it would be that the cello player could seamlessly (without training) change between genres for example, which clearly isn't true.
      - bayindirh 2y ago
        Changing genres are easy. Some of my orchestra mates were multi-genre (jazz/classic for example). I used to play metal and classic back in the day. What’s hard is changing instruments, which I have given as an example in one of my comments. Yes I did go thorough that one, too.
_heimdall 2y ago
> 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?).
- diggan 2y ago
  > 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.
  - _heimdall 2y ago
    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.
pjmlp 2y ago
AI will replace programming languages, as optimizating compilers replaced Assembly programmers. Anyone that thinks code generation will stay as is, is fooling themselves.
- whtsthmttrmn 2y ago
  Well yea, of course you can say that on an open ended timeline.
  - pjmlp 2y ago
    Well, some apparently still think code generation won't go away, like those Assembly devs when Fortran was new. Even if we consider a similar timeline, it means we have about 50 years to enjoy programming as we know it.
- qsort 2y ago
  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.
  - pjmlp 2y ago
    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.
    - qsort 2y ago
      For all those SaaS products today, you see legions of consultants, system integration projects, a cottage industry for customizations... The skills aren't irrelevant.

mjr00 2y ago

> Consider a developer versed in CRUD apps obsoleted by a code generator AI and, they need to pivot to something different. e.g.: UI, simulation, games or system. That pivot will require different languages, different mindset, different knowledge (simulation and games needs different sets of deep math, UI needs new tools and paradigms, system requires a different knowledge stack from hardware to lower levels of OS, etc.). This is nothing new, though. There used to be very lucrative job titles like "webmaster" or "web developer" whose daily work consisted of creating bespoke, static websites created with raw HTML and CSS. Whenever a customer wanted their website updated, even if just textual content updates, they got to bill a few hundred bucks to copy and paste the text into their site and upload the updated files onto whatever shared web hosting they were using. Tools were invented: first WYSIWYG editors like Microsoft Frontpage, then content management systems so users could update their own websites, then full-on SaaS website designers like Wix, and now the current state of, well maybe your business doesn't even really need a website because you can just make a Facebook page instead. When I was going to university in 2005, I was heavily warned by (cough) "experts" that due to this, plus the imminent wave of outsourcing of "IT" to low-cost developers in India and Bangladesh, that learning web-based software development was a dead-end career path, and US software developer salaries would cap out at $75k unless you got into management... yeah. So, yes, you'll need to pivot as you always have in the industry. Any potential threat from AI isn't anything new. And it's not nearly as impactful as switching from playing cello to piano.

saltcured 2y ago

I feel like you're ignoring the amount of training that an expert musician does to learn a specific piece of music and maintain their proficiency in it. For the most part, they don't go to professional gigs and play something novel. Traditional musicians have a whole live or real-time performance aspect as do athletes, dancers, etc. I think the amount of time they spend preparing for this can be similar to the time we spend working on one programming task. Bigger problems take more preparation. The difference is we don't have to then do a live performance after we've figured out how to program it. We just accumulate a recorded artifact and ship it, rather than doing a live recital after we've figured out all the difficult bits. So it's difficult to draw parallels. Programmers have more in common with writers, painters, and sculptors who all work on a tangible artifact that is delivered after the fact and which acts as an accumulator of time-shifted work product. Some crafts, like glass blowing, are more like live music in that you develop a skill but then have to make a real-time performance each time you produce the artifact.

zachwill 2y ago
An insightful comment! Had never drawn those parallels before -- great call.
bayindirh 2y ago
Actually no. When you're learning a piece from scratch, you start with 60bpm or slower and slowly polish your performance and reach to the normal speed of the piece. If you're going to perform with an orchestra, you also rehearse a lot. We started 14 weeks before the actual concert date (used to play double bass in a symphony). Learning the instrument is akin to learning the programming language. Music theory is the same thing as programming languages / intro to computation courses. You pass through them once and revisit as needed. Not everyday. However, when you finish a piece, 95% of the skill required to play it again is permanent. You just rehearse it a couple of times and, viola. The performance is there. The constant exercise part is very on par with what programmers do every day. You either code (work) or playfight/practice (hobby projects). Also, composers and genres have similar structures in their pieces, so when you get used to them, you can just fly through them, even if you play for the first time. There are a couple of comments which say that we're talking about senior programmers here. Senior musicians can play what they see in the first pass, or just improvise/remix what they hear for the first time (see [0]). So, in most cases, the partitions in front of the musicians are cheat sheets. I remember just looking at the section and playing half (sometimes most) of it without even looking to it. The live/improvised performance is akin to "hacking" in programming. I had my mentor who taught me playing double bass had to improvise a bridge section of a piece because he forgot that specific part. He said that since he knows the motifs, he bridged the part on the fly, in a solo performance in conservatory, and he got a pass because how he handled it. This is how we hack something together when we're in a rough spot and dig our way out of it by knowing what we're doing, but improvising and trusting the process. So, I draw these conclusions from 10+ years of live concerts and 15+ years of professional sysadmin/programming/research work. [0]: https://www.youtube.com/watch?v=3pYHCGYJbw0 https://www.youtube.com/watch?v=3pYHCGYJbw0