Skip to content

Tips

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.

 

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.

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.

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.

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.

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

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.

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.

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.

Thoughts on managing a devtools forum

I’m one of the team members tasked with managing the FusionAuth community forum, where folks using FusionAuth who don’t have a paid support plan can find help and answers.

Here’s some advice for running such a forum. (I wrote previously about why you should use a forum rather than Slack/Discord/live chat.)
  • First, consider why are you going to run a forum? Lots of great reasons: ease a support burden, help with SEO, foster community, get product feedback. Get clear on what you are trying to build before committing, because it is a commitment.
  • Choose forum software carefully. Migration will be a pain. Common options include nodebb (what we use), discourse, and vanilla forums.
  • Seed the forum. This means gathering up questions as you see them pop up in other venues (support tickets, GitHub issues, customer calls). I did that religiously for a few months. I learned a lot about the product and the forum posts meant that folks were helped even when it was new. I’d recommend posting the question and then responding in-thread with an answer.
  • Forums will bubble up commonly asked questions. This can tell you where your docs should be improved.
  • You must groom the forum. It won’t be set and forget. You have to pay attention to it, answer questions, respond to responses. A forum full of unanswered questions is worse than no forum at all. Trust me, developers will notice (we’ve had customers mention that they appreciated how active our forum was).
  • Because we sell support, we don’t answer questions immediately or have engineering staff answer them. There are also questions that we can’t answer such as architecture recommendations. Immediate responses and answers requiring context and research are reserved for paying customers. This hurts my heart some times, but we are open about it. May not be applicable to in all cases.
  • Don’t be afraid to ban users. We ban anyone who spams, no questions asked. Delete the content and ban the user. We luckily haven’t had any abuse issues beyond spam.
  • Have a code of conduct. I grabbed GitHub’s (you can see ours here, and here’s GitHub’s)  but have something. We didn’t in the early days, but it’s a good thing to have out of the gate.
  • Don’t expect a lot of community to grow out of it. At least, I haven’t had that experience, most people just want their questions answered. May be because I’m extremely part time on it and haven’t fostered it, though. Slack/discord is much more likely to build community in my experience. But know what your users want: Google or Facebook?
  • At a certain point, I had to enable a post queue, where a team member approves every new user. We were getting a lot of spam accounts and then they’d post gambling ads and then direct a ton of traffic (1000s of pageviews) to the ads. I don’t know what the spammer endgame was, but approving each new post has solved the issue. I’d definitely look for that feature.
In general I love forums, and so do devs, but they do take some work.