Skip to content

Tips

Say Goodbye

In this time of increasing layoffs, there’s one thing you should do as a survivor. Okay, there’s many things you should do, but one thing in particular.

Say goodbye.

When you hear someone you know is let go, send them a message. If you have their email address, send them an email from your personal account. If you don’t, connect on LinkedIn or another social network.

The day or two after they are gone, send them a message like this:

“Hi <firstname>, sorry to hear you and <company> parted ways. I appreciated your efforts and wish you the best!”

Of course, tune that to how you interacted with them. If you only saw them briefly but they were always positive, something like this:

“Hi <firstname>, sorry to hear you and <company> parted ways. I appreciated your positive attitude. I wish you the best!”

Or, if you only knew them through one project, something like this:

“Hi <firstname>, sorry to hear you and <company> parted ways. It was great to work on <project> with you. I wish you the best!”

You should do this for a number of reasons.

It is a kind gesture to someone you know who is going through a really hard time. (I wrote more about that.) Being laid off is typically extremely difficult. When it happens, you are cut off from a major source of identity, companionship, and financial stability all at once. Extending a kindness to someone you know who is in that spot is just a good thing to do. It reaffirms both your and their humanity.

It also doesn’t take much time; it has a high impact to effort ratio.

There may be benefits down the road, such as them remembering you kindly and helping you out in the future. The industry is small–I’m now working with multiple people who I’ve worked with at different companies in the past.

But the main reason to do this is to be a good human being.

Now, the list of don’ts:

  • Don’t offer to help if you can’t or won’t. I only offer to help if I know the person well and feel like the resources and connections I have might help them.
  • Don’t trash your employer, nor respond if they do. If they start that, say “I’m sorry, I can imagine why you’d feel that way, but I can’t continue this conversation.”. Note I’ve never had someone do this.
  • Don’t feel like you have continue the conversation if they respond. You can if you want, but don’t feel obligated.
  • Don’t state you are going to keep in touch, unless you plan to.
  • Don’t say things that might cause you trouble like “wish we could have kept you” or “you were such a great performer, I don’t know why they laid you off”. You don’t know the full details and you don’t want to expose yourself or your company to any legal issues.
  • Finally, don’t do this if you are the manager who laid them off. There’s too much emotional baggage there. You were their manager and you couldn’t keep them on. They almost certainly don’t want to hear from you.

Be a good human being. When someone gets laid off, say goodbye.

Business Jobs Lifehack Tips | moore |

Why Public Slack Chats are Better than Direct Messages

This is a repost of a blog post I wrote about six years and two jobs ago about Slack communication. You can see the original here; this is reposted with permission.

Do you even Slack, dude?

We use Slack, and use it extensively. As a remote team, it’s a crucial part of our workflow. I’ve noticed that I sometimes use direct messages when I should be asking a question in a public channel. Upon examination, direct messages have the following attributes:

  • Less intrusive. I sometimes worry about an excessive amount of chatter bothering other team members.
  • Protect my ego. When I ask a question it is admitting that I don’t know the answer. As a “director of engineering” it can be humbling to admit ignorance. But of course I don’t know everything! It’s just my ego talking. However, it still stings a bit sometimes to ask publicly–it’s easier to just side chat.

However, the benefits of posting in a public channel are many. A message in a public channel is:

  • Viewable. This means that others can chime in (as opposed to just the person I DMed). And that others can learn in the present as they read my question and the answers.
  • Linkable. This means that if I want to reference the conversation (in a PR, trello card or elsewhere), I can. Of course, I should extract info into documentation (future me will thank past me) but for context around a decision, a link to a slack chat can be very helpful.
  • Searchable. This means that others in the future who are searching for this information can find it. Yes, slack’s search leaves something to be desired, but if the conversation is private, that’s a guarantee that no one else will be able to search and find it.
  • Vulnerable. I want everyone to feel comfortable asking questions. That leads to better outcomes for clients and for team members. How can I expect that behavior of others if I don’t do it myself?

So my rule of thumb going forward is if I can imagine someone else asking this question, I’ll take it to a channel. If I’m answering a question, I’m going to apply the same test.

To address my worry about intrusiveness, I’ve started to use threads (which I kinda hate, but kinda love). I of course will continue to use DMs or DM groups for private information. However, if a group convo might be more useful if it is viewable, linkable or searchable, I’m going to create a channel–those are free, and easy to archive.

 

Startup Technology Tips Useful Tools | moore |

Text Manipulation with LLMs

A few years ago I wrote this post encouraging new developers to learn jq, awk and sed.

I still think it is worthwhile to do so, because these tools are everywhere and make processing text and structured text easy.

However, I think there’s a new text manipulation tool in town that you should experiment with too. That’s an LLM.

Today, I wanted to take the latest posts from the hacker news ‘whoishiring’ user posts and get a ratio. I wanted to find the ratio of ‘who is hiring’ comments to the number of ‘who wants to be hired’. I thought this would be a proxy for the health of the job market, at least the job market of companies who post on HN.

