Skip to content

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

Lifehack Mistakes Programming | moore |

Why Are Interviews Harder Than The Job?

I’ve seen a lot of startups try to make hiring easier over the years, but they all seem to converge on becoming slightly better applicant tracking systems.

Then, a few months ago, I saw this LinkedIn post.

Here’s the post in case you don’t want to log in to see it.

It’s similar in tone to this meme.

I’m currently leading an interview process at my current job. Whenever I do this, I remember how grueling and painful hiring is. And that is as a hiring manager–I know it is even tougher as a candidate in this job market. After all I am getting paid and many candidates are unemployed. I’ve been in the latter situation and the situation is often quite urgent.

But today, I wanted to dig into why interviews for software related jobs are often harder than the job itself. This is a common gripe, where the interview digs into all kinds of technical aspects that are not really needed in the day to day job, or is much tougher than the day to day work.

The reason for this is interview time is limited. Interviewers want to get as much information as they can about the candidate.

(Interviewees should do this too. Even in this market, finding out what you can about the company where you’ll be working is a good idea.)

An interview is like running 100m and a job is like a 10k. If someone wants to see who is better at running across, but only has a certain amount of time, they are going to have everyone run 100 meters, and not a 10k. Even if the real goal is to find the best 10k runner. Hence the Leetcode tests.

This is, of course, not great. But it is the least bad option.

Some alternatives include:

* contract to hire: This is great if the candidate has flexibility and risk tolerance (health care not tied to a job, willing to risk moving to another job in N months if the contract doesn’t lead to a hire). Many great possible hires will pass at contract to hire, though it does work for some people.
* homework for interviews: Asking a candidate to solve some problem which lets a candidate work in a slightly less high stakes environment. but requires candidates to do extra work, taking longer than just the interview. This also takes longer to evaluate as a hiring manager. And ff you are doing this, make sure you ask candidates to explain their solution, which helps mitigate AI assisted or copy paste solutions.
* pair programming: During the hiring process, work on an actual work related project. Companies that have OSS projects can use those, otherwise use something similar to what a new hire would be working on. Viable, but can be hard to pick up enough signal about non-technical skills. Also high-pressure for the candidate–I remember trying to use IntelliJ for the first time at an interview to write some Java code.
* leverage your network: Hire people you’ve worked with in the past. Time-tested, works well, but limits opportunities for those without experience or a network. Also means as a company you’re going to be more homogeneous, which can limit you (see this 1996 HBR article).
* historical interview: Beloved by the authors of “Who”, with this method you ask a series of questions about the candidate’s history, gleaning insight into their history. If they have done something similar to what you are looking for in the past, they’ll be able to do it in the future. I did this for the current hiring process so the jury is out for me, but am hopeful.

Hiring is hard because both parties have limited data and are trying to present in the best way, yet success is multi-dimensional and may not be visible for months. No easy answers.

Jobs | moore |

How I use GenAI for my memes

I’ve been trying to do a themed funny meme a day for the past few weeks, every day when I work. I share them on my Twitter, Bluesky and LinkedIn accounts.

Here’s my process:

  • Find a meme I understand. I know a lot of memes, but also check Know Your Meme to make sure I understand the context.
  • Use ChatGPT to brainstorm meme ideas. This usually takes 1-2 tries, but the prompt looks something like this: “can you provide 15 funny meme ideas around saml, jwts, passwords, oidc, rbac, or other authentication or authorization related topics. The meme I am trying to use is the epic handshake meme, where the hands in the middle show agreement between two parties on something.”
  • Review the 15 suggestions, modifying as needed based on my knowledge and the memes I’ve posted recently. If I just posted about SAML, I don’t want to do so again.
  • Create a meme using imgflip.
  • Post to the areas above, making sure to use alt text descriptions.

This process takes about 5-10 minutes, with a big chunk of the time being the actual posting. I created memes before all on my own, but it took longer, probably 20-30 minutes. The brainstorming took much longer. I’ve also done meme brainstorming in a committee, and that took person-hours, cycling through ideas.

I sometimes wonder: is this cheating? I’m still part of the creative process, but am more of an editor/refiner than the creator, though I do set the bounds by selecting the meme and creating the prompt. The quality of the memes are at least as good as what I did without any genAI help, so I don’t think this is AI slop, though of course the people looking at the memes are the ultimate arbiters of that.

