[somekyle2]

This seems generally true in my experience. Another aspect of this, from personal experience: while it may be easy to move around in a large organization, you risk losing reputational capital. I had a habit of building reputation in some team/platform, then after I no longer found it engaging or there was enough turnover/focus shift, I'd ask to transition to a wildly different team for a new challenge. It _is_ fun, but if you opt to start as an IC and work your way up, you're sorta letting the ratchet slip, and if you do it every couple years you may have broad experience, but your reputation (and likely level) will be well below where it could be.

Thus, unless you can ramp to expertise really quickly to leverage your skills developed elsewhere, I'd recommend (perhaps obviously) to try to move to peripheral teams where your skills and relationships transfer as much as possible.

[hinkley]

There is a time honored tradition of blaming the last person for all of your problems, or at least any they had proximity to.

Somewhat awkward if you later see them in a meeting.

[somekyle2]

Quite true! Having been fairly instrumental in a few areas that I'd eventually moved on from, it was always interesting to see some of my trademark accomplishments become The Old Thing We're Trying To Replace (or even just The Big Thing We Have To Maintain); gave me a lot of empathy for prior contributors of code I ended up inheriting. I tend to assume that the old thing seems dumb because of the constraints when it was written and changing requirements over time; if a tool made by one person in a few weeks seems hopelessly naive to the medium sized team investing a few quarters in replacing it a few years later, that seems to be a rousing success for the original author.

[Terr_]

>replacing it

Over the years I've come to say "design for deletion" when it comes to internal code. This means meaning more emphasis on making things straightforward to rip and out and replace, as opposed to stuff that is "configurable" or "extensible" etc.

As a junior developer, I know I spent too long on some things thinking that I could make a piece of Forever Art by adding ways for future developers to tweak its behavior.

[hinkley]

The problem I often run into is people equating “we need to replace this” with “it never should have existed”.

Whether it needs to be replaced or not has absolutely nothing to do with how it got there in the first place. Yes, maybe the company avoiding bankruptcy due to your clever kludge. Thank you for your service. But today we are tripping over your kludge left, right, and center. So it gots ta go.