I could have solved this with text manipulation tools, maybe some google sheets manipulation, but instead I pasted the results into ChatGPT and asked it to extract out the comments and show me the ratio.

It took about 30 seconds. Amazing.

I’ve also used it for fiddly jq commands. Instead of peering through the jq manual and trying to figure out how to capture the first value of an array and to later extract a certain key, I just describe what I want and the LLM gives it to me.

Tips for doing text manipulation:

  • use a new window every time
  • iterate on your prompt
  • give examples of current and future state

Why do I think folks should still learn those other tools and not rely just on LLMs? Because the base tools are far more reliable, cheaper, and scriptable. For me, LLMs shine in text manipulation when the problem is small and adhoc, especially when the text is not well structured or completely unstructured. But if I’m writing a script to extract data from log files repeatedly, I think using the LLM to help write the script is a bigger win and better in the long term than to use the LLM to actually do the extraction.

Either way it is a powerful tool, so next time you want to do some text manipulation, try your LLM.

Tips Useful Tools | 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 |

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 |

Docker thoughts

Docker is amazing tech for developer productivity.

You can package up the dependencies for your application into one file (a Dockerfile) or more than one file (a docker-compose file). You might use the former for an application or service and the latter if your application depends on a database, cache, or other external architectural component.

I am definitely late to the Docker party, as I remember Eric Norlin interviewing Solomon Hykes in the early 2010s at Gluecon. In 2018 I used it to stand up some consulting projects, but wondered at the value and the required investment.

I’ve recently been using it extensively at work to set up quickstarts. These tutorials let folks stand up our software quickly for evaluation purposes. Docker is a fantastic fit for this use case.

I’ve been a big fan of detailed documentation and readmes for setting up development environments, but Docker takes all that documentation (including tedious things like ‘install python 3.8.12. 3.8.11 doesn’t work’) and puts it into code that is accessible with single command.

I have a foggy memory of detailed readmes, hours of setup and dependency hell, but Docker removes all of that. Doesn’t mean your Docker images/compose files can’t get stale and won’t need love and attention, but it does mean you can control when you test and upgrade such dependencies, rather than discovering it when a new developer comes on the team and can’t get their environment set up.

Shipping software to production via containers (Docker or otherwise) has operational benefits, but I’m less familiar with those. One of the nice things about developer relations is you’re separated a bit from operations. (It’s one of the downsides as well.) I haven’t recently worked with a production system where containers were used, but I have read nice things about the approach. Here’s an article from Google which covers the technical benefits.

What about the licensing? This business model change rocked the world of happy Docker users, but when you take funding, you have to make money. Actually, if you want to survive as a company, you have to make money, but if you take funding, you have to try to make a LOT of money. That’s the game, make sure you know before you start to play. But that’s a different post.

As far as Docker licensing, as a Docker user, you have two options:

  • pay docker when you reach the threshold
  • use a docker alternative such as finch or podman

As the previous paragraph implies, Docker is a subset of containers. The benefits I mention above apply to container based systems, not just Docker systems, but Docker is the solution I’m most familiar with.

Docker, and containerization in general, feels like as big a leap as Stackoverflow, git or memory managed languages in terms of developer productivity.

Programming Tips | moore |

Protecting a CDN source using basic auth

I have a website that is behind a content delivery network (CDN). I want to protect it from being crawled by any robots. I want all access to go through the CDN for reasons. There may be errant links to the source; I don’t care if they continue to work.

htaccess and basic auth is perfect for this situation.

I added an .htaccess file that looks like this:

AuthType Basic
AuthName "Secure Content"
AuthUserFile /path/to/.htpasswd
require valid-user

I needed to make sure the path and the file are readable by the web server user.

Then, I added a .htpasswd entry that looks like this:

user:passwdvalue

If you don’t have access to htpasswd, the typical program used to generate the password value, this site will generate one for you.

Then, I had to configure my CDN to give it the appropriate header.

Use the Authorization header, and make sure to pass the username and the password. This site will generate the appropriately base64 encoded values.

Voila. Only the CDN has access.

Now, the flaws:

  • Depending on how the CDN accesses the site, it may be possible to snoop out the username and password
  • If you ever want to get the origin site over HTTP, you’ll need the username/password
Tips Useful Tools | moore |

Setting up password gorilla on an ARM Mac

I love password gorilla. It’s a portable locally hosted password manager that is compatible with passwordsafe. It has all the features I need in a password manager:

  • account groups
  • password generation
  • metadata storage (so you can add a note)
  • keyboard shortcuts for copy and pasting the url, username, and password
  • local storage of secrets

It doesn’t have fancy integration with browsers, remote backup or TOTP, but I don’t need these. For browser integration, I use the clipboard. For remote backup, pwsafe files can be copied anywhere. And for TOTP, the whole point of MFA is that each factor is separate.

