Yes, the title of this blog post is a little facetious, because the reality is that at many points in our careers – at many points in the average programmer’s week – we are coaching developers.
There’s a tale – possibly apocryphal – of a programmer who, when stuck on a problem, would explain it to a large inflatable parrot. The act of articulating the problem to someone else – even a parrot – often helps us to see a solution.
Yesterday, I paired with someone working on a library to compute visual flow. Machine vision is far from my area of expertise, so how could I possibly be of any help to someone – a PhD student in machine vision, no less – working on a problem I don’t understand?
The fact is, I coach developers working in problem domains I don’t understand all the time. I’m parachuted in – often at short notice – to pair with developers who are stuck on problems that I’m not familiar with. But if you think the role of a developer coach is to solve the coachee’s problem, then you’ve not understand my problem domain.
The trick to coaching developers is not to be a font of all knowledge. If a developer wants to know something specific, they can Google it. Rather, it is to help them articulate the problem. Yes, I am an inflatable parrot.
Don’t get me wrong: this is not an unskilled role. Coaches are perhaps more like counselors than inflatable parrots. But the essence of it is the same – to get them to articulate the problem they’re trying to solve, and to encourage them to envision a solution to try out.
This does require enough knowledge of programming, of practices, of processes, and of technology, to ask the right kind of questions. “And how does that make you feel?” won’t open the right doors in a programming context.
And, naturally, as a trainer in developer practices like TDD and refactoring, I also focus on keeping you safe while you go through the process of solving your problem.
I’ll notice if you’re not writing tests. I’ll notice if you’re making a lot changes before you run your tests again. I’ll notice if you haven’t checked your code in for an hour. I’ll notice when methods are getting too big, or when there’s a bit too much duplication, or when your method has Feature Envy for another class, and I will nudge you back to the safe path of frequent testing, frequent refactoring, and continuous integration.
None of these things will solve your problem, but they will protect you from car crashes while you solve it yourself. Yes. I’m not just an inflatable parrot – I’m an inflatable parrot who makes sure you’re wearing your seat belt.
Through Codemanship, my primary focus is on helping developers to build those good habits. You solve your problem. I help you develop the skills to do it safely and sustainably. My role as coach is not just to help you to solve your problem, but to help you emerge from that process a different programmer than when you went in.
I’m an inflatable parrot with an agenda.
Yesterday, I encouraged my pairing partner to write down in a single sentence what problem they wanted to solve. And then I asked them to write down the function or feature that would solve the problem – what would it do? That led us to tests that would fail because the code currently doesn’t do what he wants, and the act of writing those tests opened up a bunch of doors towards new ways of making it do it. We didn’t solve the problem in our session, but we constrained it with executable tests: the solution must fit in this box. And that’s progress.
Now think back to your working week: how many times did you play the inflatable parrot for a colleague? I’m guessing at least once. And that makes you a developer coach. Like I said, not an unskilled role, and it takes experience and quite a bit of confidence to get to a point where you can be parachuted into almost any problem or technology domain.
But – at a fundamental level – we’re all coaches.