Recently, I’ve been thinking about the importance of working with context. What does this mean exactly? Context can mean a lot of different things to different people, so I’ll try to elaborate on what I exactly mean by this and how exactly it can help you.

In software development, we are constantly surrounded by many context-heavy tasks and bits of information that we need to process and keep in mind, and, honestly, there can be cases when this feels overwhelming, especially when you start in a new team where there are chances of the tech stack being new, the team being completely new and the business domain being new.

When all of these things are new “at once”, it’s easy to be overwhelmed and feeling lost in the midst of it, because there are so many new things to load into the brain that it’s just not possible to take it all in one fell swoop. But, if that’s the case, then how do you adapt (and eventually thrive) in a new work environment? If you spend time simply feeling overwhelmed, then it looks like there’s no time to become productive, right? That’s absolutely right!! The first step towards unblocking yourself is to realize that you aren’t going to be able to learn everything in one go.

In fact, it’s normal that you’re never going to be able to learn everything about the business, the codebase and know everyone by their names. The first thing that you should come to terms with, is that you’ll never know everything and that’s fine!

The second thing you need to know is that taking baby steps is always going to win in efficiency in the long run, compared to trying to do everything at once. This is something that you might feel that you would be able to do and handle on your own. I mean, you look back and remember how effective you were at your last job and now you can’t even build your code locally? What kind of amateur hour is this? This is a hard position to be in for almost any engineer who is starting a new gig. We like a challenge, we thrive in complex environments and we provide the best value for our business when we feel productive and lack of context can be a real burden.

This is why I believe that working with context is critical to overcome the feelings of inadequacy that come with a new job or a new task in a job you’ve doing for years but, where context is lacking.

So, how do you build context, then? What do you do first when you want to be as effective a team member as you can be?

Let’s recall the mental states that we’ve discussed earlier that can help us with this:

1. You will never know everything. You’ll need many interactions with many people in and out of your direct team to be able to grow your mental model of the business and the company.

2. Going with an explorative mentality by taking small steps will be the fastest way to build context.

Let’s see what we can get out of these ideas.

1. You will never know everything.

This is great! Great and reassuring, because you can be certain that people around will be just as clueless as you are and will be.

Context is just gained and built up over time but it starts expanding from a specific starting point. That point is usually defined by a combination of your role, the priorities of the business from the moment you join, your own interests and the first few tasks directly assigned to you. Once you are involved with the task, the best way to get it over the finish line is to try and grok the existing patterns in the codebase and then try to map them to your ticket and by doing so, you get a little bit of extra context and you ensure as little friction as possible in your work compared to the existing one.

There might be some specifics of the domain or a home made solution to a specific technical problem that may feel elusive to you, but, with some team support in moments like code review or testing, you can still get things done based almost exclusively on pattern matching and writing the best code and tests you can. This is a good way to start moving forward and getting the lay of the land little by little. A bit like an explorer going through uncharted territory and gaining more insight as it keeps going forward.

1. Have an explorer’s mentality and take small steps

Once you have a few simple tasks under your belt, your confidence in the development process will increase, you’ll know how the code is built and deployed, the kind of stance the team has on tests and CI/CD, and so you’ll be free to keep these things in the background and you can focus on understanding in detail the small things that were elusive to you before. Doing this is a very personal endeavor and it can require deep knowledge of the framework you are using (Spring, for example) to understand some specific things you see happening, like security filters or certain DB operations being denied, etc.

This is the level of deep diving in the tech stack to gain a deeper knowledge. There’s then the level of gaining additional context of the abstractions in your codebase that are in place to support the underlying business you are writing code for. Usually, a good place to start is by reading any documentation if there is any. Documentation is great to understand the ideas behind certain decisions and how they affect the way features are built and code is maintained. Then, a next step is to read tests and try to run them. They are great because they usually showcase specific mechanics of the “company tech stack” in isolation which is great to build understanding of specific details.

Once you combine both approaches outlined above, you will find it easier and easier to start building context and increasing your understanding. You can use this approach to improve existing documentation, add new tests, explore certain assumptions and improve how people after you will be able to build their own context!