Welcome to your new job!
From a career point of view, this is the shortest, because there is so much I’m still learning myself, and because my experience is so far largely bound to one team at one company. However, I’m in a role that interfaces with other engineering teams regularly, in offices around the globe, and have seen friends make the same transition to other tech firms.
From a technical point of view, I’ve been coding for my whole life, but it’s always been solo or on school projects. Looking back after year one, I’ve learned an incredible amount, and I feel like I’m learning faster every day. Here’s the top 8:
No one expects much from you yet. Making mistakes right away, as long as you first asked the right questions to the right people, is great! Your team should be up-front about when they expect you to be useful to them; it might be 6 months or more. Use that time well, explore all the internal resources you can, and make lots of meetings with different people to get exposed to new ideas, systems, and organizations.
A good place to start: a moonshot project that your team wants but doesn’t have the time to invest in. If you fail, you’ll learn a bunch on the way; if you succeed, you’ll solidify your reputation right off the bat. And, because it’s something the team wants, they’ll be happy to help give you advice all the time. You’ll need it!
Don’t even hope for documentation anymore. In the open-source world, if a product isn’t documented well, either someone comes along and fixes that, or it dies. In a company, top-down processes and an aversion to breaking things that already work means that rather than dying, the thing might get cemented as a core tool or product.
In one case, I pulled in a new dependency, a package distributed company-wide, that did have some documentation. It wasn’t working quite right for me, so I asked around my team about it. Turns out that the package’s original author was my teammate, sitting one desk away from mine. His advice? Oh, that’s deprecated. Been deprecated a long time. I should probably update that. Yeah, don’t use it.
This is not a thing that just the new guys do - even the veterans are constantly asking for input and advice. It’s just not as visible, because they know exactly whom to go to, and when it’s worth a question.
A big company is like formaldehyde: it preserves things that should have been dead and buried long ago. Like core web applications running in Perl. Or SVN. Or a bag of scripts that just gets deployed everywhere and no one’s sure what some of them do anymore.
In the real world, you have StackOverflow, tutorial blog posts, and forums to learn how to use just about any third-party package. People who write a package want people to use it, so they generally try to make it easy to use.
Inside a company, using an internal tool, the only way to know how to use a thing is to code search for other people using it. Copy … pasta.
This drove me crazy at first: every time I had a question about something internal, one colleague in particular would just send me batches of links to the internal Git repo. I don’t want to see other people do it, I want to know what it means… The answer? No one knows what that means, that’s just what you do with it.
This was a hard lesson for me to take to heart, but it’s already made me much better and faster, even in my personal work.
Accept that there’s so much you still don’t know: not just about coding, but about how this particular company works. It probably has all kinds of systems and internal tools and sites and maybe even DSL’s that you’re going to have to pick up, quickly, to be useful to your team.
Being valuable at a large, established company seems to require a large amount of knowledge about where to find that thing or that person or those credentials, that (a) you can’t possibly bring in and (b) will be of zero value elsewhere.
Let’s face it, no matter what your job it can become a grind sometimes. Having side projects, which are at least nominally useful to your team or leadership, but in a different domain (ie CLI vs web vs distributed systems vs documentation) or different language, can not only make things interesting but also make you valuable to your team down the road, when voilà you’re the only person that knows that new thing.
Stay ready for the next gig. These interviews are done, but who knows how quickly you might spot the next great opportunity (within the company or without, or maybe just a promotion). Keep a few things in mind:
Good luck, and enjoy the ride!
Next: How this went for me