Re: path to professional musician (and obsolescence) (software vs. music careers)

This is a discussion on Re: path to professional musician (and obsolescence) (software vs. music careers) within the Theory and Concepts forums in category; (Opened up to a wider audience for more opinions. If you feel the subject is OT for programming and/or software, feel free to reset followups.) "Marc Sabatella" <marc{}outsideshore.com> wrote: >>>So there is good news awaiting >>>for you should you ever reach the point where a music career does work >>>for you. Your skills will never become obsolete. >> >> Hmmm ... I wonder how true this is in general. At some point, the >> demand for certain standards will go down, because people will prefer >> newer standards. If one doesn't learn the new standards, one will get >> less ...

Go Back   Application Development Forum > Theory and Concepts

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 06-23-2006, 02:21 AM
gds@best.cut.here.com
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

(Opened up to a wider audience for more opinions. If you feel the
subject is OT for programming and/or software, feel free to reset
followups.)

"Marc Sabatella" <marc{}outsideshore.com> wrote:
>>>So there is good news awaiting
>>>for you should you ever reach the point where a music career does work
>>>for you. Your skills will never become obsolete.

>>
>> Hmmm ... I wonder how true this is in general. At some point, the
>> demand for certain standards will go down, because people will prefer
>> newer standards. If one doesn't learn the new standards, one will get
>> less gigs.

>
>This is of course to some degree, but I think not to the same extent it
>is in a high-tech industry. When you need to learn some new pop songs
>to add to your repertoire, it takes all of a few *minutes* to learn a
>new tune.


This depends on the skill of the player and the complexity of the
music.

>Whereas when one needs to learn a new programming paradigm (which
>happens about every 2-3 years), it can take *months* to wrap your
>head around it.


Again, this depends on the skill of the software engineer and the
complexity of the new paradigm.

>While some pop songs are "throwaway" songs you probably won't be
>playing for more than a year, the cover bands around here still get
>quite a lot of mileage out "Celebration", "Mustang Sally", and any
>number of Motown songs from the 60's. Whereas these new programming
>paradigms you are constantly having to leanr generally have a shelf life
>of 5 years or so, tops. There is essentially *nothing* one might have
>learned, technology-wise, in the 60's, 70's, or even 80's that has any
>relevance whatsoever to todays' world.


As a counterexample, a project I recently worked on could have been
implemented using the DNS RFCs that were issued in the mid-1980s,
because the part of the spec that I needed to implement had not
changed since then. Neither had the parts of the C programming
language that I used, nor the format of Ethernet packets.

>Sure, basic programming skills are still good - that's more or less
>the equivalent of knowing your major scales. But the types of
>changes one endures in the tech world would be akin to someone coming
>out with a new keyboard design every three years or so with entirely
>different arrangements of black and white keys, and different numbers
>of notes per octave.


In my experience, what has been difficult is learning a new platform
that carries with it its own best common practices which are different
from the practices in the past platforms I've used. A good example
here is having to not only learn the Perl language, but also learning
the Perl style of programming (making use of hashes, regexps, etc.),
and what tools were and were not available (e.g. through the CPAN
archives). This isn't something that happens overnight, but it's not
as much a change in technology as a change in the way that technology
is used. Likewise, if one has been playing in certain styles, and one
is now forced to learn new styles (e.g. the dance band example), while
the notes are still the same, the new way in which the notes are
played needs to be mastered.

>There is just no comparison - there is *much* more "forward
>compatibility" of skill in music than there is in software.


Hmmm ... I'm not so sure I agree. But at any rate, it is interesting
to have this discussion. I remember about ten years ago, when people
were discussing how they planned to leave the software field for
music, I asked them how difficult they thought it would be to come
back if things didn't pan out in music. Most people either didn't
think it would be a problem or wanted to do music more than software
so it didn't matter. To a certain extent I have always been paranoid
about pursuing something other than the thing I really wanted to do,
even within the software field, because of how rapidly things change,
and the increased competition for jobs.

--gregbo
gds at best dot com
Reply With Quote
  #2  
Old 06-23-2006, 10:27 AM
Ed Prochak
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)


gds{}best.cut.here.com wrote:
> (Opened up to a wider audience for more opinions. If you feel the
> subject is OT for programming and/or software, feel free to reset
> followups.)
>
> "Marc Sabatella" <marc{}outsideshore.com> wrote:
> >>>So there is good news awaiting
> >>>for you should you ever reach the point where a music career does work
> >>>for you. Your skills will never become obsolete.
> >>
> >> Hmmm ... I wonder how true this is in general. At some point, the
> >> demand for certain standards will go down, because people will prefer
> >> newer standards. If one doesn't learn the new standards, one will get
> >> less gigs.

