I work as a web editor in local government. Because I work in local government, I am also a content strategist, photographer, writer, designer, and – from time to time – event planner and dishwasher. It’s the public sector, and it’s simultaneously infuriating and extremely rewarding.

A bit of background

I used to design websites, back in the table layout days. That was before CSS and prior to the acceptance and proliferation of web standards. I built websites for a publishing company, a bakery, a café.

And then I did other things. I was an AmeriCorps volunteer. I worked on a farm, with an environmental nonprofit, and for a university. I worked in GIS (Geographic Information Systems) for a while and wrote some Python here and there to automate geoprocessing tasks.

I was working with the web to some extent the entire time, but I was disconnected from the prodigious pace of innovation that occurred in web tools, frameworks, workflows, etc. At some point, I realized I needed to play some catch-up, so I began to dive headfirst into learning new tools. Given I work with content on a site that is, at the moment, completely static and hand-coded by our tech team, I don’t have the opportunity to learn on the job. So I began to explore learning resources.

Trying to learn it all

Catching up has been overwhelming. It started that way, at least. I began with Codecademy, but I didn’t come back consistently. Consequently, I lacked momentum in my learning, and I would have to review the previous section every time I started a new one. It didn’t work out.

Then I signed up for Treehouse. I figured if I was paying for the service, it would keep me motivated to use the service consistently. Plus, Treehouse is based in Portland, Oregon, so we’re neighbors.

Treehouse was pretty great, actually. I enjoyed the pace and structure of the video lessons, and I quickly racked up around 6,000 points (points and achievement badges being simple but surprisingly motivating methods for tracking personal progress).

The problem with learning via Treehouse, as with the web itself, is the breadth. The tools you’re learning about are so complex and diverse that it’s difficult to know where to start and how to proceed.

To reiterate, I’m a content editor. I work with web content, in part, because I can’t decide on a speciality. I want to do it all, and working with content offers a lot of flexibility. It allows me to delve into multiple interests and discover new interests I didn’t even know I had.

My biggest challenge as a Treehouse subscriber was prioritizing what to learn and when. I took courses on everything from REST to React, but since I rarely (or never) used the tools I was learning, I would forget most of what I’d learned shortly after completing the lessons. Moreover, since I didn’t need to learn anything in particular from Treehouse to do my job, I couldn’t decide what to learn next. Given I was paying for the service, I still felt compelled to jump down a new rabbit hole regularly. That’s how I ended up learning about “Why Version Control Matters.” I’m not a developer by trade, but I still had a pretty good idea about why version control matters before this course. I took the course as a prerequisite for learning everything I would never need to know about Git.

But as it turns out, Git (or in this case GitHub) isn’t just for coders. And that’s the problem (and the opportunity). Effective technologies find their way beyond their initial use case into other disciplines, as they should. So how do you know which ones to invest your time in to learning?

Learning what to learn

I’ve finally learned what to learn (sort of). By necessity, I’ve abandoned trying to learn every framework, preprocessor, task runner, and language. I’ve started to refocus on fundamentals and what directly impacts my publishing workflow.

HTML and CSS (of course!)

As a web editor, I certainly try to keep my skills sharp in HTML and CSS. That’s kind of a no-brainer now, and I suspect HTML and CSS will continue to be foundational knowledge for those of us working in a variety of communications disciplines. As Mandy Brown pointed out in a 2013 talk, HTML and CSS aren’t “code”. They’re markup languages, and markup is the traditional output of an editor.

Figuring out how much HTML and CSS to learn is another story, especially with the latter. Sass, Less, CSS Flexbox and CSS Grid are some of the exciting developments in CSS, but they present new challenges to keep up with, particularly when you don’t write CSS every day for a living.

I keep up with as many “major” CSS developments as I can, determining what constitutes a “major” development by tracking the experts at A List Apart and CSS Tricks, among a few others. I’m currently reading Get Ready for CSS Grid Layout from A Book Apart.

Pattern libraries

I am crazy about pattern libraries (or front-end style guides). I stalk styleguides.io. I’ve read Atomic Design and Front-end Style Guides. I’ve composed writing style guides and worked on brand guidelines, so I suppose it’s understandable that I have such an affinity for pattern libraries.

JavaScript

JavaScript is definitely the front-end language I work with the least. I’ve written presentational JavaScript and jQuery here and there, and I’ve written some Leaflet maps, but I just don’t work with JavaScript that often.

But JavaScript is now ubiquitous on the web and beyond and is becoming increasingly important for non-developers to be literate in.

I recently read Mat Marquis’s JavaScript for Web Designers. It’s the most approachable book on JavaScript I’ve read, and it provides a good balance of background, fundamentals, and practical applicability.

To be continued

As an editor and content strategist, it’s difficult to know how to invest your time and energy. I’ll write more about which tools I’m investing my time in and let you know which writing apps I use in my workflow.