Skip to content

Don’t just build a backlog, share it too

I have started sharing more blog posts and podcast episodes on Twitter, LinkedIn, email lists, slack channels, and other places. It’s kinda fun to look back over past work and find something that resonates. I’ll often discover this when I’m engaging in a discussion or see a post on a related topic.

This is one of the benefits of blogging. You can lay out your thoughts on a complex subject in detail, considering various points of view before coming to a conclusion. When someone brings up the same subject, you can share your thoughts with a single link copy and paste, rather than retyping all your thoughts.

There’s also value a backlog of stream or podcast guest appearances. Don’t just share the podcast when it first comes out (though you should do so). Share it repeatedly! You and the host had a good conversation, right? Most conversations are just as valuable a year later as it was a day later. Even if you are talking about the news of the day, your analysis should have long term value. And podcast hosts love to see someone share an old episode; it helps raise the profile of their efforts.

I like to use scheduling for some of this backlog highlighting, as that lets me batch i tup.I have successfully scheduled out posts using native tools. Both Twitter and LinkedIn let you schedule posts. Twitter lets you schedule out posts up to 18 months out. LinkedIn is more limited and only lets you schedule out three months. But if you are posting two times a month, that’s still six posts/pieces of content you can share.

Don’t rely entirely on scheduled posts. Engage spontaneously. However, having these posts scheduled means you are still sharing your past work even if you have a busy week or a vacation.

You can highlight a backlog of short form content too. With Twitter, I also do “still true” posts where I retweet one of my posts that I feel is timeless. Here are some examples.

Finally, a public backlog of your thoughts is a great way to show your expertise and growth over the years.

You know who likes to see that?

Employers.

20 years

Wow, it’s been 20 years since I started this blog. The world and my life have changed quite a bit, but I still like to muse on technology, business and more.

Thanks for reading! I appreciate everyone who takes the time to listen to me, whether you scan it, share it, or reach out to me to let me know.

Still think blogging is one of the best things you can do if you want to:

  • engage with people
  • understand a subject
  • build a business
  • create a name for yourself
  • think deeply about a topic
  • find a job (but not quickly!)

Thanks again for 20 great years!

How to have great guest posts on a blog

I have another blog that I’ve been running for a few years, called Letters to a New Developer.

It is full of advice I wish I had had at the beginning of my software development career. I even turned it into a book.

One thing I’ve done the entire time I’ve been writing this is to ask for guest posts. No advice is generic; it’s all based on where and who you are. By asking for guests to share their experiences, I expose my readers to a wider variety of viewpoints. This leads to better understanding of the wide world of software.

After all, if you want to work for a FAANG, it’s better if you hear from someone who prepped, interviewed and was hired for such a company, rather than me, who will never work for such a company. Or if you are looking to understand what it’s like to work in open source, hearing from someone who has made it their career. Have imposter syndrome? Others have struggled with it too. Also works for techniques; it’s great to hear from someone who is a methodical journaler, for example.

I bet you get the point. There’s no way I could have written any of those articles.

Guest posting also helps spread the word about my blog, since a guest poster usually shares their writing with their friends and network.

For the right kind of blog, guest posts can be great. Here’s my criteria:

  • Does the blog have decent traffic? If not, folks probably won’t want to guest post. I’d say at least 25 visits a day.
  • Have you done this for a while? A years worth of regular posting shows you’re serious.
  • Does the blog present a variety of viewpoints? I wouldn’t want a guest post for this blog, because it’s all me, all the time.
  • Is the blog non-corporate? If it is a company blog, guest posts should be paid for with money, or be part of a co-marketing project.

If you want to have great guest posters, here’s my recipe for finding them and fostering them:

  • Don’t accept inbounds, unless you know the person or can vet what else they’ve written.
  • Don’t accept any content that is off-topic.
  • Set a target guest. For me, it is someone who is or was a developer with different viewpoint and perspective. I was especially interested in highlighting voices of people who were not white men.
  • Keep an eye out for interesting posts or interviews. Reach out to the authors and see if they might be game to guest post.
  • Be okay with a cross post. I’d say about 60% of my guest posts are original content, but more recently authors want to post the content on their blog first. Offer a link back.
  • Be okay with a repost, especially if the author is prominent. Review existing content and find one or two articles that fit with your blog’s theme. Ask if you can re-publish. Offer a link back.
  • Some folks will say no. They can do so for a variety of reasons (don’t want to write, don’t syndicate their content, etc), and you have to be okay with it.
  • If someone says “I can’t right now, sorry.” reply with something like “Totally get it. I’ll follow up in 6 months, unless you’d rather I didn’t.” Then, follow up. Sometimes they’ll ignore you, sometimes they’ll have more time.
  • If they are writing original content for you, offer to edit it. Find out how much editing they want. I’ve over-edited a few times and that’s a bad thing if someone is volunteering their time and knowledge.
  • If they ask about topics, advise them to focus. Lots of people want to write about “5 things you need to do” but in my experience, articles with focus on one topic are better received.
  • Write up guidelines so you can easily share. This can include audience, benefits, formatting, delivery mechanism, word count, topic ideas, and more.