> >
> >This is of course to some degree, but I think not to the same extent it
> >is in a high-tech industry. When you need to learn some new pop songs
> >to add to your repertoire, it takes all of a few *minutes* to learn a
> >new tune.

>
> This depends on the skill of the player and the complexity of the
> music.
>
> >Whereas when one needs to learn a new programming paradigm (which
> >happens about every 2-3 years), it can take *months* to wrap your
> >head around it.

>
> Again, this depends on the skill of the software engineer and the
> complexity of the new paradigm.
>
> >While some pop songs are "throwaway" songs you probably won't be
> >playing for more than a year, the cover bands around here still get
> >quite a lot of mileage out "Celebration", "Mustang Sally", and any
> >number of Motown songs from the 60's. Whereas these new programming
> >paradigms you are constantly having to leanr generally have a shelf life
> >of 5 years or so, tops. There is essentially *nothing* one might have
> >learned, technology-wise, in the 60's, 70's, or even 80's that has any
> >relevance whatsoever to todays' world.

>
> As a counterexample, a project I recently worked on could have been
> implemented using the DNS RFCs that were issued in the mid-1980s,
> because the part of the spec that I needed to implement had not
> changed since then. Neither had the parts of the C programming
> language that I used, nor the format of Ethernet packets.
>
> >Sure, basic programming skills are still good - that's more or less
> >the equivalent of knowing your major scales. But the types of
> >changes one endures in the tech world would be akin to someone coming
> >out with a new keyboard design every three years or so with entirely
> >different arrangements of black and white keys, and different numbers
> >of notes per octave.

>
> In my experience, what has been difficult is learning a new platform
> that carries with it its own best common practices which are different
> from the practices in the past platforms I've used. A good example
> here is having to not only learn the Perl language, but also learning
> the Perl style of programming (making use of hashes, regexps, etc.),
> and what tools were and were not available (e.g. through the CPAN
> archives). This isn't something that happens overnight, but it's not
> as much a change in technology as a change in the way that technology
> is used. Likewise, if one has been playing in certain styles, and one
> is now forced to learn new styles (e.g. the dance band example), while
> the notes are still the same, the new way in which the notes are
> played needs to be mastered.
>
> >There is just no comparison - there is *much* more "forward
> >compatibility" of skill in music than there is in software.

>
> Hmmm ... I'm not so sure I agree. But at any rate, it is interesting
> to have this discussion. I remember about ten years ago, when people
> were discussing how they planned to leave the software field for
> music, I asked them how difficult they thought it would be to come
> back if things didn't pan out in music. Most people either didn't
> think it would be a problem or wanted to do music more than software
> so it didn't matter. To a certain extent I have always been paranoid
> about pursuing something other than the thing I really wanted to do,
> even within the software field, because of how rapidly things change,
> and the increased competition for jobs.


My impression is that this is the wrong comparison:
Software engineering to Musician.

I think the more analogous roles are
Software engineering to Composer

The Musician is more like a business person, learning word processing,
spreadsheets, and other custom applications. Some become very skilled
in those custom applications (occassionally "playing new, unique songs"
not known to the original designers).

Obviously the composer works in a medium that closely parallels
software code. the program (sheets of music) are fed to the execution
unit (player, band or orchestra) to produce the results. Symphonic
composers clearly work on parallel processors.

A composer today might still work in Classical style (a couple hundred
years old) while there might still be a few Programmers working on
COBOL. So while the rate of change is faster in software than music,
some old styles never go entirely out of fashion.

There are some breakdowns in the analogy but that is how I see it.
Ed

Reply With Quote
  #3  
Old 06-23-2006, 12:39 PM
felipevaldez@gmail.com
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)


Ed Prochak ha escrito:

....

> A composer today might still work in Classical style (a couple hundred
> years old) while there might still be a few Programmers working on
> COBOL. So while the rate of change is faster in software than music,
> some old styles never go entirely out of fashion.
>
> There are some breakdowns in the analogy but that is how I see it.
> Ed


perhaps one of the benefits in the music industry lies in the fact,
that wen a symphony "breaks", the "company" doesn't have to fight a 6M
LOC cobol app, to fix that damn y2k bug once and for all!

/f3l

Reply With Quote
  #4  
Old 06-23-2006, 01:32 PM
Marc Sabatella
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

<gds{}best.cut.here.com> wrote:

> "Marc Sabatella" <marc{}outsideshore.com> wrote:


>>When you need to learn some new pop songs
>>to add to your repertoire, it takes all of a few *minutes* to learn a
>>new tune.

>
> This depends on the skill of the player and the complexity of the
> music.


True. I am assuming we're talking about a professional-caliber player,
just as I was assuming we were talking about a professional software
engineer. And regarding complexity of music, remember, we're talking
here about the type of genres that actually *require* learning a lot of
new tunes just to stay marketable. That's basically one genre and one
genre only - pop. Very little of the music we're talking about is the
sort of stuff that takes more than a few minutes to learn, and
essentially *none* of it is so complex that it takes months or even
weeks.

