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 |

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 |

Great GitHub actions for techdocs sites

There are two main options for techdocs sites. You can use a SaaS solution like Readme or DeveloperHub. Or you can use a static site generator like Jekyll, Hugo or Docusaurus. There are strengths to each approach, but for this post I want to look at continuous integration/continuous deployment (CI/CD) tasks you can run on staticly generated tech documentation.

Why use CI/CD for your docs site? CI/CD tools let you automate code or documentation tasks. For documentation, you can run checks to ensure consistency and correctness which make your documentation better.

GitHub Actions is the CI/CD tool I’m going to refer to, but similar functionality is available with other CI/CD solutions such as CircleCI or Jenkins. Additionally, I’ll talk about the content living on GitHub in a repo, but you could use self hosted git, gitlab, bitbucket or other version control solutions.

This post has a couple of assumptions:

  • Your content is in version control.
  • Your content is in a format that needs to be processed before it is ready for publishing. In other words, you are editing text files in a certain format (markdown, asciidoc, etc) that are then processed, rather than using a WYSIWYG editor.
  • The people writing your content are comfortable using version control and tools like markdown.

Here are tasks you should automate:

Deploying The Documentation

This is the first one and the easiest win. You should have a workflow which automatically deploys changes when a PR is merged to your primary branch. This lowers the barrier to entry for contributing to documentation, because you only need to get a GitHub PR approved. Similar to continuous deployment of a SaaS application, it makes it easy to push changes regularly. Because it is a GitHub PR, it also is easy to roll back–you just revert the PR.

You may wonder at my including this, because it seems so obvious, but I’ve been on teams where the deploy process included sshing to a server, pulling the branch, and running a script.

Automating deployment was well worth it, because it changed “I found a typo, oh man, what a pain” to “I found a typo, I can push a PR and fix it in 3 min”.

Vale

Vale is an amazing, free linter for your prose. I haven’t witnessed it used at its full potential, but it is a spell checker, word police and living style guide all in one. It’s kinda imposing to start with since there are so many “nerd knobs”, but start simple and add to it as you learn it.

Vale runs fast enough you can have it run on every PR.

Spelling

Deploy a spell checker to run against your documentation to prevent misspellings and typos.

You have two choices here:

  • spell check just the changes (vale is good at this)
  • spell check the entire site (pyspelling is good at this)

The former lets you block a PR if there’s an issue, while the latter takes a lot longer and should run on a schedule. The latter is a good fit if you have non-technical docs (perhaps from a marketing site) that you also want to check for correctness.

You should plan to add a lot of words to the ‘known words’ file because most techdocs have jargon or names that aren’t in standard dictionaries.

Look For Dead Links

Running a link checker regularly will help your users avoid 404 pages. No matter how cute they are, they annoy folks because a 404 is a dead end. Techdocs are all about enabling end users to solve their problems and a 404 page doesn’t help.

You should run the checker periodically and fix busted links as soon as possible. I haven’t found a way to run it quickly enough to link checking on a PR. (Update July 7: someone on a slack pointed me to this open source partial link checker. I haven’t tested it, but they say they use it.) I like this fast link checker which catches 404s but also will error on page anchors that don’t exist. The latter are not as annoying as the former, but still impact developer experience.

Side note: link checkers only prevent internal linkrot. You can prevent external linkrot by being assiduous about your redirects. Never let an external link be sent to the home page or, worse, a 404 page.

Check For Closed Issues

Often documentation references an externally facing issue tracker, such as GitHub issues or Jira. After all, if there is a known problem that has a workaround or enhancement planned, adding a link to an external tracker lets the dev audience know and can help them accomplish their goals or know to wait for a future release. Often issues are closed but are still referenced in the docs, which means that the link is confusing.

This job mitigates that by iterating docs, looking for issue links, then checking to see the status of the issues. If the issue is closed, this task reports the problem that the doc can be updated.

Shrinking Images

Small images lead to a faster experience for your users, but it can be hard to remember to shrink the images as you are creating documentation. Automating such image shrinking using a tool like tinypng is an easy way to improve user experience.

This is best done on a pull request, but will require committing the changes using a tool like git-auto-commit.

Generic Content Checking

You can write a shell script using grep to look for known content issues. Examples:

  • Images without alt text.
  • Documents without a title or description tag.
  • Alt text that is not a full sentence.
  • Descriptions that are not a full sentence.
  • Enforcing that every blog post is in a known category.
  • Absolute URLs that point to your docs site. Everything should be relative so it’s easy to stand up locally.
  • Markdown syntax issues

In practice, this looks like: exit `find astro/src/content/ -type f -name "*.md*" | xargs grep ']()'| wc -l |sed 's/[ ]*//g'`

That one liner looks for a markdown link with an empty URL. The above GitHub action will fail if there is a non-zero exit code.

