Ricochet is the best place on the internet to discuss the issues of the day, either through commenting on posts or writing your own for our active and dynamic community in a fully moderated environment. In addition, the Ricochet Audio Network offers over 50 original podcasts with new episodes released every day.
I’m a technical writer by profession. It’s something I’ve been doing for more than a quarter of a century, and I’m good at it. Give me some complex technical information, and time to understand it, and I can explain it clearly. I’m lucky enough to have a good job, one that allows me to use the skills that I’m best at.
But just doing things you’re good at can get boring.
A couple of months ago, I was asked to help define the requirements for a new build-automation process for our API documentation. I knew the existing manual process well, so I was able to explain what the new automated process would need to do. During the course of the initial meeting, I mentioned some Python scripts I’d written to automate bits of the process for my own use. (Python is a currently popular programming language.) I’ve always enjoyed dabbling in programming, even though I’ve never done it for a living, and if I can find an excuse to write a Python script I will, even if it would have been less work to just do the task manually.
Before I knew it, I’d been recruited to actually help develop the new automation process, functioning as a programmer on a small team. This was an opportunity I’d never had before; while I’ve written a lot of quick-and-dirty scripts on my own, I’d never before had the chance to contribute code to a proper project, one organized and managed by someone who knows proper processes for code reviews, builds, tests, and so forth. It was my chance to learn how it’s really done.
And that wasn’t all I had to learn. I found myself taking on problems that needed to be solved, things that our code needed to be able to do, even though I had no idea how to do them. I was confident that they could be done, and confident that I could figure it out.
And so I dove in, experimenting with code snippets and frequently resorting to Google to find documentation and techniques I could borrow. I refused to go to the project leader to ask him how to do things; I insisted on figuring out as much as I could on my own. Every now and then I’d submit a new chunk of implemented code; and when the project leader, after reviewing my work, merged it in without comment, I always took that as validation.
The result was that I spent several weeks writing code that a competent programmer probably could have written in a day. You know what? I don’t care, because for me it wasn’t about being good at something. It was about getting better at something, adding to my skills, learning things I didn’t know before. I’m learning new skills that add to my consciousness; these are skills that will stay with me, tools that will stay in my toolbox until I need them again. More to the point, new experiences allow me to grow; in a very real sense, there is more to me now than there was a couple of months ago.
I am in my mid-fifties, closer to the end of my career than the beginning; this is a time when I might be expected to focus on doing what I’m good at while I’m at the top of my game. But instead, I find myself more and more gravitating toward taking on things I haven’t done before. I am fortunate that my employer places a lot of emphasis on professional development, which means that — as long as my work gets done — I can indulge this impulse and spend time on things that I’m not good at.