Would it be cheating if I had an agent do all of this? Would it still be valuable? I also don’t know.

As the cost (in time) of content creation goes down, more and more will be created.

The human attention that I’m competing for hasn’t increased, though.

Content Useful Tools | moore |

How To Plan For A Big Educational Project

I was talking to someone about a big educational project they were considering, something like a book or a course.

They asked about how I’d think about starting such a thing. I wrote this up in a DM and wanted to share it, lightly edited, with the public. Yup, that’s you, dear reader.

For any serious big project that was educational, I’d probably start with a rough topic outline. Then turn chunks of that into ten blog post titles on the topic.

Then I’d write those ten blog posts. This is because I’m a text driven person 🙂 . If you are a video driven person, you might consider making ten videos. If you learn by coding, maybe ten different projects or features in an app. I think that blogging is the best because words are way easier to change or update than video or code, but you do you.

If you are wrirting, Leanpub can be a good way to do this too, because it is easy to publish from markdown. You can also set a price that changes as you write more content. I wrote more about Leanpub here.

I’d also set up an email list so that you can get interested folks’ email and send them updates. Leanpub takes care of this, but any email list tool (buttondown, mailchimp, substack, beehiiv) can do this. Don’t get hung up on the tools, the goal is to have an easy way to collect interested folks’ emails.

Finally, I’d think about how you are going to publicize the project, beyond the email list. Options include but are not limited to:

  • Post regularly on LinkedIn or other relevant social network
  • Share on slacks (in a commercial channel or other blessed way)
  • Go on podcasts
  • Submit a bunch of CFPs
  • Spend time in the relevant reddit or Stackoverflow answering questions
  • Contribute to an open source project applicable to the topic
  • Answer questions on a relevant mailing list

Spend at least 10% of your time thinking about how to get the word out (and doing it!) over the time you’re working on the project. If you don’t, you will end up with a nice project that no one knows about.

Content Podcast | moore |

When Are You Ready To Write A Technical Book?

This question came up on an HN thread.

My process for any book I’m thinking about writing is:

  • write out 10 titles for blog posts on the topic
  • write 1-2 blog posts (this lets you, in a low risk way, verify you have interest/expertise)
  • add an email list signup at the bottom of the posts
  • do a bit of research to see if someone else has written on the topic (some googling or reddit searching)
  • write the rest of the blog posts

If you can get 10 meaty blog posts, you have the basics of a book. Plus, you’ll know that you are interested in the topic and that you can write. As you wrote those blog posts, you probably had related ideas or areas you wanted to explore.

You’ll also be able to share these blog posts with friends, colleagues and online communities that you may be a part of. You can get feedback on the ideas and the overall topic here.

You can self-publish the book (done that) or use a publisher (done that). The latter will take more time and effort and will require you to fill out a book proposal.

To be honest, even if you are planning to self-publish, doing the hard work of completing a book proposal is useful. Even if you don’t submit it. It forces you to think about:

  • who is my audience
  • what are my core ideas
  • what else has been written on this topic
  • why is what I’m saying unique
  • why am I the right person to write this book

This can help you narrow in on what will make your book successful and can help with your marketing messaging.

What If you can’t write 10 blog posts about a topic? Then you are missing either:

  • interest in the topic
  • necessary knowledge

But it’s more likely the former. Because you’ll have time to do research to learn. I remember taking something like 4 hours to answer one question about how the Cordova CLI acted in one peculiar edge case. It turned into one sentence in my book.

Finally, if no one else has written anything about the topic (no books, no articles, no social media posts, no nothing) and/or none of your blog posts get any feedback (positive or negative), pick a different topic or expand your vision.

Here’s an exchange I had with Patrick McKenzie in 2013. I wrote:

I had a quick question. I was thinking about writing an ebook for a super niche topic (testing ETL transformations using Pentaho Kettle, an open source ETL tool).

I outlined the book, did some google searching and wrote up a series of blog posts with an email list signup at the bottom.

I got some nice retweets from folks in the Pentaho community and have about 8 people signed up to the list. That was a bit disheartening, but a friend suggested that the folks doing ETL work weren’t exactly developers (perhaps more DBAs or business analysts).

I am still tempted to write the ebook, given my interest in the subject–I think it is a pretty cool tool that I wish would replace lots of data munging scripts, and testing software written using Kettle makes development with it much more fun. On the other hand, I wouldn’t mind some income.