Custom Checks

Once you start automating content quality checks, you’ll find opportunities everywhere. Some ideas:

  • If you show example applications on your techdocs website, but store the code elsewhere in a repository, you can check to see that the numbers from each source are equivalent.
  • If you have handcrafted JSON examples, making sure they parse using a tool like jq. It can be easy to miss an errant comma.
  • Making sure every API page has example code on it.

As you look at your docs, I’m sure you’ll think of others.

How To Handle Errors

Many of these tasks will throw an error when something is incorrect, such as a misspelling or syntax error. There are two ways to handle these errors.

  1. If you can run the check quickly enough, run it on every push or every opened PR and provide feedback for fixing the issue. The doc author can then handle it immediately before the PR is merged.
  2. If the check takes a long time, like spell checking your entire site, then run it on a schedule. The last person to edit the workflow will get the notification, so it’s best to catch the error and have it send an email to a shared alias to capture the issue and then fix it.

Also, configure these tasks to be run manually (the workflow_dispatch event for GitHub actions). This helps with troubleshooting or testing when a fix has been made.

Conclusion

All of these tasks can help you remove some of the toil from creating an excellent techdocs site. You don’t have to do them all at once, but adding them will reduce your effort and increase your documentation quality.

Content Devrel | moore |

Open source is code escrow on the cheap

I read this article a while back about the VC backed open core playbook. Worth a read.

If you haven’t had a chance yet, the playbook is:

  • start an open source product
  • create a company around it
  • use the siren of open source to drive adoption
  • take VC money
  • continue to developer the open source solution
  • build out closed source functionality, typically as a hosted SaaS
  • over invest in the closed source edition
  • let the open source version wither on the vine
  • profit !?!

The crux of the argument is that the open source version of whatever software is being sold is a pure marketing play, and that all the focus will eventually arrive on the closed source extensions or functionality. After all, that is what drives the revenue, and since the company took VC money, they need outsize revenue.

There are a few flaws in the argument, including, but not limited to:

  • it is possible, and even likely if a project succeeds, that there is a community of other companies that will drive the open source project forward under another name (see Opensearch or Valkey)
  • the marketing value of the open source project doesn’t necessarily recede as the closed source functionality drives more revenue; it may even grow
  • not every open source company is VC funded

But I’m going to set all those aside for now, and focus on the value of open source for the end developer. In particular, why is that so attractive to devs? Why is it such a powerful marketing tool to drive adoption?

There are two reasons OSS is important for dev focused tools:

  • permissionless access
  • derisking the future

Let’s dig into each of these.

Permissionless access

When a product is open source, a developer can access it, typically by downloading and running the code, without talking to anyone. They don’t have to fill out a ‘contact sales’ form or give any information to the vendor. By the way, marketing departments hate that, not because they want to spam developers, but because it’s really hard to do modern marketing when you have no idea who your users are.

Just as importantly, a developer downloading an OSS project does not have to ask for money or permission from their own organization either. They are spending time, which is an opportunity cost, but for typical developers that isn’t an expense that is tracked too closely. Even agency developers billing by the hour have time to explore and can justify investigating a tool if they think it will speed delivery.

Decreasing the friction of trying a tool means, all other things being equal, more people will try it. If the product is good, and by that I mean it solves a need, this is the first step to adoption.

Derisking the future

Whenever a developer picks up a tool, whether it is a SaaS product or a library, they do so with the knowledge that the tool and the uses for it will break something in the future. This is an unfortunate side effect of the fluidity of software and anyone who has spent days or weeks upgrading from one version of a framework or library to another will understand that it is part of the job.

Using an OSS tool derisks this unpleasant task in two ways, and therefore makes the future better for the developer, increasing the attractiveness of using OSS.

The first is bug fixes. It is quite frustrating to be stopped by a bug in a software library you are using. I still remember decompiling java classes two decades ago to characterize a bug in a software package we were using. I found the bug and then had to raise an issue with the vendor; in the meantime I had to code a workaround.

When you have access to the source as a developer, you can do the fix yourself. You typically want to upstream it to the vendor to ease the burden of maintaining a fork, but you are not stopped in your tracks. And finding the fix is easier because the source and build instructions are available.

The second is operations. If pricing gets punitive or the vendor has a hard time operating the software in a way that meets your availability needs, you can run it yourself. Or, if you don’t want to, you can pay someone else to do so. If the software is successful enough, a hyperscaler may offer a managed service (hello Elasticsearch!). Having  competition for running the product makes it less likely you’ll be stranded engaging with a vendor that doesn’t meet your needs. It’s code escrow without paying Iron Mountain truckloads of cash.

Conclusion

