Working on large teams is definitely a new experience. You are no longer going to be able to understand or probably even have access to the entire code base that makes up your product. You will likely have to go through peculiar process controls that don't really relate to what your team is doing or how they do it, etc.
I am still getting a grasp on this subject myself but I think my key take away so far is:
- Specialize in your area
You don't need to understand the entire eco-system, and trying to do so can actually hinder you especially when initially ramping up. When starting out I would recommend focusing on understanding just your code and the logical boundaries off how your code interact with other teams code (Shared Databases, Caches, Soap/Rest Services, File systems, etc.) and whom your up and downstream dependencies and dependents are.
- Become an expert at finding the expert.
In large orgs there are simply too many moving cogs for any one person to have intimate knowledge about the internal workings of each discrete system. Becoming really good at figuring out how to find the one person or wiki page that does have the answers you need to solve your own product or process issues is really a skill set you will want to pick up.
This means knowing a little bit about your org structure, and who to ask questions about to get information on a specific subject or who to ask questions on whom to ask questions on who to ask questions on a particular subject.
Knowing and being on good terms with your software architects, project managers, leads developers etc. all comes in very handy here.
Relax. Organizing large software projects is hard. It's a thing. The expectations on how you go about doing things and getting answers is different. The skillsets are a little bit different from the ones you use on smaller teams but you're a go-getter and just like everyone else when they made the jump to large teams you'll get the knack for it. ^_^
As far as design patterns and the technical stuff.
I don't think there are many major changes on the design patterns used on small projects versus large projects. A factory is a factory is a factory right?
At the same time to deal with the large number of people involved there tends to be push to compartmentalize specific components of the application so that they are as independent and decoupled from other components as possible. In my current role I see a lot of N-Tier diagrams with plenty of little boxes denoting specific product functionality. for the most part each team is responsible for one or more of those specific boxes. So we get very precise about what our components ins/outs are and requirements since we cant just change those details willy nilly due to the layers of people involved in making changes.
My division doesn't take this to the extreme that some other businesses do but if you are working on a large distributed solution rather than a single large program like say ubuntu or windows you might be digging into a Service Oriented Architecture such as the model amazon has going on in order to facilitate this seperation of concerns.
Much like the n-tier architecture diagrams with specific logical components, SOA is very handy in that if you do things in the correct manner and implement solid interface version control mechanisms and communicate upcoming interface changes upfront you can enable multiple teams to work on VNext solutions in parallel by working against stubbed endpoints and predetermined interfaces until some point down streams when the various services are functional enough to begin connecting to directly to one another to begin serving actual respones rather than canned stub/mock responses.
There are also some very interesting processes around development environment setup when working on services with interdependencies between services that are all being developed in parallel and how you can insure each teams or the shared companies dev enviornment has the latest bits possible deployed with out introducing major functional breaks that block other teams.