What I learned shadowing other developers for a week
Tags: learning, onboarding, culture
Published: 2019-01-13 17:01:45

---
title: What I learned shadowing other developers for a week
published: true
description: Thoughts on spending the first week of a new job shadowing different teams
tags: learning,onboarding,culture
---

It's a new year and I've just started a new job, in a different part of the civil service.

I joined on Monday, and after I met my new manager, he suggested that I spend the rest of the week shadowing different teams as a way to learn more about the department.

I've never formally shadowed someone before, so while I was figuring out how this place works, I was also figuring out how to get the most out of the shadowing. These are my takeaways a week later.

# Shadowing is hard work
Shadowing has lots of advantages. It's given me a bit of a support network which I wouldn't have had otherwise, and reduced the barriers to cross team collaboration. I got to see how multiple teams develop and operate the services they run, which gives me a common reference point for introducing new practices to my own team. I also got a good idea of what's different across the teams and what problems we have in common.

That said, this was a very intense week and I was exhausted by the end of it - as a natural introvert I found it very draining to meet so many new people in such a short period of time. If I was in this situation again, I'd rather spend some time with my assigned team first, so I can settle into my role and have more of an idea what is useful to know, rather than trying to soak up as much info as I can.

# Be prepared to ask questions
I asked a LOT of questions this week. A big culture shock for me was discovering the huge amount of acronyms people use on a daily basis here, which goes beyond the standard [civil service jargon](https://dev.to/matmooredev/can-you-host-a-read-only-api-on-github-pages-1jib) I'm used to. It was almost like learning a different language. Apparently I'm not the only one with this problem, as [somebody made an app for it](https://bigbookofacronyms.herokuapp.com/). It feels a bit awkward asking what stuff means multiple times but when you're new I think you have to get used to it.

In addition to the acronyms there is also a lot of domain knowledge that people take for granted, so I needed to ask a lot of seemingly stupid questions. I was introduced to lots of different systems with complicated interactions, and I found it hard to keep track of what was what. It was useful to see diagrams of how stuff fit together. For me it also helped to ask clarifying questions about the user and the task being done (the inputs and outputs), rather than how some data is processed in the middle.

# Different people can teach you different things
I didn't work with everyone the same way. Some people I spoke to were more talkative than others, and had their own ideas of things to show me. In other cases I paired with developers on the task they were working on (although I took on more of a navigator role rather than writing code). I think both approaches are fine - the value is in understanding what different teams do and why.

One thing that helped a lot was when the person I was shadowing asked me what I wanted to get out of the experience - this got us both on the same page and made it easier to bring up other topics I was interested in. You can also spin it around and ask "if you were me what would be useful to know/work on?" 

Lots of people I spoke to were able to show me diagrams of how systems fitted together, and I also saw a video of a call centre operator actually using one of the services, which was quite interesting. 

# Find things to do solo
I found it helpful to set myself a few low priority tasks to do during the week. This meant that if the person I was shadowing had meetings or other things they needed to do, they could still do that without feeling they had to look after me all day. On Friday the developers I was shadowing had 20% time for learning, so I spent some time learning about Spring, which is a framework we use here that I haven't worked with before.

I also tried to get as much admin stuff out of the way as possible, and compiled a list of new starter tasks to try and improve the process for the next person.

When I join my new team I'm going to be focusing on making the software easier to change and deploy, so another thing I did this week was get a spreadsheet of best practices and start to prioritise things to think about based on what I've learned from the other teams.