I think the risk of relying on OSS companies that take funding is real. VCs aren’t in the business of giving away value, so there will eventually need to be a business model and I think that the author of the original post described what is unfortunately a pattern. But developers justifiably value the benefits of OSS highly too. Permissionless access lets them get on with doing their job while source code availability derisks future problems.

I predict we’ll see more OSS companies started in the devtools space because of these factors. But the long term trend of successful companies moving from OSS licenses to more restrictive ones will also continue.

Business ElasticSearch SaaS | moore |

What I’ve learned from a weekly newsletter

I run a weekly newsletter focused on customer identity and access management (CIAM), and it just hit 53 issues, which means I’ve been writing it for about a year.

Thought I’d share things I’ve learned.

Weekly is a big commitment

Make sure you want to do this.

Writing a post every week is a bit of a grind. However, just like with blog posts, you can batch up newsletter posts. There are some weeks when I write three or four posts and schedule them out. This means that I can regularly take a week or two off.

Scheduling will vary based on your topic, of course. If I were writing a newsletter about news or current events, scheduling wouldn’t work.

But for many topics it’s a great way to keep the content flowing while not being tied to the keyboard every week.

Great way to keep on top of an industry

There’s a reason there are many newsletters with this approach. It’s a way to keep in front of interested readers, but it also forces you to keep on top of the particular industry you are writing about.

Due to the deadlines mentioned above, you’ll be forced to regularly think about new trends, find articles and books, and read people writing about the industry or topic you are writing about.

The corollary to this is to make sure you love the area you are committing to. If I wasn’t interested in CIAM, it would be a lot harder to write it. (Of course, nothing is forever, and when it makes sense, I might wind this newsletter down the same way I’ve stopped other projects.)

Have some way to keep track of good ideas

You never know when inspiration might strike.

I like to mail myself content and ideas that I think might apply. I write ‘for ciam weekly’ somewhere in the message.

Then, when I have time to sit down and write, I can search my email for ‘for ciam weekly’ and see all my proposed topics.

You could do something more organized like having a spreadsheet or a folder, but I feel like this works for my level of commitment.

You have to promote it

You have to promote the newsletter. You can’t expect people to find it. Places I’ve promoted it:

  • Hacker News (here’s a podcast I was on where I talk about how to interact with that site)
  • Various slacks I’m a member of
  • In other substacks (referrals)
  • My LinkedIn and Twitter (often scheduled)

Your list might look different but don’t forget you have to do this.

But. Don’t be a drive by promoter. I don’t post in places I don’t frequent.

You can vary between original articles and commentary

I have written some long form posts, in particular a series about the multiple ways user data gets into a CIAM system.

I have also written commentary, where I look at a blog post about password honeypots or other articles that discuss CIAM topics, and reflect on that content.

Both work fine; varying up the content is a great way to keep things interesting for me and my readers.

It’s a long game

I have 80 subscribers with an open rate that is around 50%. Some might look at that and say “after a year, you only have 80 subscribers” and shake their head.

I look at it and say “there are 80 people who want to read what I have to say about CIAM!? And at least half of them read it!”

Newsletters are powerful because they deliver your thoughts to your readers’ inboxes, but they are a long game, especially when niche.

ciam Newsletter Tips | moore |

Tech talk checklist

When you do a software related talk at a conference or a meetup, there are lots of things to consider.

This is a checklist so that next time I do a talk, I have something to reference.

My target audience is technical folks at meetups and conferences where the audience size is 5ish to 100ish. I’m sure things change as audience size and content types do.

Slide content

  • Have a QR code for slides
  • Have a QR code for any other action you want
    • “Apply for a job with us”
    • “Try our software”
    • “Read our content”
  • End on QR code slides and include “thanks” and contact info
  • Have a resources slide with more info
  • Display your twitter/social handle on every slide in the corner
  • The infamous about me slide
    • Make it quick (> 1 min)
    • Even “who cares”
  • Have a conclusion slide just before the QR code/Thanks slide
  • Ranking of content (all other things being equal)
    • Fewer words is better than more words
    • Pictures or memes are better than words
    • Animated diagrams are better than pictures
      • Easy implementation: have multiple slides that you arrow through
    • Demos are better than animated diagrams
  • Audiences are forgiving of demos, but you can always record a video for backup if the stakes are too high
  • Make code big enough to read
    • Including if you are displaying it from your IDE
  • Highlight important code bits with color
  • Add code to liberally licensed repo
    • Include on the resources slide
  • If presentation is long, break into sections and have section nav on the main section pages to orient audience
  • Don’t be afraid of too many slides
    • Be afraid of people reading your slides
    • Be afraid of boring people

Delivery

  • Sections of audience won’t be paying attention
    • Focus on those who are
  • Remember that you are the expert and people want you to succeed
  • Pause for questions
    • Include a slide or time at the end
    • Incorporate answers into talk if you get them regularly
  • Be good about time limit
    • Practice
    • Cut stuff in the middle (questions, other sections) to get to conclusion

