Learning is Productive
When I started my first enterprise coding job I was obsessed with my productivity — specifically, productivity as measured by tasks completed.
I was hyper-aware of being the most junior member of the team and the only female developer. I knew I would struggle for ages over a task someone else could complete in five minutes but I was determined to out-work this deficiency. I exhausted myself reading articles and doing tutorials outside of office hours. When I was actually on the clock (but delirious after my extra-curricular study and lost sleep), I would frantically copy/paste code, hacking away until I got something fit for review. I did this for months.
Eventually, I had a task that involved working directly with a colleague. I was terrified, imagining my ignorance would be on full display and I’d be fired and they’d think twice before hiring another female developer. Fears that look ridiculous written down but were all too real in my head at the time.
Almost immediately, we hit a bug and I didn’t have a clue what was going on. But funnily enough, my colleague didn’t either. He started talking about what he expected to happen and why he expected it to happen and I realized I could follow his logic. I could read it myself, in the code. We traced the bug back to a pre-existing issue, did a bit of research to understand the roots of the problem, filed a fix and went on with our main task.
Redefining productivity
It was a small detour but it made a massive difference for me. I stopped asking myself, “Why can’t I get this to work?” and started asking, “Why isn’t this working the way I expect?” Answering the first question was anxiety-inducing and gave me no sense of accomplishment when I stumbled upon the solution. Answering the second question could lead me down unexpected paths and often took longer but was more satisfying. I inevitably learned something that helped me multiple times in the future.
My productivity was still important to me, but no longer easily quantified. Having a productive day meant feeling good about the work I did that day. Instead of churning through a bunch of low-priority, low-impact tasks, I wrote higher quality code with a greater sense of purpose.
Documenting how we learn
When I joined silverorange, it was clear this view of productivity was generally understood. It’s a natural extension of our Be Kind philosophy. But the learning part wasn’t formally written down.
This was a topic of discussion at our last retreat and turned into an internal document with the following three distinctions:
- Everyday Learning occurs daily in the course of completing a task. Individuals should be comfortable self-directing this type of learning.
- Dedicated Learning is subject-specific, requiring more time than can be reasonably applied during a regular work day. This type of learning needs to be planned in advance with Project Managers.
- Shared Learning is an opportunity to disseminate knowledge gained from recent work or dedicated learning through bi-weekly design and developer meetings and weekly Show and Tell meetings. This could also be extended to cover conferences or group courses.
Vague and aspirational as it was, this document became the basis of a hiring exercise for our new Director of People (shout-out to the new slice, Nikki Mifflen-Mitchell!). In the process of introducing herself to everyone on the team, Nikki has been asking some great questions to inform the creation of an effective and inclusive personal development policy. It’s exciting to see the steady evolution of this work and I’m proud to be part of a company that puts action behind words.
Learning is part of the job
If there’s one thing I wish I had known from the start of my career, it’s this: learning is part of the job; it should be done during work hours. If your company already has a policy in place, use it! If they don’t have a policy, start the discussion. It may lead to results sooner than you think.