I'm not totally pessimistic, I was really referring to the knowledge that doesn't translate to a new job. After 10 years and working deeply with a lot of stuff I am among the 'Do you know..?' types for questions about the inner workings of the product. That is really just baggage.
Processes, experiences probably can be reapplied elsewhere. But having read some C files from 1996 (I .. didn't work at that company at that time), reciting the product's API every evening after dinner and being intimately familiar with the current .Net code base is time invested in this job and this job only.
>> But having read some C files from 1996 (I .. didn't work at that company at that time), reciting the product's API every evening after dinner and being intimately familiar with the current .Net code base is time invested in this job and this job only.
I disagree with this, you gain something working closely with a legacy code base. After you've done it once, it becomes easier when you have to it again, although if you do it more than a few times, it gets REALLY old. I distinguished myself at my last two jobs by jumping into and becoming proficient with the legacy code in short order.
I'm not totally pessimistic, I was really referring to the knowledge that doesn't translate to a new job. After 10 years and working deeply with a lot of stuff I am among the 'Do you know..?' types for questions about the inner workings of the product. That is really just baggage.
Processes, experiences probably can be reapplied elsewhere. But having read some C files from 1996 (I .. didn't work at that company at that time), reciting the product's API every evening after dinner and being intimately familiar with the current .Net code base is time invested in this job and this job only.