>>Whereas when one needs to learn a new programming paradigm (which
>>happens about every 2-3 years), it can take *months* to wrap your
>>head around it.

>
> Again, this depends on the skill of the software engineer and the
> complexity of the new paradigm.


True - some programmers would take *years* to master these concepts.
Only the very best of the best can get the hang of some of these things
in only a few months. Of course, I'm not talking about every new
tehcnology that comes along. Some indeed only take minutes to learn -
but those come along more like *weekly*. I am talking only about ones
that actually a very skilled programmer months to deal, and I am saying
they really do come along every few years. Just in the eight years I
was employed in that business, here is a partial list of some of the
*major* new technologies I had to deal with:

- learning to write assembly code for an entirely new hardware
architecture
- learning to write assemble code for *another* entirely new hardware
architecture
- learning to design for dynamic loadable libraries
- learning to write software using a graphical user interface, using X10
- re-learning much of what I learned about GUI's for Motif
- learning a new programming language (C++_
- learning "object oriented programming"
- learning to write software using native language support
- learning to write software using a distrubted / multi-processor /
multi-user model
- then there was this new fangled thing called the "web"...

I would say that any single thing on this list is roughly equivalent in
complexity to learning a new instrument, if one somewhat related to one
you already know. Like, perhaps, learning French horn if you alreayd
know trumept. Sure, you can make a sound right away, but it will be
quite a while before you are playing at a professional level. In any
case, each of these is at leats an order of magnitude, if not two, more
complex than any tune I have ever learned in my life.

>>There is essentially *nothing* one might have
>>learned, technology-wise, in the 60's, 70's, or even 80's that has any
>>relevance whatsoever to todays' world.

>
> As a counterexample, a project I recently worked on could have been
> implemented using the DNS RFCs that were issued in the mid-1980s


Interesting choice of words - "could have been". So I take it that it
in fact was not. The reaosns why might prove relevant. But will
backpedal slightly. It's not that older technolgoies never have any
usefulness whatsoever. But someone who only knows the older
technologies is essentially unmarketable. It's extremely unlikely a
modern software company would hire someone who came in for an interview
and said he had been working in the same bank for the last 30 and had
been doing nothing COBOL programming on punch cards for their old IBM
mainframe. Bringing such a person up to speed on what is required in
today's world would be a gigantic undertaking. On the ther hand, a band
that was playing current pop covers wouldn't think twice before hiring a
keyboardist who said he had been playing nothing but 60's & 70's songs
for the last 30 years. Because they know it would be trivially simple
for him to learn the newer songs - and realistically, much of the
repertoire he had been playing is stuff they probably still play, too.

> In my experience, what has been difficult is learning a new platform
> that carries with it its own best common practices which are different
> from the practices in the past platforms I've used. A good example
> here is having to not only learn the Perl language, but also learning
> the Perl style of programming (making use of hashes, regexps, etc.),
> and what tools were and were not available (e.g. through the CPAN
> archives). This isn't something that happens overnight, but it's not
> as much a change in technology as a change in the way that technology
> is used.


I don't really care what you call it - it's a change you pretty have to
make, and on a pretty regular basis, in order to stay viable.

> Likewise, if one has been playing in certain styles, and one
> is now forced to learn new styles (e.g. the dance band example), while
> the notes are still the same, the new way in which the notes are
> played needs to be mastered.


Right. And in my experience, there is just no comparison. Technology
forces such changes more often, and the changes are more extreme, than
the music business does. It's true that if you wanted to master every
new genre that comes along, this could be daunting. But the music
business doesn't really require that. Technology, to be sure, doens't
require you learn *everything*, but I think it's safe to say that it
does force to spend *much* longer in ongoing retraining than music does.
Most professional musicians i know are doing essentially the same things
now they were 20 years - playing mostly the same tunes on the same
instruments in the same styles. At most they've added a style or two
and a couple of dozen new tunes. Whereas no one I know in the software
business is doing anything much related at all to what they were doing
20 years ago.

---------------
Marc Sabatella
marc{}outsideshore.com

Music, art, & educational materials
Featuring "A Jazz Improvisation Primer"
http://www.outsideshore.com/


Reply With Quote
  #5  
Old 06-23-2006, 01:36 PM
Marc Sabatella
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

> My impression is that this is the wrong comparison:
> Software engineering to Musician.
>
> I think the more analogous roles are
> Software engineering to Composer


Well, that might be treu if the starting point for this conversation
were software engineering. But it wasn't - the original context was, as
the subject line implies, the path one takes to becoming a professional
musician. The discussion was in rec.music.makers.piano only. In the
course of this discussion, I made the off-hand comment that at least in
the music business, unlike the software business, you don't have to
learn entirely new skills every couple of years. In music, I can make a
living playing the exact same songs I played 20 years. But I could no
longer make a living writing the same software I wrote 20 years ago.

---------------
Marc Sabatella
marc{}outsideshore.com

Music, art, & educational materials
Featuring "A Jazz Improvisation Primer"
http://www.outsideshore.com/


Reply With Quote
  #6  
Old 06-23-2006, 08:38 PM
goose
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

I'm rather late to this discussion, but I couldn't let this pass

Marc Sabatella wrote:

<snipped>

> Most professional musicians i know are doing essentially the same things
> now they were 20 years


Hell, most professional musicians just replay variations of a blues
progression in a different key and are none the worse off for it.

Developers rarely see the same pattern twice without shoving
it into a reusable module of some sort. I know I haven't coded
the same algorithm twice in production software for at least
the last 3 years, maybe longer ... after all, why would I re-code
something that already works?

goose
amateur guitar player

Reply With Quote
  #7  
Old 06-23-2006, 11:14 PM
gds@best.cut.here.com
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

"Marc Sabatella" <marc{}outsideshore.com> wrote:
><gds{}best.cut.here.com> wrote:
>> [learning new music] depends on the skill of the player and the
>> complexity of the music.

>True. I am assuming we're talking about a professional-caliber player,
>just as I was assuming we were talking about a professional software
>engineer. And regarding complexity of music, remember, we're talking
>here about the type of genres that actually *require* learning a lot of
>new tunes just to stay marketable. That's basically one genre and one
>genre only - pop. Very little of the music we're talking about is the
>sort of stuff that takes more than a few minutes to learn, and
>essentially *none* of it is so complex that it takes months or even
>weeks.


No, not months, but I have known some professional musicians who have
struggled (at least more than I thought they would) to play certain
styles of pop music. I suspect it is like software engineering; there
is a range of abilities, and also some people have strengths in areas
where others do not.

>> As a counterexample, a project I recently worked on could have been
>> implemented using the DNS RFCs that were issued in the mid-1980s

>Interesting choice of words - "could have been". So I take it that it
>in fact was not. The reaosns why might prove relevant.


The point I was trying to make is that the technology required to
implement this code existed in the mid-1980s. You could have frozen
someone in time back then who worked on this technology, woke them up
today, and handed them the assignment with the expectation that they
would complete it in a reasonable amount of time.

--gregbo
gds at best dot com
Reply With Quote
  #8  
Old 06-24-2006, 04:35 PM
Marc Sabatella
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

"goose" <ruse{}webmail.co.za> wrote:

>> Most professional musicians i know are doing essentially the same
>> things
>> now they were 20 years

>
> Hell, most professional musicians just replay variations of a blues
> progression in a different key and are none the worse off for it.
>
> Developers rarely see the same pattern twice without shoving
> it into a reusable module of some sort. I know I haven't coded
> the same algorithm twice in production software for at least
> the last 3 years, maybe longer ... after all, why would I re-code
> something that already works?


Touche! :-)