Is this too niche a topic? I’ve been a generalist for most of my career, and if I don’t write this now, in 6 months I probably won’t have the desire or knowledge to do it again (though I might find another software niche to write about by then).

His answer was:

I regret that I have absolutely no knowledge of anything you just said. In general, I might suggest something slightly less niche (you can reasonably suspect to sell 2 copies to 8 people, so unless it is going for $10,000 a copy, might want more volume). You’d still learn a lot publishing it but for the same amount of work why not write on a subject big enough to support 100 or 200 people interested in it?

I could have expanded this topic in several directions:

  • focus on more general ETL testing
  • expand beyond ETL and look at patterns for testing data manipulation
  • focus more on the tool and write a guide to pentaho development, including testing

Or, treat the exploration as an end in itself and not write a book. That’s always a valid outcome of this process of experimentation.

Books Content | moore |

Documentation For Devtools

I have been spending a lot of time working on documentation for FusionAuth over the last couple of years. It’s been a learning experience for me. While it hasn’t been a full time position, I have worked on various aspects of our technical documentation. Some of the things I’ve done include:

  • Modifying or extending the tech stack with components or plugins. We used Jekyll and then Astro for our docs. They each have different strengths.
    • Jekyll feels long in the tooth but has a solution for everything because it has been around so long.
    • Astro feels shiny and new and has nice build time errors. It also evolves more quickly. On the downside, there have been times we had to build our own solution because no one had built it for Astro yet.
  • Extracting out common text to share across document sections, including using variables.
  • Reading lots of code and trying tasks with the product to make sure I understood behavior.
  • Building diagrams using PlantUML and Mermaid.
  • Revamping the user navigation and experience multiple times.
  • Looking at common questions that have surfaced from support tickets, sales conversations and the community and writing doc to answer those questions. This serves multiple purposes:
    • Someone can self-serve the answer to their question, using Google, and may not need to talk to us at all. Devs love that!
    • Support or sales engineers can point questioners to the documentation. They can then spend time adding nuance, rather than copy pasting or worse writing answers from scratch.
    • They help anyone in the company understand product features, including people who might work on a different part of the codebase.
    • By being public and used, these docs stand a good chance of staying up to date.
  • Worked on long guides for deep technical topics, such as one about sessions and another about searching. These are fun to begin with and then become more and more repulsive to me over time. I can barely make myself read the final draft “one more time”. But that kind of write-review-refine-hate-publish cycle is so important for quality doc.

I think we’ve done a good job of documenting our product from a technical perspective. One data point: a competitor said that a challenge of using our product is that the doc can be “overwhelming”. I agree, it is voluminous but sometimes confusing; there’s definitely there’s room to improve. But they are critical. Our docs are the main way people find us and evaluate our solution. They are read and referred to by developers inside and outside of our organization.

On the flip side, one founder I respected when I worked for her a few years ago said “no doc is the best doc”. Her reasoning: the goal of any tool should be to make usage so intuitive that there is no need for a user to read the documentation. Hard to disagree with this, right?

Wait, but I just said docs are critical to FusionAuth’s adoption. What gives?

It comes down to what devs want, when. It should be no surprise that devs want different things at different times.

Keith Casey did a good job of outlining it here, saying we need to answer two questions to help sell to devs:

  • How does our tool help developers build something useful or go home?
  • How do we demonstrate that and speed them along?

If we can’t speak to and demonstrate both, we have a toy, not a tool.

Having an intuitive interface primarily helps with the first goal. When someone is using your tool, can they build something useful? If a dev can’t figure out how to move around and accomplish what they want to do, whether that is because of jargon, bugs or overwhelming complexity, they can’t.

Good UX also helps with the second part of the second question. An interface so good docs are superfluous means it is quick to build something.

Therefore, the “no doc is the best doc” founder was right.

However, devs are not always going to take the time to poke around your tool, especially if you require them to sign up or download something. Great docs, in contrast, help with demonstration. A dev will believe your documentation, at least until you give them reason to distrust you. Statements like “tool X can help you solve problem Y” with instructions on actually doing so, help devs. These developers might be evaluating multiple tools, or even just curious and wanting to learn about your solution. Doc can help them decide whether to invest more time and take the next step. It’s far quicker to scan a doc than it is to sign and navigate a tool.

