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?

  •  SJ_Zero   ( @SJ_Zero@lemmy.fbxl.net ) 
    link
    fedilink
    English
    11
    edit-2
    1 year ago

    I feel like you should be careful trying to just optimize for the most money.

    2 years seems really short, like your boss would just finally have you producing good code and knowing all the specific pitfalls of a certain codebase and then the door slams shut behind you.

    I come from a different culture, but I’ve found 4 years is the right cadence for me. If you’re keeping your nose to the grindstone and doing what you’re supposed to, it seems like about every 4 years everything ends up changing.

    Doesn’t even mean leaving. Often it means advancement.

    • I don’t know, if I can get a really nice pay raise by going somewhere else and am not getting any pay raise where I am despite finally being able to “produce good code” I’d be angry and want to leave. You should do good work, yes, but this mentality of the fact that you have some degree self sacrifice being somehow more important than salary is naive and exploitative as well. If your company values you then you pay should reflect that. It isn’t charity. (Unless you actually are working for a charity but that’s different haha.)

      • 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