Hope this helps. Happy guest blogging!

Thoughts on static site generators and WordPress

Blog in scrabble lettersIn my last few jobs, I’ve done a lot more writing. I’ve learned to work with static site generators (SSGs), such as jekyll and 11ty. I even moved a database driven side project to Netlify. Here’s an interesting survey about SSGs from Redmonk, if you want to learn a bit more. I am also a longtime WordPress user, and think it has some tremendous strengths. I wanted to capture my thoughts on these two options for building your website.

Here’s why I’d pick WordPress for a content heavy site:

  • Avoid any kind of compilation pipeline or step
  • The authors don’t have technical chops and want WYSIWYG
  • You want more than a blog, with additional functionality pulled from the wide world of plugins. Also, themes!
  • You want to allow people to just write, without software getting in the way

Here’s why I’d pick a static site generator for the same:

  • Need performance and scalability at a low low price
  • Wanted ‘set it and forget it’ security (you can’t hack a static HTML page)
  • Authors are technical enough to write markdown and to leverage the data driven possibilities of an SSG
  • No need for interactive functionality, beyond what JavaScript/JAMStack can provide

Like any other choice in software engineering, these two solutions offer tradeoffs.

I think that SSGs are far better for simpler websites, and in some ways they are a more sophisticated version of very early websites. I remember writing a perl program to take a usenet file and turn it into a set of web pages in the last 1990s. (It was jokes, if you must know the content.) When you build and deploy a static site, you know exactly what you’re getting, but you can also extract common functionality to shared files. You will have to compile it, however, and typically uses a version control system, which can be a lot for some non technical folks.

WordPress is fantastic for just getting going. I can get a blog started in 15 minutes that can be used by anyone who knows the basics of Microsoft Word. The flip side of the speed to first page is operational complexity, slower performance (all things being equal), as well as a more complicated application to secure.

I will say that as a developer, SSGs are growing on me.

PS I know some people have combined them both, and using WordPress as the backend and publishing a set of static pages is really appealing. I’ve done some preliminary work on this, but haven’t found a great solution out there.

16 years

Fiat and treesWow, 16 years of blogging. For the record, this is the 992nd post.

Does this mean my blog can drive?

16 years ago I wrote my first post about RSS. I recently just added RSS to a static site generator that had a blog component. What is old is new again, indeed.

Blogging has taught me so much. How to write. How to promote. How to investigate a problem. How to describe what I do to non technical people. How to handle gobs of traffic. How to handle tumbleweeds (aka no one visiting my blog).

I tell everyone I meet to blog. Not for other people, but for yourself.

Having a record of my life (not the whole thing, but at least some aspect of it). Having a chance to help other people. Even just making the time to sit down and think about something deeply. All huge benefits.

Sometimes my posting schedule is less frequenty (especially when I’m writing elsewhere, as I am now on the Transposit blog), other times I speed up (I wrote 100 blog posts in 100 days, it was great).

Either way, I’ve enjoyed this blog immensely, and appreciate everyone who swings by to read a post, leave a comment, submit to an aggregator or subscribes to new posts.

Thanks for 16 great years!

Announcing: Letters to a New Developer

Blank paper, pencil, lightbulb, eraserI’ve been working on a new project that I’m excited to share here. It’s called Letters to a New Developer. It’s a blog with over forty posts full of advice for people who are just starting out in the field of development.

So much of development is not about code. It’s about teams and processes and organizations and questions. I feel like the traditional education system (whether four year college or bootcamp) does a good job of teaching folks coding fundamentals (what you need to be a programmer) but there is so much more to being a successful developer than coding. In my experience, delivering code is a necessary but not sufficient activity for success in a software company.

That’s why I’ve spent the last five months writing up some of my experiences and learnings.