You can also, with doc and example applications, show how to integrate your devtool into existing architectures or systems. This is relatively easy to do with documentation, sample code and screenshots. It is more difficult to do inside an application UX. You can also cover nuanced topics in-depth and using doc in ways that would be tough to do inside an application’s interface.

Doc also helps with discovery via SEO or LLMs, both of which ingest text. Google is the main way I navigate many devtool focused docs.

(Discovery does assume your devtool docs are public. Requiring registration or payment to view documentation is quite a high barrier for evaluation. I’d avoid that unless you have a monopoly or captive market of devs who must use your software.)

Therefore, the “doc is important” experience I mentioned above is also correct.

You want both an intuitive interface and great docs for your devtool. They serve different purposes.

Content Devrel FusionAuth | moore |

Extracting Written Content From Podcasts And Livestreams

I wrote before about not wasting content that you’re creating as you answer questions or interact on communities like Twitter, Bluesky, Discord or Slack.

One great source of content for your newsletter or blog is podcasts or livestreams that you are on. Here’s how I’d do that with an example podcast interview I did a few months ago.

First you need to transcribe it. Most podcasts and livestreams are posted to youtube, and my go to tool there is youtubetranscript.com. Here’s the transcript of the interview. I know people who are happy with Descript and I’m sure there are other solutions out there.

Most podcasts are a wide ranging conversations with multiple possible newsletters or posts contained within them. Sorting out these topic areas is a great use case for AI.

Paste the transcript text into Claude.ai and ask for topic grouping as well as verbatim text for the beginning of each of the topic groups.

Here’s an example of the Claude output:

Content Creation and Repurposing Strategies
Starting text: “I think that the reason I wrote this blog post is because I am a member of a lot of different slack communities or follow people on again on some of those platforms that I shall not mention and I see some great great content that comes out and great answers great wisdom and then it just and then it goes poof away”

Themes:

  • Leveraging existing content from platforms like Slack
  • Low-effort content creation
  • Transcribing podcasts for newsletter content
  • Maintaining authentic voice while repurposing
  • Best practices for newsletter creation

Claude identified five topic areas in this transcript. Once you have this, go back to the raw transcript. Search on a unique text string and. Pull out an interesting, relevant section.

I use the youtubetranscript site to understand where I stop talking and other people start. You can click on a section in the text and view the corresponding part of the video. There may be an AI solution or a specific GPT to do the transcription and have it include speaker names, but I haven’t found one yet.

Here’s an example section that I extracted:

I think that the reason I wrote this blog post is because I am a member of a lot of different slack communities or follow people on again on some of those platforms that I shall not mention and I see some great great content that comes out and great answers great wisdom and then it just and then it goes poof away and even on some some like I follow the ietf emailing lists around ooth and things like that I see some great content there but it it especially in in slack but even in those other places it just gets lost and so my point was by picking up and putting it onto um a newsletter you can and maybe you do some editing right because most stuff that you you um write off in a slack it might not be as Pol as you would normally put a newsletter but you can basically take this um wisdom exhaust right like it’s like kind of like data exhaust from the early 2000s but you can like pick it up and put it together and even if you don’t think you have enough content for a newsletter I think you do if you are active on those channels and by taking it from these walled Gardens of the platforms or slacks or discords and putting it out on a in a newsletter you do a couple of things one is you just showcase Bas your knowledge um the same way a Blog would you can deliver it to people you have a low effort way to connect with folks right if you ever run into somebody a conference or whatnot instead of asking them to follow you on something you can say hey I have a newsletter about real estate in Atlanta or I have a newsletter about how developers are the new king makers or AI or whatever it is and that’s just a lower ask than some other things and it will start to build up a longer term relationship with anybody that you’re um engaged with at low effort to you so that’s kind of the the purpose of the blog post is people are creating all this beautiful content and it’s just trapped especially stuff in slack

This one section is 383 words. This is the kernel of a newsletter edition or a blog post. However, this needs some work. I can’t copy it directly into a newsletter or blog post because I don’t talk as clearly as I write.

Let’s take the above content and lightly edit it to be something I’d feel comfortable publishing.

The reason I wrote this blog post about not letting your content go to waste is because I am a member of a lot of different slack communities where people post great content. I also follow people on Bluesky, that which was formerly Twitter, and other platforms where, again, people are dropping lots of knowledge. This even occurs on IETF mailing lists. There the content is available but it can be difficult to separate the gems from the dross.

