First day as a Junior Developer
What can be a more interesting way to express common yet frequently overlooked challenges of pair-programming across expertise, than a blog post? Perhaps, a slightly frightening tale..Get (not too) comfortable and read on.
Jo has joined the company as a graduate developer, where Sam works in the role of a senior consultant. Fresh from university, Jo is inexperienced and enthusiastic, her excitement to learn mixed with natural self-consciousness.
Jo is lucky in the sense that the team all practice pair-programming. On her first day, Jo sits with Sam, to pair on an important programming task…
Sam (not bothering with common pleasantries): Hey. So I picked up this story yesterday. Basically, we need to implement another shipping option….First, we need to extend the ShippingOptionsController in the webapp, we will need to create the option in the database and when that is done, we will implement a change in “an poorly built internal system” and speak to “the team that built it” to code review it. We also have a number of unknowns with regards to the the UX and some other business rules. After that…
Jo (eyes growing big): Could you please give me an overview of how all these systems are related to one another?
Sam: Sure, no problem… Argh, I have a meeting with ‘x team’ now. Have a look at the code base, see if you can make a start, I will explain when I am back.
Jo looks around code base and sees a mess of legacy code and hundreds of files.
40 minutes pass, Sam comes back
Sam: Hey, how did you get on?
Jo: A little lost, to be frank.
Sam: No worries, let’s start working on it, and I will explain as we go along.
With that, he takes the keyboard, starts to work. Some time later, a project manager stops by their desks, spends 5 minutes exchanging ‘in’ jokes with Sam, then casually checks that the new shipping option feature is going to be released on time, and leaves. Regaining concentration takes a while. Jo’s morning enthusiasm is painfully varnishing, taking along her self-esteem..
Sam: Another day of meetings and disruptions, we better start before it’s time to go home!
He gets comfortable by his desk, at which point Jo has to lean over in order to see anything on the screen.
Sam starts explaining the code they write as they go along. Jo tries to follow. As the time passes, Sam understandably gets tired from talking at Jo, and speaks less and less.
Jo, having no physical interaction with the keyboard and the problem at hand, finds it increasingly difficult to concentrate and engage. When their senior partner speaks less, they feel completely lost. Her shoulders begin to ache and her eyes are red from squinting at Sam’s screen.
Throughout the time, other teammates take turns inviting Sam for coffee breaks (and failing to see Jo, who is sitting right next to him), while Jo frantically tries to catch up on what had been said.
Finally, it’s 6pm!
At the end of the day these are the thoughts that ran through Jo’s head…
- Everyone on the team knows so much, I will never catch up
- I don’t know any of the teams involved in the process
- I wasn’t invited to any of the coffee breaks or meetings — they probably think I bring no skills of value
- I haven’t written a single line of code today
- My back is aching from constantly leaning over to see the screen
Clearly, this wasn’t an incredibly productive day for Jo’s learning. She has gained a headache, doubts in her technical abilities and a sense of exclusion from the team, all in one day.
None of the team, and particularly Sam, intended to be mean or exclusive on purpose. So what went wrong?
Quite a few things, on different levels, aren’t right when pairing goes that badly.
Fundamentally, both Sam and Jo had certain needs and expectations from the pairing experience at the start of their day but neither of their needs’ were met by their pairing session. In a later article we will describe how the needs and expectations of junior and senior developers are surprisingly similar.
The End.