The posts are mostly mine, but some are from guest posters who bring a different perspective. I also excerpt posts I find on the Internet that I find helpful, so that I can stand on the shoulders of some of the giants who have come before.

Here are some of my favorite Letters To a New Developer posts: Always Be Journaling from Brooke Kuhlmann, Get Used to Failure, and Learning to Read Code is More Important Than Learning to Write It.

I hope you find this project as fun to read as I’ve found it to write.

Fifteen years

Birthday cakeWow. 15 years ago today I wrote my first post. Thank you for reading!

I’ve been blogging for longer than I’ve done any other activity in my life. Longer than any job, any romantic relationship, any hobby.

And I can’t see stopping. Sure, I may use other outlets, but I’m trying to keep the streak of no month going by without a post going (darn you, November 2011!). I think that writing is an essential part of software development and it’s been an essential part of my reflective process. I primarily blog for myself. But it is still fun when folks reach out to me and let me know my writing has helped them in some way. It’s also fun when I google a problem and realize that I’ve already written up an answer.

I encourage everyone I meet to blog. It is a fantastic way to accumulate credibility and expertise. (You never learn something as well as when you are trying to explain it to others.) It also gives me a chance to expound on some of my thoughts around jobs, business, and software development. I’m lucky that my work almost always is something interesting enough to write about, at least once a month. Maybe one of these days I’ll put together a ‘best of’ and make a PDF.

I also think it is important to blog at a place you control. Yes, Medium or Facebook make it easier to gain a following. But what they giveth, they can taketh away. I may only have limited engagement here on this blog, but what I write is mine and will never be anyone else’s.

Hard to believe that my blog will be able to drive next year. Again, thanks for reading.

Where I’m Writing

It’s been a bit quiet around here, but since I joined Culture Foundry I’ve been writing over on their site more. I’ve written on a number of topics, but this one about how to move files between different servers in order to scale a traditional CMS application horizontally, is one of my favs:

Compared to the other methods of syncing files, this works well with non cloud native applications. It also has the virtue of using old tested tools. You can use this system on prem or in the cloud, anywhere with SSH and rsync. This system works well with large numbers of small objects because rsync can be configured to only push new objects.

I’ll be splitting my blogging time between this site and the Culture Foundry site in the future. See you there.

 

My first day at Culture Foundry

I am excited to pen that title. I’ve joined Culture Foundry, a digital agency that connects the world through beautiful technology. There are a number of reasons I accepted a position with this firm, but a few that jump to mind are:

  • they are good people. This is important as a great job with a bad manager is no fun. A great manager can help make a bad job better.
  • they are working on interesting technology problems, including API integrations and high traffic websites.
  • they are 100% remote. This flexibility is really important to me.
  • they work on stuff their clients’ value.
  • the team is big enough to take on larger projects, but small enough to be agile.

For now, I’m going to be drinking from the fire hose, trying to get up to speed on their systems, so the blogging may slow down a bit. But I’ll definitely be sharing things I learn from this new opportunity. Here’s to new adventures!

One hundred days of blogging every day

This is a meta post, but it’s been 100 days since I started blogging every day. I wanted to celebrate! And I just wanted to note some lessons.

When you blog every day, it doesn’t have to be as good

Before I started the streak, I blogged at least once a month for the previous year or two. During that time, I often spent a lot of time working on my blog post. Not necessarily days, but hours. This was, after all, the only blog post I was writing, so it needed to be really good. But once I committed to writing once a day, I was focused on getting something out. I still wanted to be proud of it, but there wasn’t as much pressure. It could even be something really short, or just a pointer to a different piece that I thought was interesting (like here or here).

Having a streak forces your hand

A streak makes you make time. There were definitely times when it was after dinner and I still hadn’t blogged. If I wasn’t trying to keep a streak going, I’d have skipped that day.

Opinion pieces are easier to write than technical pieces

It was easier (and more popular) to write a piece on the nature of the CTO/co-founder or what a senior engineer is than it was on an interesting rails gem like after_party or the nuances of Stripe Connect integration. Interviews were the easiest post to write, but required a bit more planning.

More content means more readers, but mostly from one offs

In the months before December, I averaged about 4200 visits/month. In the months after, I averaged about 6300, but most of the elevated traffic came on specific days from referral traffic due to posts I had made to Hacker News. Still, the increase in traffic was about 7% even for months when I didn’t have a post that “went viral”

I feel so lucky to have a place to spout off. Thanks for reading.