---------------
Marc Sabatella
marc{}outsideshore.com

Music, art, & educational materials
Featuring "A Jazz Improvisation Primer"
http://www.outsideshore.com/


Reply With Quote
  #9  
Old 06-24-2006, 04:37 PM
Marc Sabatella
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

<gds{}best.cut.here.com> wrote:

>>> As a counterexample, a project I recently worked on could have been
>>> implemented using the DNS RFCs that were issued in the mid-1980s

>>Interesting choice of words - "could have been". So I take it that it
>>in fact was not. The reaosns why might prove relevant.

>
> The point I was trying to make is that the technology required to
> implement this code existed in the mid-1980s. You could have frozen
> someone in time back then who worked on this technology, woke them up
> today, and handed them the assignment with the expectation that they
> would complete it in a reasonable amount of time.


I realize that. But my overall point remains. The situation you are
describing is the exception, not the rule. The guy you woke up after 20
years might be able to successfully complete that one assignment, but
he'd still be of extremely limited viability overall in the today's job
market. Whereas a musician who woke up after a 20-year siesta could be
gigging that night.

---------------
Marc Sabatella
marc{}outsideshore.com

Music, art, & educational materials
Featuring "A Jazz Improvisation Primer"
http://www.outsideshore.com/


Reply With Quote
  #10  
Old 06-24-2006, 05:11 PM
M. Rick
Guest
 
Default Re: path to professional musician (and obsolescence) (software vs. music careers)

>Whereas a musician who woke up after a 20-year siesta could be gigging that
night.

That's incorrect. A rock musician 1956 would have a hard time gigging with
a 1976 rock band, unless he's playing oldies. Same story with a jazz
musician 1930 - 1950, or a rap/hip-hop musician 1986 - 2006.


Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 06:19 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.