I see great great content published and great answers for common questions. Then it goes “poof” away.

Especially in slack but even in those other places, this content just gets lost.

By picking up and putting it into a newsletter you save it. You have to edit it, because most Slack posts are not as polished as newsletter content would be.

But even with that work, you can basically take this “wisdom exhaust” and repurpose it. It’s kind of like data exhaust from the early 2000s. Even if you don’t think you have enough content for a newsletter, you do, if you are active on those channels.

By taking it from these walled gardens of the platforms, slacks or discords and putting it out on a in a newsletter, you do a couple of things.

  • you showcase your knowledge
  • you deliver it to people’s inboxes so they remember you
  • now you have a low effort way to connect with folks; if you ever run into somebody a conference or whatnot instead of asking them to follow you, you can ask them to subscribe to your newsletter
  • you start to build a corpus of knowledge and a set of people interested in hearing from you.

I edited to clarify and expand on the content. I added links where appropriate, and also updated it–Bluesky wasn’t a big thing when I did this podcast.

This is fewer words, but a firm foundation for writing a longer blog post. I could also review the transcript for more of my words.

So, that, in a nutshell, is how you can easily generate written content from a podcast, recorded presentation, or livestream.

Blog Content Newsletter | moore |

Startup Opportunity Gains

As a former startup founder and an employee or early contractor of five other startups, there are costs an benefits to joining a startup. But first, what is a startup? Investopedia says:

The term “startup” refers to a company in the early stages of its operations. Startups are founded by one or more entrepreneurs who want to develop a product or service for which they believe there is demand.

Startups can be either bootstrapped (hard) or raise money (hard). But they are focused on growth. In my opinion, if a business isn’t scalable, it is not really a startup.

  • A laundromat: not a startup.
  • Laundromat management software: startup.
  • Being a real estate broker: not a startup.
  • Building a tech focused real estate brokerage: startup.
  • A web development consulting company: not a startup.
  • A company building product that makes web development easier: startup.

The lines can be blurry of course; if you start a laundromat and make a custom app to improve operations, you can perhaps use that software as the foundation of a laundromat software startup.

I know there is absolutely an opportunity cost to starting a startup, but I don’t want to focus on those. Buy me a beer sometime and I can chat with you about that.

This growth is the key to the benefits. Because of the growth, you’ll learn a ton about a bunch of different parts of building a company. These can include:

  • devops
  • hiring
  • product
  • creating process
  • conflict resolution
  • customer support
  • sales

Of course, what you learn depends on what stage you join a startup and the role you are hired for. But in my experience, especially at startups under one hundred employees, there’s so much work to be done that you can help almost anywhere. (If you are an engineer, talk to your manager before jumping into a sales call, though.)

All of this is exposure you won’t get at a bigco.

Of course, you need to ask yourself if that is what you want to do. Some people are happy building a system and business, while others are more content when embedded in a system which can make them productive.

And even for the same person, you can be ready for different challenges at different times of your life.

 

Startup | moore |

Is A Piece Of Software Ever Done?

I was thinking about this in the context of the Bending Spoons list of acquisitions.

When you are starting out writing any piece of, it seems like there is a limitless amount of new, useful functionality to add. Yes, even sometimes reading email.

But just as a building goes through phases of construction and ends up done, I believe software can be finished too.

I do not mean that the software is abandoned either because it isn’t used any longer or because an adequate substitute for custom built software is purchased. In these cases the software is unused, not finished.

I also don’t mean theoretically complete, where it is bug free and does exactly what is in the spec, as discussed here on Reddit about /bin/true. I don’t think any non-trivial piece of software ever reaches that point.

My definition of finished is when the software is still being used, but the long term value of adding new features to the software package is exceeded by the cost of adding those features.

Finishing software in this manner is different than finishing in physical construction because:

But just as there’s value in personally ending projects, I think there’s value in calling software done.

What would this mean?

  • the software would continue to be valuable
  • the value of the software would depreciate over time
  • some users would continue to use it, others would not
  • most of the team which built it would move on to different endeavors
  • there would need to be a team to do maintenance

Wait!, you say. Software is bits, and those don’t decay, so why would depreciation happen? It would happen in a similar way to how it happens in buildings. A building can become less useful because of:

  • wear and tear, breaking down the physical infrastructure
  • changing styles, making it less desirable
  • new needs of inhabitants/users that it has difficulty meeting because of the way it was built

