Being a developer is brilliant – our goal is to deliver business value by building software applications. But we can also deliver business value in other ways too…
New starters are an investment by the company. When a new dev is hired they usually aren’t productive straight away. In fact, there is probably a lot of overhead – things they need to learn about the company – before they are productive. Until then they are probably cost-inefficient.
As a developer, then, we can deliver business value by helping new team members get up to speed faster. I’ll explain in just a moment how I approached this solution when a new starter joined our team at 7digital.
But first…It’s important to understand the context in which I am working. So let me give some details about the new starter. Let’s call him newbie.
Newbie is a senior developer, who is comfortable with the language and framework, and is used to a lot of good practices such as TDD, agile, and OO techniques.
With this in mind my goal was not to mentor newbie or preach about how to do things. Nor was I here to patronise him - I needed to show him about our culture, team and way of working so the company can get ROI quicker and we can have a happy team with more productive, motivated developers.
Pair programming, a bit of preparation and the big pictureAt 7digital we use a lot of pair-programming. When someone new joins a team, it works great for getting them up to speed. But it’s no silver bullet, and there is still a lot more to getting someone up to speed.
So in advance of newbie’s arrival I created some architectural diagrams. Having been to Simon Brown's architecture for devs workshop I was looking forward to using the effective sketching skills I learned there.
When I paired up with newbie the first thing I did was to use these diagrams to illustrate the big picture. A context diagram shows your systems (each system is a box) and the systems they interact with. Therefore, I was easily able to show newbie how our team fits in to the company – which other dev teams, DBAs, and types of customer our systems talk to.
Take him on the journeySimon Brown talks about motivation as being key to getting the best out of developers. It’s a common-sense statement we can all relate to. But how do you do it? Simon thinks you need to to feed developers the big picture, and make them feel excited about their part in the team's journey toward its goals.
So I gave it a shot. I explained to newbie all the goals our team was currently working towards – switching over to SOLR, improving indexing speeds, making our endpoints support JSON. I tried to explain how these features are a benefit to end-users and the business, too.
I hope at this stage newbie understood the purpose of the team and where it wanted to go. I should probably have tried to test him (without being patronising).
More diagramsWhen we got down to the feature we were assigned to work on, I was able to use another diagram - the containers diagram - to help me. I was able to use a containers diagram to show newbie how the different parts of the system (zoomed in from the context view) interact.
Doing this, I hope newbie was able to zoom in and out mentally – understand the system in general, and where the work we were about to do would be localised to, and how it would fit in overall.
Let him drive at his pace, and learn along the wayI don’t want to offend anyone, but I find it boring when I join a team and I have to sit there and watch. I also find it takes me a long time to learn.
One way I wanted to tackle this with newbie was to just guide him. I laid down the problem and only intervened when he was going way off track.
I never told newbie how he should do something, in fact I told him to do it however he wanted. However, I would challenge his ideas and suggest problems with that approach but leave the decisions up to him.
By taking this approach, newbie was generating his own thoughts. If you’ve seen my little project you’ll know I’ve studied a bit of psychology. Therefore, based on psychological theories I was confident he would create stronger memories and learn quicker by being allowed to generate his own thoughts.
By giving newbie freedom, I was also able to learn from him. I watched how he solved some problems differently to how I would. I picked up some cool power-user tips and keyboard shortcuts too which is always a bonus.
Did it all himselfWe haven’t quite finished the piece of work (the building we work in was evacuated due to being on fire) but newbie wrote all the tests, did all the coding and was jumping around two of our projects pretty rapidly after just a few days.
When I think back to my introduction to a few development teams, it has taken me a lot longer to piece together the high-level information and become comfortable with project structures.
My opinion is that the wax-on, wax-off – aka sit and watch me – is not a very good strategy for integrating new team members. I don’t think it provides a good level of business value either (this isn’t a criticism of anybody and is purely my opinion).
It's also worth pointing out that newbie is a pretty solid dev, so much of the credit for him getting up to speed is down to his ability. Hopefully I was some help in allowing him to use his ability, though.