3 ms·

I'm not sure if I'm dumb or something, but I don't see the difference in your examples. First: Musician used to play orchestra, but now automation might replac

by diggan 2y ago

I'm not sure if I'm dumb or something, but I don't see the difference in your examples. First: Musician used to play orchestra, but now automation might replace them. Musician can take their skills elsewhere as they still posses them Second: Software developer (for example) used to write CRUD apps, but now automation might replace them. Developer can take their skills elsewhere as they still posses them. I don't see how in the second example, somehow the skills as "destroyed" while in the first example, they're used somewhere else instead of destroyed.

bayindirh 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. 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.
- 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
bad_haircut72 2y ago
If automation takes your job, there are now less overall positions and more people competing for them (you and everyone else who got laid off) so its not like you can "just" take your skills elsewhere, there may be nowhere else to go.
- diggan 2y ago
  How is that different from the hypothetical Cello player? Once enough automatized cello players exists, how could they go anywhere else?
  - bad_haircut72 2y ago
    Thats exactly the point I was trying to make.
- whtsthmttrmn 2y ago
  This is assuming we're at some sort of job ceiling and no new jobs will ever be created.

by diggan 2y ago

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

bad_haircut72 2y ago

If automation takes your job, there are now less overall positions and more people competing for them (you and everyone else who got laid off) so its not like you can "just" take your skills elsewhere, there may be nowhere else to go.

diggan 2y ago
How is that different from the hypothetical Cello player? Once enough automatized cello players exists, how could they go anywhere else?
- bad_haircut72 2y ago
  Thats exactly the point I was trying to make.
whtsthmttrmn 2y ago
This is assuming we're at some sort of job ceiling and no new jobs will ever be created.