The latter two apply to software as well as buildings.

While I think it is easy to vilify companies like Bending Spoons for buying software up, laying off most folks, and changing the business model, I’m struggling to understand how it is it any different than buy up a finished building and renting it out while doing minimal maintenance.

What am I missing?

Programming Technology | moore |

Paying attention to competitors

How often do you check out your competitors? And how deeply?

If you are working at any kind of business, you need to know what the market looks like. This includes the services offered, new features or capabilities and pricing. Pricing is very important, and you should try to know both the public pricing and the real pricing. The latter is tough and part of why secret shoppers are a thing; your customers who have talked to competitors but chose you might also be able to help.

If you work in devtools, you also need to know about how competitors are actually used:

  • integration time
  • migration complexity
  • long term ROI/issues

How can you find out about this? You can:

  • read their website
  • read their code (if they expose it)
  • read their forums or slack channel
  • subscribe to their newsletter
  • set up a google alert for them
  • use the tool

However, all of these have flaws.

A marketing website can be tough to extract information from. And technical documentation can lie^H^H^H^H be inaccurate or out of date.

Reading code to understand it is helpful if you are zooming in on specific feature, but most users of whatever the tool is are going to be interested in solving a problem, not the intricacies of how a problem is solved. Code isn’t always available or in a language you know, either.

Reading feedback and questions from a community around a product can be fruitful, but you will only see problems, because happy users rarely post. It is a good way to find out about longer term challenges, though. If you do this and reply to messages, you should 100% never shill your product. That’s like going into a Wal-mart in a Target shirt and walking up to customers and trying to get them to leave with you. Not a good look.

Getting a newsletter keeps you on top of their messaging. However, understand that a newsletter will show them in the best light.

Setting up a google alert can be helpful in getting you an understanding not just of what they are saying about themselves, but what the wider internet is saying. However, there can be a a lot of garbage in there. If the competitor is a public company, you’ll get more stock tips than technical evaluation.

I think the last choice, using the tool to solve a problem, is the highest effort, but will teach you the most. You’ll have to spend money and time.

Since you aren’t using their software in a production context, you won’t get a full picture, but you’ll have an idea of the integration joy and pain that their users will feel. You should ideally do the integration on a cadence so that you keep up with changes and features.

Great. You should learn about the competition.

But how do you figure out how your competitors are? That’s what I’ll cover soon.

Business Startup | moore |

Don’t Let That Content Go To Waste

If you are a member of an online community and you participate, you’ll often write a few paragraphs in response to a comment or question. This is also true if you use a social network like LinkedIn well. Both of these let you share your knowledge and experience with low effort.

While you can definitely gain visibility, your wisdom will only benefit a few people.

If you posted to a synchronous community, the people who happened to be around when you posted will benefit, but no one who visits the site in a few months or years will. Okay, if someone is determined, they might struggle through a search for the topic and find it. If what you write is really memorable, other people might link to your post. But most of what you share will go straight to the Slack memory hole.

If you post to a social network, you are at the not-so-tender mercies of the algorithm. What you write might surface for your followers a day or week later, but a month or year later it’ll be gone. Detritus floating on the scouring stream of witty content and pleas for attention, if you will.

But you spent precious time creating that post. You’re an expert in your field, and you post about it. You shared your experience and your wisdom. Why should you let it go by the wayside? Is there a way to leverage it without too much effort?

Yes.

Capture it in a newsletter or blog post. I prefer a newsletter, which has the following benefits:

  • you can easily build an audience of people who want to hear from you
  • you can have your ideas posted to a permanent URL that Google can find and others can share
  • a newsletter can be casual

First, you need to select a theme, usually related to your professional goals, and then set up a newsletter. Examples of themes can range from database optimization to product marketing; it doesn’t matter what the theme is as long as you have expertise and plenty to say. The nuts and bolts of setting up a newsletter and adding a subscription form to your website are well covered by the newsletter providers (Beehiiv, Substack). Therefore, I want to focus on the next step, gathering and publishing content.

After you read this post, you’ll know how to gather and publish the scraps of insight your share around on communities or social platforms in a sustainable regular way. You can start getting the first one hundred subscribers to your newsletter; people that want to hear from you.

Doing so is a four step process:

  • gather sources
  • schedule scouring
  • tell a story
  • schedule it

