[Balgair]

Man, I wish that were true! I'd love to sit in one place for 2 years. I can't seem to find a job that will last more than 18 months. Some will, but the pay is stagnant and there are no promotions. You must job hop. As one anecdata point, employers all seem to know that diagonal promotions are the standard now and they don't fault you at all. If they did, well then they gave me a red flag, if anything.

[wils1245]

It's a good point. The reasoning behind the moves matter. There's a huge difference between switching jobs because a better opportunity is available, and switching jobs frequently for lateral moves.

It would probably be more accurate to say that it's a yellow flag, requiring a bit of explanation but not necessarily a bad thing. I find the pattern of switching every 6 months for (presumably) ~10 years to be pretty extreme and difficult to explain, though. Not to mention exhausting! How many job interviews must that have taken?

[Balgair]

> Exhausting

No kidding! Here I am complaining about 18-24 month moves and the OP was moving in 1/3rd to 1/4th of the time. Whatever uppers he's taking can't be good for you. Either that or he has the best spouse in history.

Still, honestly, it's a yellow flag. If the guy is good, 6 months may be just fine. But it's a cautious interview I'd think.

[khedoros1]

I've been at this job 2 years, and for 7 years at the job before it. 5-6 years of the previous job were great (promotions, raises, etc). The current job is stagnating; I can't stay here much longer.

[nejenendn]

18 months is a lot different than 6 months. You can’t even ramp up fully on a codebase in 6 months, arguably.

[mnm1]

Having worked at over a dozen places in my career, I've never encountered a code base that takes longer than three months to master let alone ramp up on. This includes shitty code, overly complex code, and well written code. I'd say the challenge is staying interested and challenged after three months.

[jondubois]

The more you change projects, the faster you are able to ramp up to new code bases. It takes me 1 or 2 week to understand the code base well enough so that I can start contributing - This is pretty standard for many contractors like me. Adapting to unfamiliar code bases is a skill on its own.

You don't need to master the whole code base in order to make high quality contributions but you need to be aware of what you don't know and focus your efforts on the parts that you understand really well while learning more about the parts that you don't understand. You can learn as you go throughout for the first 3 months.

If you're already familiar with the framework that the company is using, that's already a big step. Peer review can help as well.

Most good companies have similar coding styles and follow similar practices but they might have different requirements when it comes to testing, security, scalability, Agile/Scrum, etc...

[Balgair]

> for many contractors like me

Ooooooh! Yeah, I should have caught that earlier. 6 months now makes a lot more sense.

[khedoros1]

You've said shitty and complex code...how about voluminous code, or old code? The main product that I work on has about 2 million lines of C, C++, and Java code in the core of the system, then about 20 plugins ranging in size from a few thousand lines to a few hundred thousand lines.

We basically hire for sections of the codebase. It's pretty common for developers to discover the existence of an area of code that they haven't had to touch before and were unaware of the existence of even years after starting to work here.

[Balgair]

2 Million! Wow! Now that is a LOT of code. I can't imagine anyone being able to master all of that and then keep up with the changes. That would take a decade at least!

For reference, the Bible has ~30k verses in it. A verse isn't a line of code, but I'd say mastering the Bible is a good benchmark for equivalent complexity to coding. If anything the Bible is more straightforward than a 2 million line code base.

[khedoros1]

> 2 Million! Wow! Now that is a LOT of code. I can't imagine anyone being able to master all of that and then keep up with the changes. That would take a decade at least!

The people who'd I'd say mastered the core codebase were the people that wrote it. Over the last couple years, they've been laid off one by one, but most of them have been around for 15-18 years already (the prototypes were built around 1998, and I think that the current code descends from stuff written in 1999). I've been around it for about 8 years now, in total. I wrote most of the current build system, a lot of the packaging code, the initial version of two or three of the plugins, and individual features in a few of the others.

The Bible has a distinctly different kind of complexity, though. Social complexity, rather than technical. A line of code has an unambiguous meaning, with other lines of code, the OS, and the underlying hardware providing an unambiguous context. A verse of scripture can have multiple simultaneous meanings, and the context is provided both by surrounding text and by the millennia-old cultures that the verses were written in. I'm not sure how I'd make the comparison.

[slackstation]

Why have everyone know all of 2M lines of code? Programming is about abstraction, knowing what a subsystem does, what it's responsible for should be adequate most of the time until you need to fix something inside it.

We aren't doctors, we just need the skills to figure things out and fix them quickly.

[khedoros1]

The system's more broad than deep, mostly. Lots of functionality covered, but for the most part, the abstractions aren't super-deep.

My point was that someone can ramp up quickly on a portion of the system and have a vague idea of other parts of it, but "mastering" it covers too much code to do it in a reasonable time. Each plugin introduces special cases for the data flow, and the plumbing for that ends up running through the whole system.