Where Do I Start?

06 July 2013 / Career development

The first day at a new job is always a bit nerve-wracking. In a recent session at SPA 2013, we came up with some things a developer joining a new team can do to get up to speed quickly.

Whiteboard an architecture diagram

This is a brilliant way to get a quick overview of how the pieces of your new project fit together, and can be tailored to whatever level of understanding you (or the person you are talking to) has. It's a good way to meet people on other teams, when you're looking to get more detail on some of the parts of the diagram. And your fresh perspective can often be very useful to the person taking you through the architecture.

However, it can sometimes be hard to know who the right person is to ask, and it can also be hard to get the right level of detail.

Facilitate a retrospective

This is the fastest way to find out what's going on in a team, and beacuse you're new, you will essentially be an external facilitator which is really useful to the team. It's also a great way to find out what's going on in other teams once you've settled in.

However, it could be challenging if your new place of work is not used to agile working, and of course you do have to be the kind of person who has the confidence to faciliate a retrospective for a bunch of people you don't know yet.

Start putting a glossary together

...with the aim of putting it on the wiki.

This will give you a head start on understanding the concepts that the rest of team take for granted – and has the added advantage that you may hit on areas of vagueness or disagreement that can be straightened out.

It can however be hard to get started with this, and to work out what to focus on, and in some teams it might be a challenge to find anyone who understands them all.

In Summary: Do something, document something

People have different ways of learning and sometimes the explanations you get in your first week can lead to information overload and be hard to take in. So it can be useful to ask more directed questions, for example in pursuit of added detail for an architecture diagram, or to draw out actions for a retrospective.

We had some other ideas as well:

Pair program as much as you can, with different people

You could think about shadowing someone for a morning or a day

Talk to other teams - the teams that particularly can give you insight into what you need to know are the testing team, the support team and the ops team

Find out where people go for lunch and wangle yourself an invitation!

We also stole some ideas from other teams, like if the team's processes are not documented you could offer to do that as a way to gain understanding. For example, how well documented are the new joiner instructions? You are in a great place to improve those, and a big win would be automating some part of that. Also, meeting the users is a fantastic way to understand the business, so if that's not part of your induction you could arrange that.

Thanks to Andy Longshaw, Eoin Woods and Nick Rozanski for organising the session.