What I learned working for a "big" company - part 1

There are undoubtedly many paths one can follow in their career as a programmer; and it's not about choosing backend, frontend, or an specific language to work with: it's about one's attitude and choices when it comes to development.
However, often the environment in which you work has a lot of influence on which kind of dev you are going to become, as well as how long it will take for you to advance on your career. One of the decisive factors is the size of the company you work for.

Part 1: How a company shapes developers

As said previously, the environment in which you spend a lot of time has a great influence over you and your work. Some companies place emphasis on skills that other companies undervalue. This dynamic is responsible for shaping devs differently across different environments, and it is something important to understand because the more adaptable you are, the greater the chances to be successful in your career.

1- The generalist vs. the specialist

I'm the kind of developer who likes to know how an application work, end-to-end - from the CSS to the choices for cloud providers. Although it's fun to do so in my personal projects, often it's not something possible to do in a big company.
However, this is not exactly a bad thing. As applications grow in size, it becomes more productive - for the devs and managers - to split responsibilities between scope-specific teams. It keeps them focused on a smaller scope, making it easier for new devs to get the context and quickly start to contribute to the codebase.

It means less space for fullstack, generalist devs and more space for professionals who act on a more specific scope and are used to solve similar problems. In my last job I was the first fullstack on the team, which created some minor friction since this kind of role was something completely new in an environment where people worked in strictly defined scopes.

2- Soft and hard skills

Before my first experience as a developer, I thought hard skills were the decisive factor when it comes to advancing quickly in seniority. Is it true? Well, it depends.
Acting on a smaller scope means having a smaller surface under your/your team's responsibility. In practice, it implies having different services under the responsibility of different people - and since many of these systems are interconnected, the people must be as well.
It creates a contradiction - in theory, splitting responsibilities should increase teams' productivity and reduce coupling. But in practice, this is not always the case, because sometimes solving a cross-platform problem requires talking to a lot of different people. You will have to roll up your sleeves and prepare to make all these people understand your problem and look for a solution together.
Obviously, this will require much more than bare technical skills - it will demand from you a concise and effective communication.

Therefore, the larger the company, the greater the need to evolve your skills beyond code and focus on making your communication effective and positioning yourself proactively. This is the key to being a professional who makes a difference in this kind of extremely interconnected environment.

Sync and async work

Sometimes calls cannot be emails.
And sometimes you'll have to bet on sync communication to make things flow quicker, specially when there's no available documentation on sight.

However, this is precisely the point where many managers fail - identifying when sync communication is really necessary. So, you will have to be prepared for meetings, calls and sometimes unnecessary Scrum ceremonies. The greater the company, the greater the probability of this happening, because management teams tend to be more distanced from developers and thus have a distorted perception of which things are really important.

The lone programmer vs. the System Design Engineer

I had a colleague who used to put a great emphasis on how "developers" are different from "architects/engineers". Although I disagree in parts, there are many contexts in which this analogy is true. Specially in the context of this post - big companies.

Can you be both? Yes, you can.
But the environment in which you are usually tends to favor one type over another.
Usually, more "structured" software will imply on less worries about details. This is often the path that corporations follow as they grow - they abstract things over time to gain productivity and reduce the required boilerplate to develop things.
You'll see it in the use of internal libraries or in the adoption of more opinionated frameworks; they reduce the quantity of micro technical decisions and favors the second type over the first one. But they also represent a very important downside of working in a big company: you'll have to take less important decisions.
And it is very good for businesses, but sort of bad for developers, specially if your desire is to learn as much as possible. You'll have less context under your hands and therefore, less opportunities to make mistakes and learn from them.

Finally, it is important to keep in mind that the points listed above are not inflexible rules - rather, they are trends that I have personally been able to notice while working in and getting to know the environment of different companies.
As a developer, the bottom line is to be as adaptable as possible within your context, and especially to have a sense of what to expect beyond the code in each of the companies you set out to work for.