But recently, I started setting up an Apple M1 machine, and the password gorilla downloads failed to start. I looked at the github issues of the repository and didn’t find a ton of help, though there were some related issues.

After some poking around, here’s what I did that worked for running password gorilla on my Apple M1:

  • installed tcl-tk using brew: brew install tcl-tk
  • cloned the password gorilla repository: git clone https://github.com/zdia/gorilla.git
  • wrote a small shell script and added the directory where it lived to my path.
#!/bin/sh

cd <cloned repository directory>/sources
/opt/homebrew/opt/tcl-tk/bin/tclsh gorilla.tcl

That’s it. After I did this, I can run this script any time and password gorilla starts right up.

Security Tips | moore |

GitHub Actions Are Amazingly Easy

GitHub Workflows are automated jobs that can be triggered by various events against a GitHub repository. They are pretty awesome.

GitHub Actions are a way to encapsulate configuration and functionality in a way that can be easily reused in GitHub Workflows.

I was thinking it’d be fun to create some GitHub Actions (yes, I’m the life of the party), so I sat down a few mornings ago to do this. I was shocked at how easy it was.

I followed a few lines of this tutorial to create a workflow. Then I created an action by following this tutorial. Finally, I edited my workflow to use the new action. That was it.

It was amazingly simple and took me about 30 minutes. I ran into one unrelated issue (to set the executable bit on a shell script in windows, I had to modify the shell script contents in order to ensure the change was sent to the remote repo).

If you take a look, you’ll see these are both toy repositories, to be sure. However, the ability to write jobs which will be executed on a git push, pull request or other events is great and removes toil. Being able to extract common functionality to an action is even better. Finally, the ability to share the action publicly by adding it to the GitHub marketplace is fantastic.

I’ve liked CircleCI for a long time, but if I were them I’d be worried.

One issue I found is that the testing/release cycle is pretty tedious (I’ve mentioned that action debugging to be an issue for a while).

While I was troubleshooting my executable bit error, I had to do the following every time I wanted to test a change:

  • make a change in the action repository
  • create a new tag
  • push it to the remote
  • switch to the workflow repository
  • bump the action version
  • push to the remote
  • wait for the workflow to complete

Not horrific, but pretty tedious. I don’t know if there are other options such as local deployment which would reduce that cycle, but that would be swell.

Other than that, 10 out of 10, would write more actions.

Devops Programming Technology Tips Useful Tools | moore |

Collecting internet points

I’ve been pretty active on HackerNews for the last couple of years and recently made it into the top 100 posters. According to this stats page, in just over 10 years as a member, I’ve posted 3468 comments and had 7824 submissions. That is approximately 1 comment and 2 posts per day, for a decade. (The numbers are as of the time I write this post.)

That’s a lot of hours on a site.

In light of that effort, I’d like to reflect on the good, the bad and the ugly of my years on HN, collecting karma points.

The good:

  • It’s elevated worthwhile posts and sites. I don’t know a single better source of free traffic for technical content. You don’t just get the initial traffic; other sites, online communities and newsletters pick up top ranked HN posts and reshare them, so there’s an echo effect as well that lasts for weeks. It is really fun to find a good article, post it and surprise the author.
  • I’ve learned a lot by reading the comments, especially in fields outside of software engineering. Posts on topics such as economics, physics and careers all receive really insightful comments.
  • I’ve been able to help a few folks get jobs by posting on HN. They have a monthly free jobs board and I know at least two people who have been hired because of one of my posts on the jobs board.
  • While trending on HN doesn’t typically translate directly to sales, it is great for brand awareness. At my current job, quite a few sales processes have been started because an engineer read a post about FusionAuth on HN.
  • For a developer relations position, having an active presence on HN is helpful. You can certainly devrel without being on HN, just like you can devrel without being on Twitter. But in general a public profile is helpful.

The bad:

  • While most folks argue and discuss from a place of goodwill, there are some who are overly pedantic and or just not nice. I can ignore them, but I remember a few flushes of shame where I made a mistake in a comment and was called out on it in an unkind, direct manner.
  • Self-promotion is part and parcel of a community where there’s this much traffic (to be transparent I promote my own stuff, but only 1 out of 10 posts at most). Often, I’ve seen over the top self-promotion. If someone only posts their own content, it simply doesn’t work.

The ugly:

  • HN has its share of trolls. I have personally seen fewer ugly posts recently, but any time I mention HN, folks reflect on the ugly, mean comments they’ve encountered on the site. Here’s an example of some people’s feelings.
  • I’ve had people ask me not to post their content without warning them. This is because of the kind of feedback they get from the site; they want to mentally prepare. That they’d even feel the need to do that is icky.

I think finding a community or three is a key part of growing as a developer.

While HN is not perfect nor it is as welcoming as other communities like the one around the Ruby language, the breadth and volume and diversity of it has been helpful to me.

So, I plan to keep collecting internet points for the coming years.

Community Devrel Tips | moore |