Last month, I had a guest post published on CSS-Tricks, “Building a Conference Schedule with CSS Grid.”

This was really personally exciting for a few reasons:

1. CSS Tricks is probably the web design blog I have read the longest and learned the most from. It featured prominently in my recent reading list.
2. They get a lot of readers! Based on their 2018 stats, the number of users my site gets in a year (40.5K), they get in 15.5 hours.
3. My post was the culmination of a lot of other work I had done.
4. I got paid to write it! Not a ton, but it was the first time I earned a paycheck simply for writing something. That was as emotionally rewarding as it was financially.

The Post

The subject of the post was fairly technical, so be forewarned. The gist is that I used a fairly new type of CSS code in a somewhat novel way to output a really nice conference schedule. Along the way, I considered accessibility and supporting older browser and came out with really nice solutions for just about anyone who might use it.

Here’s the actual schedule looks like:

Background

Like I said, this post was the result of a lot of other work.

• The demo was first built in an attempt to improve the WordCamp.org schedule tool which powers hundreds of conference websites per year. I built it both out of frustration with the old tool and as a way to learn about “CSS Grid”, the new-ish technique it uses.
• I presented about the technique last year at a WordPress developers meetup in Seattle. The presentation was well received, and that gave me confidence that an even broader audience would be interested.
• I was lucky enough to know one of the people who can actually make changes to the WordCamp.org tools, and he’s been working on taking this code and making it work for all future WordCamp sites. I’m hopeful that will come out later this year!

The Benefits of Blogging

It’s always worth mentioning that writing down your ideas is an amazing way of clarifying them and learning more. That was especially true of this post. It’s a unique challenge to write a technical tutorial-style blog post without it becoming an impenetrable wall of code. I realized in writing it that the included code demos needed to be treated like paragraphs of text themselves that had introductions, conclusions, and elaborations.

I seriously edited this post for structure, ease of reading, and general flow, probably more than almost any blog post I’ve ever written. I used Hemingway as a rough guide for reading level and sentence complexity. While I’m often skeptical of such measures in the absolute, this particular post was greatly improved by shortening sentences and simplifying language.

To make the post even more understandable, I illustrated the article with visual demos of code concepts. I think that greatly improved the article’s explanatory power and visual flow.

Finally, the post didn’t just clarify my thinking, it highlighted parts of the code that I didn’t understand! One rabbit hole I went down turned into an entire section of the post I hadn’t planned to write. A comment on the post after it was published made me realize that I didn’t even fully understand why my own code worked! In seeking to respond to that comment and others, I further refined my understanding of the concepts and my way of explaining them.

Among those comments, I inspired at least one person to write their own demo code and connected with two other people who used very similar techniques but weren’t sure if they too were alone in doing what they did.

In the end, writing this post achieved a professional life goal I didn’t quite realize I had before I did it. It confirmed to me that I know what I’m talking about and can explain it to others in a way people want to engage with.

Now, I’m already outlining my next proposed guest post. 😃