It’s important to not let the perfect be the enemy of the good. Finding, editing and shipping existing content in a newsletter is a process that you’ll get better at, but you don’t need your newsletter to be perfectly manicured like one of the big newsletters, or a newsletter from a large company. You may build your newsletter into that, but to get started, the goal is to enable you to send a regular newsletter. Remember, we want to avoid letting that great insight languish.

Let’s look at each of these above steps.

Gather Sources

First, gather your sources. I start with a google doc and write down links for everything that might be a source of newsletter content.

This includes social media platforms where long form posting happens, such as LinkedIn or Facebook. Also, include sites where you write substantive comments, such as Hacker News or Reddit.

The real gold is often in private communities such as slack or email lists. Make sure you respect community rules and never use someone else’s content. But your long, detailed answer to a common technical question is perfect for touching up and publishing to your newsletter list.

Another place to look for newsletter content is livestreams or podcasts you are a guest on. The technical conversations are a great source of content for a newsletter.

Any fully-formed GitHub project READMEs can also be good content, especially if they talk through the use cases of a particular tool or project.

Wherever you share insights related to your newsletter theme, especially if it is long-form and ephemeral, is fair game.

Add these to a list. Keep it up to date; as you appear on a new podcast or start posting thoughts elsewhere, add the links.

Scouring

Next, find some regular time to review these sources. I suggest doing this once every two months, but the right frequency depends on how many newsletters you want to send and how often you post.

In the google doc, do the following:

  • mark the date you reviewed
  • copy and paste the text
  • capture the link

Don’t grab one to two line comments or anything that is off-topic of your newsletter . Instead, look for the multi-paragraph insightful comments. If there was a discussion, grab all your comments. Don’t forget to grab any links you mention as well.

How exactly you grab the text depends on the source:

  • If you are looking at LinkedIn, you can search for all posts and comments you have made.
  • If you are using a podcast or video stream as a source, For these, you can use a tool like Youtube Transcript to extract text and then scan to find insights that you can repurpose. You can use GenAI tools to group the text into high level topics that you can portion up into newsletters.
  • If you are posting on a slack, you can search for all your posts using the from modifier.

Each source will have a different way to find your content, but after the first few times it’ll be second nature to grab it.

Tell A Story

The next step is to take the raw text and turn it into a coherent story. You want to do this every month or so, though you may need to front-load this if you are starting a newsletter.

You’ll need to spend some time on this process. The goal is to create something worth sending out to your readers.

Each post should be:

  • 500-1000 words
  • coherent; if you are merging together more than one comment, make sure tense and pronouns agree
  • edited; remove fluff words and anything that distracts from the point, especially if you are condensing a podcast section
  • on theme; if you are a devops consultant, don’t post about ice cream stores, unless they relate to devops

You will end up with a solid newsletter post. Mark this fragment with the date you reviewed and turned it into a story. This will prevent you from using the same text in six months.

In my experience, this is an AI-aided manual process. You can use the AI to condense podcast text, think of alternate angles, or give you feedback on any other areas to cover. But what you should not do, unless you want a newsletter that sounds robotic, is paste your text into ChatGPT and ask for a newsletter-length block of text.

Don’t rewrite the text. The whole point of this process is to leverage existing content you have created in a low-effort, sustainable way.

Since you have all your content in one place, you can repeat this process to get many newsletters ready. I like to get as many ready as I’ll send out in the next month.

Then, schedule them out.

Schedule It

You’ve done all the hard work, scheduling is easy.

Make sure any platform you select supports scheduling out newsletters.

Test sending them to yourself to see what they look like.

Schedule each story on a regular interval. I like to send on the same day of the week every time. Once every two weeks to once a month is sustainable but will keep you top of mind.

If there’s timely news that you want to address, you can bump one of the other newsletter editions.

Summing Up

This process is the start of a journey that will end with a permanent, searchable corpus of your insights, at relatively low cost in terms of effort and time. It also ends with you having a list of people who want to hear from you about the topics you cover.

You will no longer be letting your content go to waste.

It is not, however, a quick process. You may send newsletters to hundreds of subscribers for years. There are two ways to think about that:

  • oh man, I only have 200 subscribers and therefore I compare poorly to people who have tens of thousands of subscribers or more
  • oh my, I have 200 subscribers who want to hear what I say and are willing to let me into their email inbox regularly

Which do you think is the better perspective?

Content Newsletter | moore |