An anniversary occurred last week that I don’t want to let pass by unremarked. On November 24th of last year, I made this note:
Welcoming @LotteJackson on her first day at @Clearleft.
Charlotte’s start at Clearleft didn’t just mark a new chapter for her—it also marked a big change for me. I’ve spent the last year being Charlotte’s mentor. I had no idea what I was doing.
Lyza wrote a post about mentorship a while back that really resonated with me:
I had no idea what I was doing. But I was going to do it anyway.
Hiring Charlotte coincided with me going through one of those periods when I ask myself, “Just what is it that I do anyway?” (actually, that’s pretty much a permanent state of being but sometimes it weighs heavier than others).
Let me back up a bit and explain how Charlotte ended up at Clearleft in the first place.
Clearleft has always been a small agency, deliberately so. Over the course of ten years, we might hire one, maybe two people a year. Because of that small size, anyone joining the company had to be able to hit the ground running. To put it into jobspeak, we could only hire “senior” level people—we just didn’t have the resources to devote to training up anyone less experienced.
That worked pretty well for a while but as the numbers at Clearleft began to creep into the upper teens, it became clear that it wasn’t a sustainable hiring policy—most of the “senior” people are already quite happily employed. So we began to consider the possibility of taking on somebody in a “junior” role. But we knew we could only do that if it were somebody else’s role to train them. Like I said, this was ‘round about the time I was questioning exactly what my role was anyway, so I felt ready to give it a shot.
Hiring Charlotte was an experiment for Clearleft—could we hire someone in a “junior” position, and then devote enough time and resources to bring them up to a “senior” level? (those quotes are air quotes—I find the practice of labelling people or positions “junior” or “senior” to be laughably reductionist; you might as well try to divide the entire web into “apps” and “sites”).
Well, it might only be one data point, but this experiment was a resounding success. Charlotte is a fantastic front-end developer.
Now I wish I could take credit for that, but I can’t. I’ve done my best to support, encourage, and teach Charlotte but none of that would matter if it weren’t for Charlotte’s spirit: she’s eager to learn, eager to improve, and crucially, eager to understand.
Christian wrote something a while back that stuck in my mind. He talked about the Full Stack Overflow Developer:
Full Stack Overflow developers work almost entirely by copying and pasting code from Stack Overflow instead of understanding what they are doing. Instead of researching a topic, they go there first to ask a question hoping people will just give them the result.
When we were hiring for the junior developer role that Charlotte ended up filling, I knew exactly what I didn’t want and Christian described it perfectly.
Conversely, I wasn’t looking for someone with plenty of knowledge—after all, knowledge was one of the things that I could perhaps pass on (stop sniggering). As Philip Walton puts it:
The longer I work on the web, the more I realize that what separates the good people from the really good people isn’t what they know; it’s how they think. Obviously knowledge is important—critical in some cases—but in a field that changes so quickly, how you go about acquiring that knowledge is always going to be more important (at least in the long term) than what you know at any given time. And perhaps most important of all: how you use that knowledge to solve everyday problems.
What I was looking for was a willingness—nay, an eagerness—to learn. That’s what I got with Charlotte. She isn’t content to copy and paste a solution; she wants to know why something works.
So a lot of my work for the past year has been providing a framework for Charlotte to learn within. It’s been less of me teaching her, and more of me pointing her in the right direction to teach herself.
There has been some traditional instruction along the way: code reviews, pair programming, and all of that stuff, but often the best way for Charlotte to learn is for me to get out of the way. Still, I’m always on hand to try to answer any questions or point her in the direction of a solution. I think sometimes Charlotte might regret asking me things, like a simple question about the box model.
I’ve really enjoyed those moments of teaching. I haven’t always been good at it. Sometimes, especially at the beginning, I’d lose patience. When that happened, I’d basically be an asshole. Then I’d realise I was being an asshole, apologise, and try not to do it again. Over time, I think I got better. I hope that those bursts of assholery are gone for good.
Now that Charlotte has graduated into a fully-fledged front-end developer, it’s time for me to ask myself once again, “Just what is it that I do anyway?”
But at least now I have some more understanding about what I like to do. I like to share. I like to teach.
I can very much relate to Chen Hui Jing’s feelings:
I suppose for some developers, the job is a just a means to earn a paycheck. But I truly hope that most of us are in it because this is what we love to do. And that we can raise awareness amongst developers who are earlier in their journey than ourselves on the importance of best practices. Together, we can all contribute to building a better web.
I’m writing this to mark a rewarding year of teaching and learning. Now I need to figure out how to take the best parts of that journey and apply it to the ongoing front-end development work at Clearleft with Mark, Graham, and now, Charlotte.
I have no idea what I’m doing. But I’m going to do it anyway.