| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
| |||
| |||
| (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 |
|
#2
| |||
| |||
| 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 |
|
#3
| |||
| |||
| 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 |
|
#4
| |||
| |||
| <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/ |
|
#5
| |||
| |||
| > 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/ |
|
#6
| |||
| |||
| 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 |
|
#7
| |||
| |||
| "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 |
|
#8
| |||
| |||
| "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/ |
|
#9
| |||
| |||
| <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/ |
|
#10
| |||
| |||
| >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. |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.