He said it took that time to "to understand how all the moving pieces of the business data flow fit together" which doesn't seem to me to be that long at all. Not every employer is an "Uber for X" where you can understand the product concept in a day or two. I've had jobs where I didn't feel really comfortable with my understanding of the entire scope of the business until I'd been there a couple of years.

> I've had jobs where I didn't feel really comfortable with my understanding of the entire scope of the business until I'd been there a couple of years.

I've had that problem, too, but I considered it a failure of architecture and design, not an inherent property of the space we were operating in. Often this is a sign of a lack of separation of concerns at the system level.

Yeah, I don't think so.

It's not "have something of an understanding of what we're doing here", it's "feel comfortable, and _competent_, in the interactions across the code base, why some approaches might not work or have failed in the past, etc.

I'd totally agree with three to six months before that comfort sets in.

Six months really isn't uncommon at all. Almost every company has a weird legacy codebase you have to figure out. Unfortunately it doesn't generalize very well -- figuring out why some weird COM interface has 14 inheritance dependencies or what weird JSON file is driving behavior is part of the job. It's just, uh, the part that kind of sucks.

Depends on developer I one took over a super nich system written in a new language (Pl1g) and using bleeding edge tech (Map reduce in the 80s) took me < than a month to get productive.