Markdown, GitHub, Atom, Jekyll, rubber duck, refactoring… Those are just a few of the terms I had never heard before starting here at Corgibytes. Yes, I had heard of a rubber duck, but not being a rubber duck.
In case anyone’s thinking “Oh, she’s one of those drips,” let me stop you right there. I’m a knowledge-thirsty geek. In high-school, I was in the gifted stream (a separate stream reserved for high-performing students). I wasn’t at the top of the nerd class, but close. In University, even though I studied translation, I taught myself basic HTML and web design because the office where I interned needed a website. The staff was made up of translators and one admin person. They could tell you all about French typographical rules in English documents, but couldn’t tell an opening HTML tag from a closing one. More recently, since I enjoy writing thrillers, I took forensic anthropology and forensic psychology classes so that I could infuse more realism into my fictional stories.
Still, none of it helped me understand command lines and branches or that Rails had nothing to do with freight trains.
Being a less-technical person on a highly-technical team can sometimes be daunting. Even almost tear-inducing. But if you’re willing to put in a little – okay a lot – of effort, you can develop a killer set of skills that will separate you from all the other writing-communications-marketing hyphenates out there.
What Does It Mean to Be Technical?
As Andrea, our CEO, has often pointed out, being technical is relative. Compared to my writer friends, most of whom pretty much only know how to use a word processor and upload their work to Dropbox – which they begrudgingly learned to do after losing one too many drafts –, I’m a techno-goddess. At the other end of the spectrum, me being part of the Corgibytes team is kind of like a toddler just learning the alphabet speaking with scholars about the literary merits of War and Peace.
Give Yourself a Break
Since your place on the sliding technical scale will vary depending on the context, don’t spend too much time worrying about where you are exactly. I’ve adopted Andrea’s terminology. I no longer refer to myself as “non-technical.” Instead, I say I’m less technical. It feels more accurate. I’m not really non-technical, but I’d be uncomfortable calling myself technical – especially working on this team. If I’m talking about my skills not in reference to the team, then I might use something like I’m technically-inclined.
Ask a Lot of Questions
Don’t be that person who pretends to know more than they do. You’re fooling no one. And it just makes the experts grit their teeth and roll their eyes.
Reality is, if you’re performing marketing, content or even administrative tasks, it’s because you were hired to do that. No one hired you to be a developer, no need to act as though you understand everything they say.
So, ask questions.
Since I’ve been at Corgibytes, I’ve asked a ton of questions. At times, I’m sure my question made the developer’s head explode. But you know what? No one, not even once, has ever made me regret asking my question. Everyone has always been gracious and patient and oh-so-generous with their explanations. And if I didn’t get it, they’d try again.
But Don’t Ask All of Your Questions
There is a fine line between gaining enough knowledge to be able to follow along, and blocking the conversation because you’re constantly interrupting the speaker asking to explain every word and concept. This isn’t a university course. It’s a work environment.
To help me walk that fine line, I ask myself these two questions:
- Has this come up several times?
- Does it affect my job?
Has this come up several times?
A good example of this is the rubber duck thing. The team had talked about being each other’s rubber ducks and thanked one another for it. Then, someone either found or created a rubber duck emoticon. They all thought it was awesome. I was clueless. “What’s with the tub toy?” Googling rubber duck didn’t help either. So, after failing to come up with an answer on my own, I asked them what it was all about. They were all too happy to share with me the concept of rubber ducking. Now, not only do I know what it means, I even get to be the rubber duck sometimes.
Does it affect my job?
Earlier this month, the developers were chatting on Slack about changes they were making. I didn’t really follow what they were discussing, but it didn’t seem to affect me. Until I saw what I understood as: “Made changes to bla bla bla bla, GitHub bla bla bla bla, blog post bla bla bla bla, immediately.”
Although I didn’t know what those changes entailed, I did know it somehow affected blog posts. And that’s my responsibility! So I approached the developer and asked about it. In the end, the changes weren’t impacting on my workflow. But better safe than sorry.
The best way to better understand the team and their needs is to better understand what they do. And being an active listener during team meetings is a good start. But it’s only a start. It’s also worthwhile to read up on the various topics, take introductory classes and listen to podcasts.
Part of my job is to proofread the blog posts. I don’t always understand the concepts explained, but I can generally get a sense of what is being said. Which adds to my knowledge base.
Through my local library, I have access to Lynda.com classes for free. I take advantage of this to learn more about things like how GitHub works.
Another aspect of my job is to edit the Legacy Code Rocks podcasts. Again, I don’t always follow, but some terms come up frequently. And I start to learn them as I work, kind of by osmosis.
Ultimately, it can be a rewarding and stimulating experience to work on a team of experts in another field. The trick is to resist the urge to quit every time you have to – yet again – learn some new software the team has just adopted, after having finally mastered the previous one, and a big, dreadful error message stops you in your tracks, and you can’t figure out how to make it go away. Instead, you take a deep breath, and ask if anyone’s available to be your rubber duck.