When I started my first role in software development, it didn't take me long to realise that you can do all the study in the world, but it will never prepare you for a professional codebase. This is especially true if you work at a big organisation with established or legacy code.

Sometimes the code will be lacking in comprehensive documentation. This can happen when teams have been there so long that their understanding of the code is just innate, and they haven't thought to put on a wiki page. Sometimes it just won't look like any other code you've encountered.

The unfamiliarity of a new project might make some people excited, but it can also cause anxiety. We're in an industry where bootcamps and influencers promise the world when it comes to learning. They often fail to take into account that a company's software can look very different to a todo list or blog built by a single person.

Getting to grips with a professional codebase can take weeks. Sometimes it can take months. However, there are some things you can do both before your first day on a dev team and in your first few weeks to speed up the process.

Take a look at some large open source projects.

Before I had my first day on the job, I wished that I'd seen a production codebase before. It wasn't until months after I started that I discovered the open source community.

Contributing to open source is a great way to get used to the kinds of tasks you'll be asked to do in a company's development team. You learn about working with other contributors, following design specifications, report bugs, prioritising tasks and fixing issues. You'll likely be working remotely as well, which is a fantastic experience to have.

Yet even if you don't feel like you can contribute, taking a look through some of Github's most popular open source projects will reveal some commonalities between them. You'll likely see the same test frameworks, task runners and frameworks being used across a number of projects. Being able to identify these on your first day at work will be incredibly helpful.

Find out all the tech that's being used and read the docs.

Make a list of anything in the code you haven't seen before and bookmark the documentation. This will take you a while, but it's a crucial part of working in a new codebase. It can be tempting to watch tutorials instead, but video courses will probably using the technology very differently. Get used to the documentation first and identify how the tech is being used in your codebase. If you're interested in learning more after that, watch some videos.

Start with tests.

After reading the documentation for whichever test framework your company's codebase uses, take a good look at the tests themselves. These will tell you what the most crucial functions are and what data formats you're working with.

Most importantly, tests should give you a high-level overview of how the code flows.

Make diagrams of everything. And then share them.

Speaking of the flow of code, it's a good idea to document any meaningful interactions you find between files and functions while you're looking at the test code. For instance, if you're working on an e-commerce website, diagram how the the user's order journey works in the code. If you're working on a straming service, visually document how the data gets displayed on each carousel in the app or browser.

Whether you're contributing to a legacy project or a brand new product, breaking down the codebase like this will help immensely when you're debugging or adding new features later on. Eventually, you'll end up with a decent skeleton of how the app or website works, and that's the first step to diving in and start making code changes.

There may be existing diagrams on your company's wiki pages, so make sure you take a look. If there isn't, share the ones you've made to make a future developer's life easier (and to make sure you don't lose your own notes!).

Use the knowledge of your fellow developers.

Software development is always a team effort. There's no one person who will know everything about the code (or there might be - but those folks are, in my experience, very rare!). Find out the experts are for each part of the development process and pick their brains.

You might get to the point where you feel like you're asking too many questions, but no-one will expect you to know everything the second you walk in the door. Make sure you tap into your teammates' knowledge by asking to pair program, getting them to explain the technical choices they've made, and to review your underderstanding often. Asking informed questions about the things you don't understand is the fastest way to progress in your role.

Just fix it!

Throwing yourself in the deep end can sometimes be terrible advice, but there's a grain of truth in it. Perhaps wading into the water is a better metaphor. You might be in your first job feeling overwhelmed by the code and unsure whether you belong in the team. The best way to overcome this is to give yourself a quick win.

Once you understand a bit about the technology being used and the flow of the code, look for a bug that you think you can fix. If you can't see an obvious one, talk to your team and ask if there's a manageable issue you can tackle. You don't have to understand everything, but the feeling of that first closed ticket might help with everything seeming so huge and indecipherable.

Have you got any advice for early-career developers transitioning from study to work? I'd love to hear some other suggestions!