My name is Duncan Campbell and I work as a senior developer in a team of seven developers at the Rabobank. In the last year, there’s been a lot of change within the team. Two of our most senior members left to pursue other assignments at more or less the same time. This left a large void in terms of our capacity and technical knowledge. Luckily, where I work teams are entrusted with hiring new members. So we filled this void with three new developers of varying skills and experience levels. All of which are relatively new in the Netherlands.
To be an effective developer in our team requires a lot of knowledge. Just understanding the complex domain of the Dutch mortgage market and the details concerning mortgages themselves is a hefty undertaking. On top of that, you need to know about the developer process details inside our team. What is the lifecycle of our User Stories? What criteria are important when conducting code reviews? How do we field external questions and requests during the day? Outside our team, you need to know about how architectural decisions are governed, how to find documentation, how our infrastructure is set up and much more.
Our team works with three other teams on the same platform and are surrounded by a couple of hundred fellow Rabobank developers. We do not work alone. Therefore social knowledge is also required to act effectively. How you do you lobby for your new idea? If you have a technical problem in a certain field or with a certain system which developer around you knows the most about it? If it’s your turn to field production incidents during the weekend and you get a P1 at 2 AM on Sunday morning, that you have no idea how to fix, who can you call that will help you out?
An effective engineer needs to be a strong developer. You need to be fast. That muscle memory of shortcuts that lets you fly around your IDE, browser tabs and terminals needs to be strong and healthy. You need to realise when you have tried your best but it’s time to ask for help. You need to be strongly motivated to focus for hours on challenging work.
Through helping our new recruits (and the existing juniors on the team) with facing this challenge, our team has learned several lessons. Some of which I’d like to share in this blog post.
Environment
With such a challenging workload it’s of paramount importance that the environment that the team spends their time in is conducive to the outcomes we want. Developers often spend more time with their team members than their own families. If you hate where you work then work is something to get through. I’ve had this and it can be soul-crushing. Luckily, now I love going into work in the mornings because I know I’m going to get to hang out with my mates and be paid good money to code cool stuff. That’s what I wish for all our new recruits.
Safe
There is no such thing as a stupid question. Is there something you had explained yesterday and now have forgot? Ask again. Are you stuck and just can’t, no matter how hard you try, conquer a bug? Ask for help, you will get it without judgement. Have you just made a catastrophic error of judgment and production is exploding into giant flames only outmatched by the pissed-off look of the product owner? Stop panicking, sit down with a pro and we’ll debug the logs and code together to figure out how to put these fires out. Too often I’ve seen developers get angry at the more junior devs for failing at something, then “save the day” by fixing the error only to sulk back to their desks with no explanation of what they did. By blindness to these opportunities to teach someone something you just add work onto your own plate.
Challenging
Every day should be a stretch for a novice.
Ideally, a task will be:
- 60% stuff they know how to do without thinking
- 30% stuff they know how to do but is new
- 10% completely unknown.
By constantly doing things that you aren’t sure you know how to do and then, most of the time, being successful leads to confidence. I want to get our novices to the point where if some framework is throwing a cryptic error they won’t ask for help but will have the confidence to dive into the source code and work it out for themselves.
Accountable
It’s a pleasure to work in our team but that is a privilege and not a right. We all work hard and expect the same of each other. You can have total freedom in how time is spent but you also have to be able to stand up in front of the team and explain your decisions. We try to teach our novices to frequently reflect throughout the day on what they are doing and have done to teach them how best to manage their own time and learn from mistakes.
Fun
I wouldn’t be able to work as hard as I do if I didn’t have fun doing my job. We laugh in our team a lot. I don’t think we could put the pressure on our novices that we do without also blowing off steam with jokes, beers, sharing memes and interesting links. We also celebrate success and look out for juniors doing something they previously couldn’t. We compliment them on every mini achievement. So far I’ve yet to discover someone who doesn’t love being complimented on work they found hard to do but got done.
Different people have different values. In other teams, with more members who are also parents, flexibility in working hours and working remotely are valued more than spending fun time together after-hours. This is another reason why I value the ability to choose members for our team that not only have the right CV but also match us on a personal level.
Process
Next to the sort of environment in which novices work, the type of work can also help with growth.
Pair
Pairing is in my experience the best way to train up juniors. There is however a wrong way to do it. Often I see experienced developers code and juniors watch over their shoulder in awe whilst absorbing bits and pieces of knowledge through proximity. This delivers some value but, in the long term, is highly inefficient.
Instead, I find the following pattern works the best.
Choose a unit of work, not too hard and not too easy. Remember the 60/30/10 ratio from above. Pick a junior and both sit behind the same development station
As the senior, execute the work but every step of the way explain not just what you are doing but also why: explain the context. Instead of just saying you’re making a mock, check they know why we use mocks and how the mock works internally.
After the unit of work is completed have the junior sit behind the keyboard. Choose another comparable unit of work where the skills and concepts from the previous unit of work cover the development of the next one. Then walk the junior through solving the problem whilst explaining yourself. Normally this is where the penny begins to drop.
Another tip: forbid using the mouse. Additionally, if you see them do a piece of work that could have been done with a shortcut make them redo it. Every time. It’s painful for all involved but eventually, it speeds everything up.
Then finally do another comparable unit of work but let the junior do it themselves with no prompts. Let them ask questions and experiment with what they “think but aren’t sure” will work. Let them go down rabbit holes for a few minutes and make mistakes, then explain why the mistake is a mistake and gently lead them back to the path.
Eventually, you can let them do work independently with the safety net of someone nearby to ask the occasional question. Just like training-wheels on a bike. Each time they are successful we raise the training-wheels a little bit and give some more freedom. Eventually, we can remove the training-wheels altogether and then it’s “Look, mum! No hands!” in no time.
Foster independence and social ability
All this soft talk about safe spaces and “no such thing as failure, only feedback” could lead someone to think this approach is too soft and will only create lazy developers who will lean on others too quickly. And it can, which is why it’s also important to foster independence.
Sending junior developers on errands like “go ask Jan from the infra team to do XYZ for us”, “go to the architecture guild meeting and raise issue ABC with them, then report the outcome”, is a great way for them to build up a sense that they can work with the wider dev community and not just our team. Sometimes when I get asked a question I know the answer to I’ll send a junior to a different developer with the same knowledge just to help the junior build a network and social skills.
When you are asked for help, don’t just fix the problem but help the novice learn how to find the information needed to fix the problem. Look up documentation, StackOverflow answers and source code together. Like a good parent, ultimately the aim is to make yourself obsolete.