Let’s just not talk about 2021 and look forward instead

I can’t be the only one who is just bone-tired after the past two years. I can’t blame it just on That Disease or OMG Politics. The problem is that everything else keeps going. Every year, there is some balance between the good and bad. But pandemic times add two colossal rocks to the ‘bad’ side of the scale. Then the regular bad stuff continues to pile on.

I know this. So why do I feel guilty about productivity (or lack thereof) over the past two weeks?

I’m guessing I’m not alone.

Looking back at the past year to take stock makes me even more depressed.

In an attempt to counter this perspective-induced ennui, I’d like to take stock of the future instead. Instead of looking over the things that either almost happened last year (but never quite did) or happened (but not as successfully as I hoped), I’d like to look at some of the things that could be interesting in 2022.

Work and ideas for work

I’m still working on how to position myself—how my skill set could best benefit people. I’m kicking around a few ideas on how I could do that, but in the meantime, I still have time for new projects and jobs, so get in touch if you think I might help you.

I’ve realised that I have a lot of knowledge and have done a lot of reading on research and decision-making processes. Some of this was a part of my last job’s focus on helping academic researchers. Some of it is how I’ve applied methods and tactics from my arts and humanities background to coding. I’ve noticed that many developers feel underwater, find it hard to keep up, feel lost when they need to begin new projects or tasks and don’t realise that there is help out there. People say that web development is unique in the fast pace and volume of changes in the field.

That, strictly speaking, isn’t true. That there is a fast pace is true. And the volume of changes feels all-encompassing. What it isn’t is unique. Social sciences, health research, economics and investment, many fields of science, all face similar problems with managing your research and news.

What is useful is that many of them have been dealing with this pace for a little bit longer than web dev and have come up with a few helpful approaches.

There are three prongs to the approach I’d like to take to this (subject to change, as always):

1. On frameworks and stacks. For the past six months, I’ve been trying to formalise my approach to navigating the various tech stack and framework choices I deal with in web development. It’s based on the processes taught at art school, which doesn’t just teach you how to practice but what to practice, whose practice you study, why they did what they did, all to help you figure out what to do with your work. With a bit of Thomas S. Kuhn mixed in. This one could take a while.
2. When to read, when to bookmark, and when to Google. How to do the practice-led research that we should all be doing as web developers. The web development training programs that I’m aware of don’t teach this. But they should.
3. Practice-led note-taking. Zettelkasten is a note-taking strategy out of social sciences that’s popular in certain online circles today. It works well when you’re working on novel ideas and new theories in your field. It doesn’t work well for practice-led research which is what most developers do. Umberto Eco’s approach, from his How to Write a Thesis, is, in my view, a better tactic when the research has to have a specific outcome (thesis, program, website, etc.). I’d like to figure out specific ways to adapt this idea to web dev research. But in the meantime, you can read and enjoy Eco’s original book. I highly recommend it.

Web devving it

I love web development and it’s still going to be a big part of what I do, esp. since I’m still working on my own website and web apps (see Colophon Cards below).

But I keep changing my mind as to whether I should focus my time on coding-oriented web dev topics or not. I have a strong preference for ‘vanilla’ JS approaches (that is, using browser-provided APIs directly) and I tried my hand at writing about those topics. I’m just not convinced that trying to teach others how to effectively use browser-provided APIs for web dev is a productive use of my time. But maybe I’m just getting jaded after years of constantly seeing people apply the React hammer to every web dev nail, screw, bolt, or fastener in sight.

I’ll write posts on the approaches and methods I’ll be using in my web dev practice (like Colophon Cards) but I’m still on the fence as to whether I should push beyond that.

I have a suspicion that I might have a greater impact—be more helpful to people—by writing about research and process for web dev. But I’ll only find out by testing it.

Writing

I wrote a few mega-posts last year that might even qualify as short books:

• Software Crisis 2.0, on how software goes bad.
• 136 facts every web dev should know before they burn out and turn to landscape painting or nude modelling, full of bite-sized advice and opinions.
• Lessons in Interactivity, 2021 redux, an overview over the past decade.

I’d like to take these long essays and extract as many focused ‘one problem, one solution’ blog posts out of them. Take each concept and frame it with the problem it solves.

I’d also like to put together a proper book-type thing or two this year. Could be fun.

Colophon Cards

From the site:

My goal with Colophon Cards is to create a web-based note-taking app for bookmarking and reading websites, ebooks, and documents.

I got a grant to prototype a web app that marries ideas from both traditional card-based note-taking approaches with hypertextual digital note-taking apps.

Making is a lot of fun and I’m looking forward to putting the prototype together.

Other Stuff

I’d like to get back into regular practice with my photography. The past four years have, honestly, been a bit frantic and I haven’t taken the time that I should have to go out and take pictures.

I did manage to do a bit of it over the past year. Let’s hope 2022 will see even more.