I recall a regular piece of advice for software engineers: “change your job every two years.”

There’s innumerable Google results for this, even from as recently as 2022 — but none of them really seem that high-quality?

I’m really, really enjoying my current (somewhat unusual, hard-to-replicate) position; am about a year and a half into it; but I also don’t want to relax into that and have it cost me in the long-run, career advancement wise.

So, what’ve y’all been doing? Especially in the post-pandemic/fully-remote world, does that advice still apply?

  • If your skill set is just getting up to speed, that seems limiting to me.

    I know I’ve ignored many resumes with people who jump jobs every 2 years because those first 2 years you’re getting paid to be varying degrees of incompetent and useless within a team. Moreover, someone who leaves every 2 years will never be in a position where they actually have to deal with long-term problems.

    If you don’t think you’re getting paid enough, well enough go out and do some capitalism. But going into any given job with the intention of quitting almost immediately to optimize your pay, I don’t think that’s necessarily the right way of doing it either. Employment is actually a 2-way street in good companies.

    • I can’t quite wrap my head around the claim that a new hire is (should be?) useless for two years — I’d say I had my head wrapped fairly well around my primary corners of the codebase within six-ish months; and at my current year-n-six, I’ve had reaso to (at least cursorily) trawl through prolly ~halfish of our several million lines of OCaml — I feel I can speak fairly knowledgeably about all sorts of angles of this organization’s architecture, make directional decisions about the interfacing surfaces between Our Part and the rest of the org, etc, etc.

      Similarly, that feels fairly true across the team: doesn’t take people more than a couple months to onboard; and they’re making major architectural decisions within about a year.

      Is the difference perhaps in organization size (we’re <100; maybe larger teams are slower? More code, more bureaucracy?) Or, failing that, I’m tempted to crow about the successes of pragmatically-applied FP — it’s pretty trivial to onboard into some new section of our product, thanks to OCaml’s strengths vs. weaknesses … hm.

      One other possible explanation: I do suspect my organization attracts above-average talent … but I also meta-suspect that suspicion is self-serving, so … :P