38
Is the old advice to change companies every two-ish years still the best practice for career advancement?
(self.experienced_devs)
this post was submitted on 27 Jun 2023
38 points (100.0% liked)
Experienced Devs
125 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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