Prep/Followup

  • Promote on socials (schedule it)
    • 2-3 weeks out
    • 2-3 days out
    • same day
    • after (include slides)
    • Tag the organizer or conference/meetup if you can
  • Don’t plan on doing anything intense the hour or so before your talk
  • Download a PDF of your presentation in case you don’t have internet
  • Get to the presentation room at least 15 minutes ahead of time
  • Test AV connections including mic if needed
  • Bring your power cord for your computer
  • Connect to people who attended talk if they send a request
  • After talk, hang out for a bit if you have time, to chat with folks. Many won’t ask questions during talk, but will after.

I’ll plan to add more to this as I think of it, but this is a good starting checklist for me.

Devrel Presentations | moore |

New adventures, same company

I recently shifted roles at FusionAuth. Where I was previously head of developer relation (devrel), I’ve relinquished this role to Tony Blank, who is now leading that team. I can’t wait to see what Tony and the team do to help developers build on and learn about FusionAuth.

But why did I switch roles? I’d been leading the devrel function for almost four years and built the team to:

  • two full time employees
  • one part time contractor
  • three agencies

Last year, I took a long hard look at what I was doing and what I wanted to do.

I noticed I didn’t want to be on a manager’s schedule and didn’t want to spend a large chunk of my workday in meetings. I enjoyed the impact of the devrel team and am very proud of everyone who was a part of it.

Yet I also noticed a pattern in my career. I have often:

  • been hired in an IC role
  • had an opportunity to take a management role, because the business needed it and I could do an okay job
  • took the opportunity
  • didn’t enjoy it but also didn’t see a way out
  • started looking for a new job
  • quit the company

I can think of three times this has happened in the last decade.

When I started to build out the devrel team at FusionAuth, especially when I was hiring the full-time employees in the last year or so, I communicated clearly to my managers that I’d build the initial team because I saw a business need. Devrel and market awareness go hand in hand and I think the latter is what FusionAuth needs right now.

But I was also clear that I wanted to hand team management to someone who cares about that as a discipline. I’ve learned enough about myself to know that I like some parts of people management, but that I don’t compare well with others working toward mastery of that craft.

I’m happy to report that my managers at FusionAuth heard me. They were willing to allow me to hire someone who has built out a great devrel team in the past and who really loves to do so; that would be Tony. (Raising our round helped with this too.)

So, where does that leave me? My new title is principal product engineer. What I’ll be doing is high impact individual contributor (IC) work. Combining my knowledge of CIAM, my understanding of the company based on my tenure, and my software skills, I’ll be working on processes, code, and integrations to help solve FusionAuth’s business problems.

At a company growing as fast as we are, there are always bumps to smooth out. Because of my history and skillset, I’m a good person to help. The first thing I’m doing is building out a training program to help employees sell more effectively; it’s been fun to evaluate and select a learning management system, create the curriculum, and build out the training modules.

I’ll miss some pieces of devrel, but I expect to continue to do some devrel-esque tasks. For example, there are several long-form guides and example applications that I can’t wait to write. In fact, building out the training has unearthed holes in our documentation that I can’t wait to fill.

When I look back, I often spun out of a company because I didn’t see a way out of a management role. This is because managers are among the most highly paid employees. Once I was promoted, I didn’t think that my superiors, who were in some cases the owners of the company, would see a place for me. I wasn’t sure there was a high impact IC role at these companies.

But I made a mistake. I didn’t talk to them about alternatives. Part of this was due to my immaturity but a larger part was due to my fear and distrust. After all, if I mentioned I wasn’t happy managing a team, but that was what the business needed, I feared I wouldn’t be needed. But jumping to this conclusion without discussing options removed any agency from my managers. It is possible that I could have moved laterally within the company or found another path forward.

I’m ashamed that I didn’t trust them enough to explain how I was feeling and discuss the job shift I wanted to make.

That’s why I’m proud I had this tough conversation at FusionAuth. I was able to because:

  • I had seen the pattern enough times to know that I could do management for a while but would eventually become unhappy enough to leave
  • I knew I didn’t want to leave because of the team, the problem and the overall opportunity
  • I was in a unique position, having been there for most of the growth yet not having a C level role
  • I’d seen other folks in difficult situation be treated fairly

This conversation could have resulted in a departure for me if there was no budget or need for a high level IC role. The fact that it didn’t have that result gives me hope that there is a path, and a budget, for non-managerial technical leadership, even at smaller companies. In fact, I’m hoping this inspires other folks at FusionAuth, who may want to increase their impact without managing people, to stick around.

I also look forward to solving tons of problems as we keep growing.

Here’s to new adventures!

Devrel FusionAuth | moore |

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.

Blog Social Media Tips | moore |