[the_af]

I had one junior guy who had been working for some years confess to me that he hadn't learned much in all his years of working. The reason? He was always chasing better pay, which in software development almost always means changing employers, and he never stayed long enough to learn the ropes of any job.

Granted, he was a junior developer, but I can see this applying to people with more "seniority" (measured in years, obviously).

[scotty79]

You become senior developer not by advancing technically. You just request salary that's too high for junior developer on your next job hop. If they want to hire you (and some will want to) they have to hire you as developer or senior developer. Also being older helps.

Once you are senior developer no one even dreams of offering you position of developer or junior developer.

[pyre]

I've been told that I would be in a entry-level position because I hadn't professionally worked with Python before, even though I had masses of experience in Perl, with Python being my free-time/side project language. Apparently I would be a "Senior Perl developer" but a "Entry-Level Python developer." (and this was at a start-up, not some big corp with an HR department)

[scotty79]

Yeah. What I said works for corporations. Start-ups tend to be as creative with ranks as with everything else.

[x0x0]

in your case, the right answer is, "k, good luck with that"

[nawitus]

How often did he change employers? I can't see how changing often somehow prevents learning. Even if he changes his employer every year, there should easily be enough time to learn.

[scarmig]

I'd guess that someone who jumps ship every year or two years will know more than someone of equivalent experience who's stayed at the same place for a decade. I learn the most the first six months at a new job.

Relatedly, there's the big benefit of much higher knowledge transfer of best practices in markets where job mobility is high. Individual companies, of course, end up giving up equal amounts of knowledge to peers and competitors, but ecosystems which support job mobility will outperform those that look down on it.

[null_ptr]

Sure, you learn the most in your first 6 months by quantity but that doesn't mean you learn the most valuable things. You won't learn anything of depth in half a year.

[nawitus]

Can you give some concrete examples of in depth learning that one can't learn in a year?

[encoderer]

Oh, lawd, help me.

Kidding. You ask a legitimate question. This is by no means a comprehensive answer, but...

1. Domain knowledge. I think most of us enjoy the creative and problem solving parts of software engineering. That takes domain knowledge and domain knowledge takes time. You will get an intro to your domain in a year, but mastery? I would bet against it.

2. Working on a hard project from start to finish and sticking around for the lessons learned after. This is just a math problem. You're useless for at least 30 days no matter how good you are. (More like 90 IMO...). So if you start working on a larger project with a new team, and that project takes 6 months, your year is ending rapidly.

3. Mastering truly large code bases. Not everything is a rails app. Some things are just hard. Mastery is difficult to achieve.

4. Engineering leadership. Even if you don't want to be on a management track, it's important for a seasoned, senior-level engineer to be able to lead/drive a project from start to finish.

...And I suppose you may think "But I do all of those." And maybe you do? Or maybe it's just really hard to see something that you're convinced isn't there.

[nawitus]

Domain knowledge is only useful if you work in the same domain year after year. That's often not the case. Atleast I've worked with three completely different domains the past year.

[watwut]

Impact of architectural and design decisions. How hard to decipher certain code parts you are so proud about today are a year later - my experience is that people used to work on small projects or who change projects a lot generate hard to maintain/understand code.

Learning non-trivial codebase often takes much more time. I worked on bigger projects and someone who worked there only six months would not be allowed to do bigger or core changes.

Then there is domain knowledge (finance, healthcare, law, etc) if you do that kind of software. Six months is enough to learn surface in anything non-trivial and everything is much more effective if developer already learned that.

Of course, last two points are not really valid for small projects world.

[Iftheshoefits]

Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine.

[sheepmullet]

Working on a big/long running project end to end. If you jump ship after a year you won't really understand the impact of a lot of the decisions you made months ago.

Most companies wont let you make any high risk or big impact decisions in your first year of employment with them (regardless of whether you get hired at a junior or senior or tech lead level).

Experience in solving the more difficult problems that require expertise with the companies particular stack and internal architecture.

And many more. There are ways to mitigate these problems but few do.

[the_af]

About once a year, sometimes less. The constant shifting of tech stacks, architecture, domain, and also that he didn't have to maintain anything long term meant he was constantly at junior level.