Forem: Salma Alam-Naylor

How to make your first contribution to an open source project

Salma Alam-Naylor — Tue, 03 Mar 2026 12:25:26 +0000

Getting involved in open source doesn't have to be scary! Understand how to find a great project and make your first contribution in this guide.

I recently (and accidentally) became a maintainer of a new open source project, npmx.dev. The project’s vision is to provide a new way to browse the npm package registry, with some exciting bonus features.

I’ve always been on the fringes of open source; I’ve contributed to a few projects here and there, such as the Astro docs, Google Lighthouse, and some others, and most of my code on GitHub is open source for the wider community. But, contributing to open source projects can be scary: big codebases, unfamiliar tech, lots of new people, and a sea of open issues can make it hard to know where to start.

However, open source isn’t really all about code, it’s about community. Since my involvement in npmx, I’ve experienced first-hand what a welcoming and inclusive approach to open source can do to empower anyone to make a variety of contributions to help make The Web ecosystem a great place to be and work.

And so, with that experience and some great examples of what good looks like in open source, and because npmx just announced their alpha release, I thought I’d put together a guide on how to get involved in open source to help you get started.

Throughout this guide, I’ll be using some specific open source terms. Here's what they mean:

Open source: a software development model that encourages open collaboration, with source code, documentation, and discussion around the development of the project freely available to the public.
Issue: A ticket used to track bugs, features, questions, or tasks.
Pull Request (PR): a request to merge any changes into the main project, and to review and discuss those changes.
Maintainer: a key contributor to the project who leads, manages, and steers the direction of the project. Maintainers are responsible for reviewing and merging pull requests, managing issues, and taking care of the community, usually acting as the final decision-makers. Some maintainers may also be called stewards.
Contributor: anyone who has contributed anything to an open source project, whether it is code, documentation, testing and reviewing pull requests, design, finding issues, community management, or anything else related to the project.

Where this guide provides specific examples on things such as pull requests and issues, the examples will be specific to GitHub, as that's where all the action is happening for npmx.

1. Find a cool project

The first step is to find a project that you are excited about. Maybe it’s a library or tool you already use that you want to help improve, or perhaps its a project that you really want to see succeed, or it could be that some of your friends are working on something fun.

Your interests matter more than the popularity of the project, and your time is valuable. If you care about the problems that the project is solving, you’ll be more motivated to contribute and invest more of your time in the project.

Making ten contributions to a single project is much more valuable for you than making ten contributions to ten different projects.

And don’t worry if you don’t feel like you’re unqualified to contribute: you are.

2. Read the community guidelines

Before making your first contribution, look for the project’s community guidelines or code of conduct. You can usually find this type of document in the root of a project repository, named CODE_OF_CONDUCT.md or similar.

A code of conduct should help you understand what you can expect from the community: how people treat each other, how conflict is handled, and what behaviour is encouraged or discouraged. A great example is the npmx code of conduct, outlining the community’s standards and the responsibilities of the project maintainers.

If your chosen project doesn’t have a code of conduct or community standards, you might consider skipping it. That being said, your first contribution could be to create these community standards from one of the many templates available. If you’re comfortable agreeing to the code of conduct for your chosen project, move on to the next step!

3. Browse closed pull requests

Take a look at some closed pull requests to help you understand more about the project culture and direction, and how maintainers and contributors work together. It will also give you an idea of how the community standards are being upheld. Some questions you can ask yourself:

What kind of work is being contributed?
Are reviews kind and constructive?
How are mistakes or incomplete work handled?
If the project is busy, how are multiple pull requests addressing the same issue handled?
What’s missing from contributions?

If you’re browsing a project on GitHub, you can find the closed PRs by navigating to the pull requests page, and filtering by closed.

4. Check the contributors list

Next, take a look at the contributors list. A healthy and active project often has:

Many contributors (not just one or two people doing everything)
Recent activity
A visible breadth of contributors

While you can’t conclude everything from avatars and usernames, immediate visual diversity can be a strong signal that the project is welcoming to all kinds of people. This, in my opinion, always makes for a more exciting project to get involved with. It's been really wholesome to see how many contributors have been working on npmx so far.

5. Explore open issues

Exploring open issues will help you get an idea of what needs to be worked on. Issues may be bugs, tasks, larger feature requests, or discussions about ideas that are not yet set in stone. Project maintainers will often use helpful issue labels to categorise issues based on skills or areas of the project. When you’re just starting out, it’s a good idea to look for issues with the label good first issue, or you could filter issues by your area of expertise.

For example, when joining a new project, I often use the issue filter to surface good first issues, or issues labelled front or front end, a11y or accessibility, or docs, as those are my areas of expertise. Another good label to look for is help wanted, as this type of issue is usually more of a discussion around planning an approach to solving a problem.

For your first contribution, I recommend choosing a small, low-lift issue. A lot of the time investment when making your first contribution is taking time to understand the code or the documentation, learning the process of contributing, and ultimately, building relationships with other contributors and maintainers as you move through the process. Choosing a smaller issue means less cognitive overheads for you, and more opportunity to make a meaningful impact. For example, my first contribution to npmx was a pull request to fix the alignment of the logo in the header. This pull request fixed a very small issue that was reported by another contributor that allowed me to open my first pull request with minimal effort.

In a very active open source project, there may be multiple open pull requests that address the same issue. This could feel a little daunting at first (and it’s sometimes tricky for maintainers to manage), but it’s usually not a big deal and can be managed effectively. If you’re worried about this and don’t want to attempt something that is already in progress, GitHub helpfully identifies which issues have open PRs on the issues list with an icon, which I’ve highlighted on the image below.

6. Read the contributing guide

When you’ve found an issue you’d like to make a contribution for, it’s time to understand how the process works. Well-maintained open source projects will have a contribution guide in the project, which you can usually find in the root of a project repository, named CONTRIBUTING.md. A contributing guide is usually geared towards contributing to code or documentation, and will include instructions on how to set up the project, maintaining a consistent code style, testing, and how to format your pull requests.

If you get stuck or notice something confusing or outdated whilst you’re trying to set up the project, you may have found your first opportunity for a contribution! In fact, when setting up the npmx project, I wasn’t sure how the code formatting worked because it wasn’t clear in the contributing guide. And so, after discussing with other maintainers, I opened a pull request to clarify how code is formatted.

7. Chat with the community

Many projects have a Discord, Slack, or other space for chatting with the community, which will usually be linked somewhere in the project repository or in the project itself. If you want help or just want to chat about the project and what issues would be good to tackle, it’s a great idea to join one of those spaces. It’s also a good opportunity to check that the community standards are being upheld and that you feel welcomed by the maintainers and contributors when you join.

Also, don’t feel like you need to jump in and get involved straight away. It can be daunting to jump into an active chat stream of people who are actively working on a project. Take your time, and do a little lurking until you feel comfortable enough to take part.

8. Open a pull request

If you’ve found an open issue and you know how to tackle it, you can usually do the work and open a pull request without asking for it to be assigned to you. That being said, in a very active project it is always helpful to leave a comment on an issue stating that you intend to work on it.

Communication in open source is key, especially with many people working asynchronously on a project across multiple time zones, day and night. But on the other hand, a very active project can feel very noisy and overwhelming, and more often than not, maintainers will appreciate your initiative when it comes to direct contributions, rather than the extra admin of assigning people to issues, and the extra time it takes for contributors to wait for permission.

To open a code-based pull request, fork the repository to your own GitHub account using the fork button on the main page of the repository, and clone your fork of the repository to your local machine.

When you've cloned the repository to your local machine, create a new branch off of main to make your changes. When you push those changes to your own GitHub fork, you'll see a banner at the top of your repository page with a "Compare & pull request" button.

Click this button to write a title and description for your PR, making sure to follow the contributing guidelines. Then, click "Create pull request". In an active project, you probably won't need to message the maintainers to notify them that you've submitted a PR, as they'll be watching for pull requests coming in. I know you're probably really excited to make your first contribution, but be patient in waiting for a review and approval!

9. Not every PR needs an issue

If you spot a typo, a small refactor, or an improvement worth making, you can propose it directly with a PR rather than creating an issue. Make sure to include a clear description of the change and why it’s useful, especially if it’s your first contribution. Even if your pull request is not accepted, you’ve practised the contribution workflow, so you’re ready for the next issue.

Even if someone else submits a similar PR before you, your work won’t be wasted. Maintainers may still merge your pull request, borrow ideas from it, or use it to improve the final solution. This happened to me on an early PR for npmx, where I made a small change to the Open Graph images for the package pages, which will eventually be superseded by a full redesign of the Open Graph images across the project.

10. Not every contribution has to be code

In open source, all contributions are valuable, whether or not they make it into the project codebase or documentation. Finding and reporting issues, requesting or suggesting features, reviewing and testing pull requests, opening PRs that don’t get merged, updating documentation, and welcoming people into the community are all valuable ways to get involved. Participating in open source projects gives you a wealth of opportunities to use your existing strengths, or learn new skills to add to your experience.

Get involved

In my experience, open source really is about humans, rather than code. Open source projects have huge potential to bring people together and solve problems for the people that work on The Web, making the ecosystem (and, optimistically, the world) better for everyone to benefit.

If you’re looking for a great open source experience to get involved in, I would highly recommend the npmx project, who welcomed me with open arms from the outset. Find an open issue, give it a try, and join us in the npmx Discord to experience a truly wholesome community approach to building great tools for The Web. Start small, and have fun!

How to delete all squash-merged local git branches with one terminal command

Salma Alam-Naylor — Mon, 08 Sep 2025 08:17:04 +0000

In 2022 I wrote about how I use a bash function to delete all merged git branches with a single terminal command. This works great for branches that have been merged, but not squashed. Given the team I'm working on right now like to squash and merge pull requests on GitHub, and also how I like to keep my dev environment clean, it was time to update the clean up function to take squashed branches into account.

Now, this was a total rabbit hole I went down, so bear with me.

The difference between "merge" and "squash and merge"

The default option when merging pull requests on GitHub is merge. When you merge a pull request on GitHub, all commits from a feature branch are added to the base branch in a merge commit. A merge commit preserves the full history of the changes being merged, allowing you to see an intertwining history of events that happened on both branches after a feature branch is merged into the base branch.

On GitHub, a default merge uses the --no-ff option in git, which means no fast-forward. This option is what creates the merge commit and allows you to inspect the complete history of both the feature and base branches.

When you squash and merge a pull request, all commits on the feature branch are "squashed" into a single commit, using the fast-forward option. A fast-forward commit merges all file changes after the most recent change on the base branch. This loses the distinct feature branch timeline of changes. This can be useful when:

You want to keep your commit history tidy on the base branch
You're merging small changes on short-lived branches
You don't need to preserve the feature branch history

Why the original bash script doesn't work for squashed branches

Here's the original bash script I wrote to delete all merged branches. The first line, git checkout main && git branch --merged, checks out the main branch, and lists all branches that can be detected as being merged into the main branch.

# delete all branches merged into main
dam() {
  echo "=== Deleting all merged branches ==="
  git checkout main && git branch --merged | grep -vE "(^\*|main)" | xargs git branch -d
  echo "☑️ Done!"
}

When you do a squash merge, Git takes all the changes from the feature branch, compresses them into a new commit, and applies it to main as the latest change. The original branch’s commits are not in the history, so Git still sees that branch as “not merged". The git branch --merged command won't match any branches, and so won't find any branches to delete.

The script that finds and deletes squashed branches

To delete all squashed branches that merged using the fast-forward option we need to take a different approach. This script is named dams(), which stands for "delete all merged squashed". To use the script:

add the following code to your .bashrc or .zshrc file (switch out main for what you usually call your main branches if necessary)
save the file
source the new changes (or reload your terminal)
run dams in a git project directory (without the brackets)
enjoy the cleanup!
(This may need to be adjusted according to your shell, please don't come for me.)

dams() {
  echo "=== Deleting merged and squash-merged branches ==="

  # Ensure main is checked out and up to date
  git checkout main &&
  git pull &&

  # Loop over all local branches except main
  for branch in $(git for-each-ref --format='%(refname:short)' --exclude=refs/heads/main refs/heads/); do
    # Skip if branch does not exist on remote
    if ! git ls-remote --exit-code --heads origin "$branch" >/dev/null 2>&1; then
      echo "Skipping $branch (not on remote)"
      continue
    fi

    # Delete only if content is fully in main
    if git diff --quiet "$branch" main; then
      git branch -D "$branch"
      echo "Deleted $branch"
    else
      echo "Keeping $branch (has unmerged changes)"
    fi
  done

  echo "☑️ Done!"
}

Let's break down what the script does, and learn some things about Git!

Check out the main branch and update it

First we want to make sure we checkout main and pull in the latest changes to compare the other branches against.

git checkout main && git pull &&

Loop over local branches and check for changes

Here, the script loops over the branch names returned from the command [git for-each-ref](https://git-scm.com/docs/git-for-each-ref), which iterates over all branches (or refs) that match a pattern and shows them according to the given format. The pattern excludes the main branch (--exclude), and the --format requests the short branch name. refs/heads/ at the end of the line instructs the script to look only at local branches.

for branch in $(git for-each-ref --format='%(refname:short)' --exclude=refs/heads/main refs/heads/); do

Check if a local branch has been pushed to the remote

This following code runs [git ls-remote](https://git-scm.com/docs/git-ls-remote) to check if the branch in the loop has been pushed to the remote to avoid deleting branches that haven't been pushed. The --exit-code flag instructs the command to exit with status "2" when no matching refs are found in the remote repository. In Bash, if considers exit code 0 as true and non-zero as false. Exit code 2 will evaluate to false, so with the ! at the start of the if, we're checking if git ls-remote returns false. If it does, we skip deleting that branch.

The >/dev/null 2>&1 part instructs the script to throw away both stdout and stderr output so that it produces no output at all, to keep the terminal free of noise. The script still produces a success or failure via the exit code, but suppresses all output.

# Skip if branch does not exist on remote
if ! git ls-remote --exit-code --heads origin "$branch" >/dev/null 2>&1; then
  echo "Skipping $branch (not on remote)"
  continue
fi

Check for diffs and delete the local branch

This part of the script checks for diffs between the branch in the loop and the main branch. Again, in Bash, if considers exit code 0 as true and non-zero as false, so whilst this may look backwards compared traditional programming languages, if there is no diff found between the branches, then the branch will be deleted using [git branch -D](https://git-scm.com/docs/git-branch#Documentation/git-branch.txt--D).

I decided to use the -D flag to force the delete in this script, seeing as I'm operating on my local machine and it's safe to force delete local branches in my case, especially if we have checked at the start of the script if the local branch has been pushed to the remote.

# Delete only if content is fully in main
if git diff --quiet "$branch" main; then
  git branch -D "$branch"
  echo "Deleted $branch"
else
  echo "Keeping $branch (has unmerged changes)"
fi

It uses the --quiet flag to suppress all output, as we don't need to view that whilst the script runs. Without the --quiet flag, here's what the command outputs in isolation when there is a diff:

And here's how the output looks when the full script runs and finds some branches to delete that have been squashed and merged on GitHub:

Probably don't use this script

You probably shouldn't trust random bash scripts written by random people found on the internet, especially where your precious version-controlled work is concerned, so you probably shouldn't use this. This is my disclaimer. Use this script with caution!

Why is CSS ::first-letter not working?

Salma Alam-Naylor — Wed, 20 Aug 2025 09:31:56 +0000

I recently had a use for the CSS ::first-letter pseudo element. I was dealing with some inconsistently formatted strings from the back end, and wanted to make sure that on the front end, all strings were shown with lowercase letters except for the first, which needed to be uppercase. I thought it would be trivial to use the following CSS:

.parentElement {
  text-transform: lowercase;
}

.parentElement::first-letter {
  text-transform: uppercase;
}

In my case, however, the first letter was not being uppercased, and I was confused about why. Here is a modified version of the HTML I was attempting to style:

<div class="parentElement">
  <div class="child1">
    <svg width="16" height="16" xmlns="http://www.w3.org/2000/svg">
      <path>...</path>
    </svg>
  </div>
  <span class="child2">
    inconsistently FormattED string
  </span>
</div>

Naïvely, I thought I would be able to apply the styles on the div with the class parentElement, and the styles would cascade down to the span with the class child2. However, it turns out that the ::first-letter pseudo element selector can only target text under a certain set of conditions.

The ::first-letter spec

The ::first-letter CSS pseudo-element applies styles to the first letter of the first line of a block container, but only when not preceded by other content (such as images or inline tables).

When drilling down into what exactly defines a “block container”, there is definitely some ambiguity across the CSS spec: “In specifications, block boxes, block-level boxes, and block containers are all referred to as block boxes in certain places. These things are somewhat different and the term block box should only be used if there is no ambiguity.” I won’t go deep into the specifics of block boxes and block containers in this post, but I will attempt to provide a summary:

An element is a block container only if it contains block-level or inline-level boxes. The following values for the CSS display property produce block containers:

block
inline-block
list-item
table-cell
table-caption
flow-root
inline (on one condition: inline elements become block containers when they contain inline text! The spec is difficult to read but I think I got the gist.)

The following values for the CSS display property produce block-level boxes, but not block containers, given how their child elements are formatted:

flex
grid

The key issue in my case was that I was attempting to target a non-block container; the parentElement class specified a display property of flex and attempting to cascade the styles for ::first-letter down to a child element.

The rules of ::first-letter

To summarise, using CSS ::first-letter will not work in the following conditions:

The element you are targeting is set to display: flex or display: grid
The element you are targeting is preceded by other content, such as a ::before pseudo element, images or inline tables
You are attempting to cascade ::first-letter styles from a parent element, even if the elements are block containers

To make sure CSS ::first-letter works for you:

Apply the ::first-letter styles directly to a block container (and those block containers are specified above)
Ensure the content you are attempting to target is not preceded by other content, such as a ::before pseudo element, images or inline tables

A note on browser support

CSS ::first-letter may have limited browser support: caniuse.com reports this pseudo element selector is not supported in Firefox, but Baseline reports that "This feature is well established and works across many devices and browser versions. It’s been available across browsers since ⁨July 2015⁩."

Using ::first-letter in action

To better understand how ::first-letter works, I threw together some examples of when this pseudo element can be correctly targeted, and when it fails to work. You can view the examples at CSS first-letter demo, and you can view the code here.

Why Women in Tech isn't enough

Salma Alam-Naylor — Thu, 17 Jul 2025 06:47:18 +0000

Disclaimer

This article is based entirely on my personal experience as a woman in the technology industry. I have no doubt that there are organisations and initiatives that are putting in incredible work to improve experiences and opportunities for "non-men" in the industry, and genuinely helping to improve equity in hiring pipelines in tech. If you’ve found safety and opportunity in such spaces as described below, I am truly happy for you.

This article does not intend to belittle the efforts of such initiatives, but highlight that they may not be working for everyone as intended. I am most certainly not advocating for funding cuts or erasure around DEI initiatives, but only that we rethink what is not working.

The technology industry (and beyond) is performative, often offering shallow solutions to deeper problems, shifting the responsibility of change onto those that bear the brunt of the dire consequences the world has created for itself. Want to prevent climate change? Use paper straws instead of holding corporations accountable for their increasing carbon emissions. Want to protect your mental health online? Limit your screen time using app-blocking tools instead of questioning why social media platforms have been deliberately engineered to be addictive. Want to create equal opportunities in the technology industry? Segregate all the women, non-binary, intersex, LGBTQIA+ identifying and trans folk under the banner “Women in Tech” and hope they figure it all out.

At most of the tech companies I have worked, there have been dedicated spaces for “non-men” to get together, including Slack channels, informal meet-ups, and formal discussion panels. “Non-men” in this context has been used to discount “non-heterosexual-cis-men”, and to include women, non-binary, intersex, trans women, trans men and those identifying as LGBTQIA+ all at once. The people spanning the very wide spectrum of this group have probably, and unfortunately, all experienced some kind of discrimination in the workplace, and so it seems sensible for a company to put us all together to share our experiences in a safe and enclosed space, right? It helps, but I'm not so sure it offers a full solution.

The problem with “non-men” spaces

Reports on gender statistics in the technology industry have consistently published figures of around 17-25% of women and non-binary people working in this industry since the early 2000s (this varies by geographical location), and not much has changed over the last 25 years. A recent statistics dump by Spacelift reports that “half of all women who work in tech have left the industry by age 35”, and “none of the biggest US tech companies report women occupying more than a quarter of all technical roles”. Furthermore, “the proportion of undergraduate computer science degrees awarded to women has fallen from 37% in 1985 to about 20% today.”

Why are the statistics not showing much improvement despite countless initiatives surrounding diversity being created, and in particular events, awards, and “safe” spaces for “Women in Tech”? I have a hypothesis: all of these initiatives are operating in closed and exclusive spaces, which is sending a strong signal to the male majority with the power to affect real change that they are not welcome here, and it is not their problem to solve.

A few years ago I was nominated for a “Women in Tech” award by an anonymous party. Not only did I have to confirm my nomination by writing a number of time-consuming essays about my achievements and eligibility for the award, I also couldn’t shake the weird feeling that I was nominated only on the basis that I am a woman. I understand the need to celebrate and lift up “non-men” in tech, and to provide a platform for representation to young and less experienced people entering the industry, but I wasn’t comfortable with demonstrating that if you want to succeed in the tech industry you need special awards and events under the banner of your gender. I did not accept the nomination; I want to win awards that the men are eligible for, too. Because I can, and I have.

These enclosed “non-men” spaces are also not without their specific problems. At one company I worked for, I was asked to participate in a “Senior Women in Tech Panel”, where I was invited to share my experiences and career progression in tech to an audience of women, non-binary, and trans men and women. This event was not moderated well, and descended into a chaotic discussion about how many children each of the panel members had, and negative remarks about the ethnicity and representation of the panel speakers. This may have been a one-off, but at that point I decided to leave the closed Slack channel for “non-men”, and chose not to participate in events of this type for the rest of my career.

What's more, the hard work of ensuring that workplaces are equitable often falls upon the shoulders of underrepresented groups, who are already carrying the burden of discrimination, being overlooked for promotions, and other related issues. A friend reports:

They've started a women's network at work and I am not a member because I think these initiatives are basically just making female members of staff do extra work to fix organisational problems.

The problem with women-coded labels

Imagine if men described themselves as a “male founder” or “HeTO” (a male CTO), or slapped the #MenInTech label on their social media posts when sharing their achievements? The industry’s obsession with women-coded job titles such as “female founder” (which has descended painfully into “girl boss”) that were conjured up to challenge the male default and demonstrate representation in the industry, does not sit comfortably with me.

Feminising job titles, in my opinion, belittles success and achievement in the context of a patriarchal default. Just as “Women in Tech” awards and closed spaces for “non-men” segregate underrepresented groups of people from the spaces where people with power make decisions, women-coded labels inherently classify people on a separate, non-default scale of success and achievement.

It may work for early career folks, but what's next?

After speaking with many women during writing this article, it looks like "Women in Tech" initiatives work well in the context of those entering the industry, but may not be enough to support getting enough underrepresented groups into leadership positions.

A friend of mine shared this with me about her experiences:

I joined tech through Rails Girls. It was a really nice space, it made me feel very safe. It also played into this thing that I knew was happening a lot, which is women thinking that they are not capable of doing something because the world is telling them that they cannot. I really loved getting into tech through these female-focused initiatives. It made me feel like there was a group of people who cared about me joining tech, which is such an important thing if you are looking at an industry that is overloaded with a specific default type of guy.

Another friend had a similar experience, but once she had established her career, things changed:

My perspective also changed with age and expertise gathered. I found a lot of “Women in Tech” programs and initiatives incredibly useful as a newbie. I wouldn’t be where I am without codebar and some early speaking opportunities. But as I gained my voice and my knowledge I found it increasingly patronising.

Another Women in Tech statistics report from AIRPM reports that in 2025, "around 14% of global tech leaders were female in 2023 – up from 8% in 2015", which is promising. Yet, the Spacelift report also finds that “The so-called Big Five tech companies (Alphabet/Google, Apple, Meta/Facebook, Amazon, Microsoft) have never had a female CEO.” And to couple that with another finding from the Spacelift report mentioned above, that “half of all women who work in tech have left the industry by age 35”, it seems that once we get to a certain level of seniority, age, or experience, something isn't working.

Rachel-Lee Nabors wrote about this in 2018 in an article titled A Counterintuitive Way to Increase Diversity in Tech:

I’m mid-career in the web development and design industry. And right now, I’m hearing a lot of the same stories from my fellow mid-career friends from underrepresented groups (women, minorities, LGBTQ, and more): you reach a certain point in your career and you can’t win.

Responses to how you may be feeling right now

I have benefitted from "Women in Tech" initiatives or other "non-men" initiatives in tech. Are you saying these programmes shouldn't exist?

I'm a man and I think DEI is terrible. I'm glad to see a woman agreeing with me at last!

As stated in the disclaimer, this is absolutely not the point of this article. Diversity, equity and inclusion initiatives are absolutely needed in this industry. However, the current landscape has seemingly affected little change in statistics on the whole, especially at leadership levels. I don't think we can continue to segregate ourselves if we want to make progress. Personally, I have worked with some excellent men. And men who have worked with me have said I am also excellent; we have all benefitted from working with each other. To that end, we absolutely need these initiatives: but the men must be invested as well. They must not be excluded from the conversation about how they can help affect change, especially in the context of leadership, given it's mostly the men who hold those positions today.

I am a man and consider myself an ally. Do I need to do something?

I remember speaking on a panel of all women, which was organised by a man. I requested that he not promote the event as an "all-women" event to avoid focussing on gender. He did it anyway. Celebrate underrepresented groups in tech, but do not focus on their gender identity. Celebrate their achievements, use your privilege to lift them up, share their work, make their voice heard: not because they are not men, but because their work is worth celebrating. If you are a man in a leadership position, you can absolutely do more to bring more underrepresented groups into leadership with you. To take another quote from Rachel-Lee's article:

You should be a mouthpiece when someone isn’t heard, an advocate when people are unable to be represented, a shield bearer when folks are under attack, an elevator for the stuck, a signal booster for the unnoticed. Wherever possible, let them do the work, and be heard and understood, and represent themselves. You’re the back up, the path carver, the taker of the brunt of the negative impact, always asking, “How can I help?” Always pushing others up, even over yourself.

We’re focussing on the wrong thing

I think that purely gender-based initiatives are shallow solutions to the deeper problems of male-dominated industries and society as a whole, that focus solely on surface-level optics of inclusion rather than addressing the root cause of inequality and imbalance on a larger scale. So, how do we address the root cause of inequality and imbalance?

We invite those with power to have a seat at the women’s table (and the underrepresented table as a whole): men _must _be part of the conversation to help affect change, especially at higher seniority levels.

Women, non-binary, intersex and trans folk are in tech, have always been in tech, and will (hopefully) always be in tech. There is a problem, in that these underrepresented groups are often discriminated against and overlooked. The solution? Men in tech can lead the change in how men represent themselves and their gender as a whole in the industry. A bandaid? Groups where "non-men" can feel safe. Both are important, but only one will affect real change.

The promise that wasn’t kept

Salma Alam-Naylor — Thu, 29 May 2025 14:08:13 +0000

I recently wrote about AI and productivity, and how data from the 2024 Accelerate State of DevOps Report shows that widespread AI adoption in the software industry is contributing to a real and meaningful decline in software delivery performance. Approximately 76% of developers use AI tools in daily tasks such as coding, debugging, and documentation.

This week I posted a silly and whimsical post on Bluesky, which seemed to resonate with a lot of you out there, and it reminded me of a section in the DORA report about valuable work.

AI has always promised to “help people spend more time doing valuable work” by “automating the manual, repetitive, toilsome tasks” so that software developers can be “free to use their time on ‘something better.’” Despite this, the report states that “individuals are reporting a decrease in the amount of time they spend doing valuable work as AI adoption increases”. The maths isn’t mathsing.

What is valuable work, actually?

I have observed a growing trend of developers focussing solely on the tools used to make software, rather than what the software actually does. Many people are sharing their new apps on social media, attempting to provide context for their creations by listing the databases, runtimes, frameworks, UI libraries and AI code generation tools they used. But what does your app actually do? What problems does it solve? Tell me about the value you just created!

Valuable work and meaning is not derived from what AI makes us (apparently) faster at: generating code. Meaning and value in software development is actually created through the impact of building things that makes human lives better, or easier, or slightly less bad. Now, it can be argued that much of the work in the technology industry in 2025 is not centred on making things better for humans whatsoever, but that’s a discussion for another day.

What’s becoming clear is that the mass adoption of AI is shifting the focus away from human-centred software solutions that provide meaningful value, and is reducing the entire industry to just the tools at its disposal. Just generate the code, bro. Just ship one more app, bro.

The new kitchen metaphor

If I employ someone to build a new kitchen for me, I really don’t care what drills, hammers, nails, or sandpaper they use to get the job done. I just want a valuable end result: a fancy-looking and functional kitchen that makes good use of the available space, enabling me to cook delicious food in a delightful and comfortable environment. Ultimately, a great kitchen is created with vision, creativity, and by solving existing problems the old kitchen presented. The same is true for software.

Value in software development cannot be determined by how many lines of code you can bash out in any working day, and especially whether or not you are using AI to do so. Real value is delivered through vision, creativity, experimentation, and using human brains to solve human-centred problems. The report backs this up:

[T]here is also an art and empathy underlying a great product. This might be difficult to believe for people who think everything is a problem to be resolved through computation, but certain elements of product development, such as creativity or user experience design, may still (or forever) heavily rely on human intuition and expertise.

And what’s even more interesting, is that while seemingly “high-performing teams and organizations use AI”, the report finds that “products don’t seem to benefit”. We’re all just churning out AI generated code, moving those tickets, making meaningless graphs go up, but to what end? Real software is actually not moving forward. We're all just cranking out the same broken software with the same stupid bugs. In fact, as I was editing this post whilst sitting with a fresh batch of black hair dye on my head at the hairdressers, one wrong tap of a button on my phone deleted half of the article. I attempted to use the three-finger gesture to bring up the undo button on my iPhone, which, not surprisingly, did not restore what was deleted. I ended up having to find a deploy preview of this post (that I fortunately deployed before I left the house), copy and paste half of the article back into the CMS, and reformat the headings, being very careful to not make a single wrong move.

All the new kitchens and silly add-ons are shit. There’s no value in that.

Tools do not determine value created

The tools someone uses to build a kitchen are only as good as the skills of the person using them. A skilled craftsperson can probably use any old tool and produce a great result that holds up for years to come. A less experienced craftsperson who doesn’t understand the fundamental concepts of space, structure and value-based utility might be able to make a single kitchen cabinet look good to the untrained eye, only for the shelves to be at the wrong height so I can't store my stuff. The same can be said for software.

There’s nothing wrong with being inexperienced; we all have to start from somewhere. But we can’t rely on tools as a shortcut to gain valuable experience. Experience takes time to develop, and your tools are only as good as your fundamental knowledge and skills. If you skip the knowledge and skills part, and if you fail to learn about what you’re doing and the implications of how you’re doing it and the human value you have the potential to deliver, then you have little hope of building human value into your software. Because for the most part, humans use software. Andreas Møller said it better in They lied to you. Building software is really hard:

The true value of a software engineer is in our ability to analyze problems as well as design and implement creative solutions. To get good at these skills you need to understand not just the tools at your disposal but also the technologies you are building on top of. If you don’t understand how an application works then you have no chance of fixing its bugs and issues.

In the report, “respondents also reported expectations that AI will have net-negative impacts on their careers, the environment, and society, as a whole”. Whilst AI has empowered anyone to build and ship web and mobile apps, the tangible negative impact of the soulless, valueless software released on a daily basis across the industry cannot be underestimated.

And no, I do not want to use your new AI tool to summarise an email (?) or summarise a document (?) or summarise a meeting (?) or anything else. I want to use my brain so I can comprehend and learn and connect with what is in front of me.

Productivity ≠ value

Returning to the topic of the previous article, I want to touch again on the topic of productivity. Productivity as a measure of value is extremely misleading. The very notion of productivity has been conjured up by Big Capitalism™️ to keep us busy, and to misdirect our attention so that we forget to question the broken system in which we have no choice but to participate. All of this prevents us from real growth, and moves us further and further away from the pursuit of real value.

You could argue there is space for both approaches in software development. Build the hard, compelling stuff using your human brain, and use AI to generate the code for some of the more boring parts of your apps. Take form validation, for example, scaffolding out a new project, or setting up all the boilerplate to make some API calls. But those boring parts are only boring because you wrote the code to do the same thing before! You already learned how to do it without AI.

But unfortunately, too many of us are getting sucked into the productivity hype cycle and engaging in daily conversations with energy-sapping computer machines that vomit out thousands of lines of code based on probability and existing mistakes that the Large Language Models themselves are trained on. It's absurd. We have a whole new cohort of inexperienced kitchen builders who have invested in the latest must-have drills, hammers, nails and sandpaper, but have no idea how to build real value into what they are using those tools to create. And so we're seeing an influx of infinite inferior kitchens that offer no human value. They may look good when you walk into the room, but will inevitably fall to pieces as soon as you put the kettle on to make a cup of tea.

The data speaks for itself. Vibe coders are reporting outages and critical security vulnerabilities in their apps, losing months of work that didn’t use version control, and the inability to truly learn new things.

The world is already cooked, and yet, we’re cooking it more

What’s more, there’s the environmental impacts of AI, which are only just beginning to emerge. An MIT article titled Explained: Generative AI’s environmental impact outlines how the rapid expansion of generative AI presents significant sustainability challenges, including electricity and water overuse, hardware-related emissions, and increasing pressure on power grids.

The world is already cooked. And yet, we’re cooking it more — literally, and figuratively — by shipping insecure software into the void that we have no idea how to debug, scale, or extend. In the not-so-distant future, LLMs will be trained purely on LLM-generated software, and the world will eat itself.

I challenge you to find the value in that.

It wasn’t the idea that failed: it was the execution

Salma Alam-Naylor — Fri, 09 May 2025 13:37:58 +0000

Since writing my new talk, An Introduction to the World Wide Web for Very Senior Programmers, in which I transport the audience back to the year 1995, I’ve become somewhat of a proud and nerdy Internet historian. So much happened on the web in 1995. HTML 2.0 was released in September and saw the introduction of the HTML tag, transitioning the online experience from something that resembled reading books and formal documents, to flicking through colorful magazines or photo albums. JavaScript was released in December 1995, which moved the web from a read-only medium to an interactive experience. Multimedia tools like Macromedia Shockwave Player and FutureWave FutureSplash Animator were created in 1995 out of a desire to bring exciting and interactive CD-ROM-like experiences to the browser.

While the end-user experience was evolving, new tools to support web developers who were building websites were also being invented. The World Wide Web Consortium (W3C) was formed in 1995. And, whilst the first version of CSS was not released until 1996, the 1994 proposal for Cascading HTML Style Sheets was being developed by the W3C. This would give web developers full control over the design of their websites, instead of allowing end-users to enhance the visuals of their internet-surfing experience using proprietary browser configurations. And, whilst the web was becoming more visual, so were the tools used to build websites.

It all started with Visual Basic

In 1991, Visual Basic was launched for Windows software application development. Visual Basic was a graphical user interface (GUI) that provided a visual abstraction layer on top of C/C++ and the Win32 API. Ryan Lucas describes this historical release in detail in The history and legacy of Visual Basic, and pays particular attention to how it saved the careers of “millions of mainframe COBOL programmers who were looking with terror at the microcomputer invasion,” as recalled by the creator of Visual Basic, Alan Cooper.

To design their UI, developers could drag and drop out components onto a WYSIWYG canvas. To add behavior to a UI element, they could simply select it and choose a click event handler from a dropdown. Mainframe programmers were suddenly empowered to quickly get up to speed writing Windows apps.

Whilst application developers were embracing a more visual way of working in the early 90s, developers on the web were still confined to the command line, Notepad, and MS-DOS Editor on Windows. That is, until FrontPage 1.0 was released in November 1995.

FrontPage was developed by Vermeer Technologies, and was categorised as a “World Wide Web publishing and site management tool”. Like Visual Basic, FrontPage was a WYSIWYG (what you see is what you get) visual interface, and this tool built HTML. It also provided a personal web server, which allowed you to preview your website on your local machine as you built it. It also included templates, automated scripts, and more. FrontPage was acquired by Microsoft just two months later in January 1996, and was rebranded to Microsoft FrontPage in June 1996 to coincide with the release of version 1.1.

Around the same time, a company called iBand worked on a similar visual tool to FrontPage called Backstage Designer. And, as is seemingly standard practice in this industry, iBand was acquired by Macromedia in 1996, and soon rebranded the Backstage Designer product as Macromedia Backstage Desktop Studio, which in 1998 became a web development GUI you may be more familiar with: DreamWeaver.

Development tools for building games were also evolving in the same way at the same time. Unreal Engine 1, a GUI built in Visual Basic, was also released in 1995.

And what’s very interesting to note at this point, is that while game development has largely adopted visual development tools across the industry, web development seemingly abandoned the visual tools of the mid-late 90s. Thirty years later, most of us are still building websites and web applications using text editors. Why is that?

Why didn’t we adopt visual website tools in the 90s?

The bottom line is that visual website tools in the 90s (and beyond) produced terrible HTML markup, and therefore, pretty terrible websites. I remember fondly using the Apple website builder iWeb in the early 2000s. In fact, it wasn’t very long ago that a website I built for a client in 2008 using iWeb was still up and running. The text-based CMS I built for them, which displayed a text file in an iframe that they uploaded via FTP, really stood the test of time. But now I have professional knowledge and experience of building things for the web, I know that the HTML markup that iWeb produced was absolute filthy garbage. And if the HTML markup is garbage, then your site is not accessible to those who use assistive technology, such as screen readers.

In 1986, IBM announced the first screen reader, but it wasn’t until the mid 90s that screen readers started to become a little more accessible themselves, when JAWS was released for Windows 1.0 in 1995. The first web accessibility guidelines, later branded as the Web Content Accessibility Guidelines or WCAG, were published in January 1995. Yet, despite this, tools that were created to build websites were not ever seemingly built with these official standards in mind. This goes for tools built in 1995, and astonishingly, 2025.

This week on May 7th 2025, Figma announced Figma Sites, a tool to publish your designs built in Figma directly to the web. But this new product has not been well received. Adrian Roselli warns us: Do not publish your designs on the web with Figma Sites.

“…Unless you want to fail all the WCAGs, create litigation risk, close off opportunities in Europe, engage in reputational harm, and oh yeah, throw up barriers to your customers and users.”

It’s no surprise we weren’t getting it right in 1995, if we still can’t get it right 30 years later with all of this knowledge, experience, and empathy under our belts. And I’m not even going to mention at this point how AI can’t get this right, either. Of course it can’t; it doesn’t possess the capacity for empathy.

Developers want control

Developers want complete control over their HTML, CSS and JavaScript: and rightly so. If visual web development tools can’t generate clean and semantic HTML, organized and debuggable CSS, or performant JavaScript, it really is a no-brainer to continue to build websites and web applications using text-based web frameworks, or rolling your own.

It is no secret that I am writing all of these things on the Nordcraft blog, and that Nordcraft is an open-source Web Development Engine which combines a web framework with a suite of advanced visual tools that let designers and developers collaborate to build high performance web applications, and that I work at Nordcraft. And you might think that Nordcraft is just another visual website builder that produces the same old garbage that all the other visual tools do. But speaking as someone who has been building websites and writing code for over 20 years, and as someone who likes complete control over said websites and code, I can say for a fact that Nordcraft is very, very, different.

Nordcraft actually gives you control

In Nordcraft, your HTML markup is yours to control. Using the Nordcraft editor, you build your HTML structure in the same way you build HTML with text, using semantic element tags of your choosing, with full access to adding attributes and other web platform-based functionality. Nordcraft does not prescribe how to build your HTML markup: you do. The only difference (and advantage) is that you are building your HTML on a WYSIWYG canvas, where designers can collaborate with you and add design flair as part of the process, not as some preliminary task that sees designs in Figma thrown over the fence in a developer’s general direction (which is, all too often, the case). CSS and JavaScript work in the same way: you have complete control over what you ship to the browser, without any unexpected nonsense.

It’s 2025, and we can do better than what has come before us, and what is, unfortunately, currently unfolding in this visual web development landscape. By giving you, as developers and designers, full control over the end result you envision, I am confident that Nordcraft won’t suffer the same fate of the early visual tools of the 90s, or Figma Sites in 2025.

Your fate is in your own hands, as well as the fate of your websites.

Does AI really make you more productive?

Salma Alam-Naylor — Fri, 28 Mar 2025 09:04:33 +0000

In October 2024, the DORA research programme published the 2024 Accelerate State of DevOps Report, which for the first time, included a section on how AI adoption is affecting software development at an individual, team and product level. With the recent emergence of the new “vibe coding” meta, a term introduced by Andrej Karpathy in February 2025, where AI is is enabling people to ship apps from idea to production in record time, I wanted to take the time to reflect on the report and discuss whether AI is really making us more productive as software developers.

Most developers are relying on AI

The report found that almost 76% of participants are “relying on” some form of AI tooling in their daily responsibilities as a software developer. This can include writing, optimising, documenting and debugging code, explaining unfamiliar code, writing tests, data analysis, and summarising information. “[D]evelopers who trust gen AI use it more”, but almost 40% of participants “reported having little or no trust in AI”.

I do not trust AI. I have over 11 years of professional industry experience, and have been making websites in some form or another for almost 30 years. With all this considered, AI code generation has only ever made me feel less productive. I prefer to understand every single line of code I ship in my applications: it makes everything easier to debug, fix, and extend. I have found that AI-generated code is often sloppy, unnecessarily complex, and a lot of the time, just plain wrong. For me, AI code generation is akin to mindlessly copy-pasting code snippets from Stack Overflow, and we all know how that goes. It usually takes me longer to understand AI generated code than write my own.

You may be sacrificing software delivery metrics by relying on AI

DORA’s software delivery metrics provide an effective way of measuring outcomes of software delivery processes. They are split into two categories: throughput and stability. The report found that “AI adoption is negatively impacting software delivery performance”, and the “negative impact on delivery stability is larger”.

Sacrificing throughput with AI

Throughput measures the velocity of changes in software that are being made, that is, how quickly and how frequently software teams can ship changes to production. Throughput is all about how efficient and responsive a team can be.

The report hypothesises that “the fundamental paradigm shift that AI has produced in terms of respondent productivity and code generation speed may have caused the field to forget one of DORA’s most basic principles — the importance of small batch sizes.” Since AI code generation will often spit out huge batches of code in one fell swoop, pull requests are getting larger. Larger pull requests and changes are much more difficult and time-consuming to review thoroughly for edge-cases and potential issues.

Speaking from experience, code reviewers are more likely to skim over large changes and miss important details; walls of impenetrable code are much more difficult to process and interpret by a real human brain than smaller changes, amidst an already busy work-day. Whilst combing through that +11456 -7892 code review, you’re probably thinking about all those lines of code you need to write yourself in order to stay “productive”.

Of course, there are tools that provide AI-assisted code reviews. But if we, as developers, do not trust AI to produce maintainable and reviewable code, why should we trust AI to review it? If you find yourself constantly reviewing large pull requests with a lot of AI generated code, you’re probably sacrificing throughput. You might not be shipping as fast.

Sacrificing stability with AI

Stability measures the quality of software changes delivered, and the team’s ability to fix bugs. Stability is measured using a combination of change fail percentage, which is the percentage of deployments to production that require hot-fixes or rollbacks, and failed deployment recovery time. A lower change fail percentage means the team has a reliable delivery process, and a lower recovery time indicates more resilient and responsive systems.

The report suggests that it’s “possible that we’re gaining speed through an over-reliance on AI for assisting in the process or trusting code generated by AI a bit too much.” I would argue that speed here is the illusion of speed, and the concept of “over-reliance” is key here, especially in the context of the new vibe coding meta. Vibe coding is about being dependent on AI code generation. Describe the app or code you want, and let an LLM take care of it for you. Ask it for a few edits. Ship it.

The report states that a developer’s productivity “is likely to increase by approximately 2.1% when an individual’s AI adoption is increased by 25%”. Vibe coding and any sort of AI adoption is attractive because it feels fast; it feels more productive. Now, I’m not proposing that professional software developers are going all-in on vibe coding, but increased adoption of AI and reported productivity increases poses a risk to software stability. We think we’re going faster, but we may be shipping poorer quality software and more broken changes, because we’re putting our trust in AI generated code too much.

Data from the industry is proving that vibe coders are shipping unstable applications, reporting outages and critical security vulnerabilities in their apps, losing months of work that didn’t use version control, and the anecdotal struggle to finish vibe-coded apps. If professional software development teams do not stay vigilant with their use of AI, they run the risk of sacrificing stability.

Plus, if you’re moving fast, but always having to pick up the pieces caused by over-zealous AI code generation, are you really being more productive?

Is this the next step in the evolution of front end dev?

Salma Alam-Naylor — Mon, 03 Mar 2025 11:54:27 +0000

In 2025, setting up new web development projects is still really, really annoying. And honestly, it’s one of the reasons I either prototype a new project in a single HTML file, or don’t manage to find the energy to prototype a new fun idea at all. Starting a new front end project involves a never-ending list of administrative tasks and decisions to be made, when all you want to do is get building. Your list of setup tasks might look something like this:

Set up a new development environment (install e.g. correct version of node, npm, yarn, pnpm, bun)
Set up a new project (create directory, choose framework, choose starter project or boilerplate, install dependencies, ensure they are compatible with each other)
Define a file structure and component library approach
Define a base style guide and CSS resets
Write boilerplate code to connect to APIs and databases
Configure a build and deploy pipeline
Configure Webpack???

And, if you’re working with a designer, you’ve also got the back and forth handover and sign-off processes to go through, which in a busy team or multi-project agency, can really hold things up. You just want to get building!

There are some alternatives to the time-consuming, decision-heavy setup process. You could use virtual machines or environments that enable faster time-to-setup through scripts and automated processes. But still, even this requires some effort and “onboarding". I remember at one job, I went through a “tried and tested” vagrant virtual machine setup process that didn’t actually work correctly with my version of MacOS at the time. Now, granted this wasn’t a brand new project, but it took me a full working week to configure my development environment so that I could be productive. So what are the alternative approaches? Recently, I’ve become curious about visual development frameworks.

What is a visual development framework?

When you use a visual development framework, you're working in an environment where you don't need to think about — or do — any of the relentless admin and project configuration tasks described above. Everything is taken care of from the beginning, and you're ready to start making components, fetching data from APIs, adding custom code, and watching your ideas come to life straight away. Visual development also removes the need to translate designs from design software to code: the design of the user interface is baked in to how you build it. No more handovers between teams!

In summary, visual development solves two key problems in front end development: it abstracts away the repetitive administrative setup work, and removes the inconvenience of separate design and dev environments.

Here's how working with HTML, CSS and data from an API looks inside visual development framework, Nordcraft. You’ve got a document tree of HTML elements on the left, CSS styling and API connections on the right, and the visual result in the middle. In traditional text-based development, this weather widget might be powered by a collection of files dotted around a codebase. In visual development, it’s all right there.

Is this the next big step for front end development?

A common sentiment among the terminally-online community is that if you’re not writing actual lines of code, then you’re not a real developer; often the industry treats the process of development as the outcome, rather than the actual website or app produced. But when you think about how every evolutionary step of computer science has centred on abstracting away things that no longer make sense for a human to do, then visual development frameworks are the logical next step in the evolution of front end development.

For example, hardly anyone is coding in Assembly in 2025, and we don’t shun people for not being real programmers just because they don’t write instructions to add memory data to a register in a x86-family processor in original Intel syntax, or know the equivalent in AT&T syntax used by the GNU Assembler. Most of us don’t need to worry about this anymore.

Whilst everything is a set of binary instructions at its core, we also don’t need to worry about writing code in binary, thanks to Grace Hopper who released the A-O compiler in 1949, which used symbolic mathematical code to represent binary code. And we don’t even need to worry about writing code in mathematical symbols, because soon after A-O, Hopper released B-O, or “Flow-Matic”, which is considered the first English language data-processing compiler. Each advancement removes another layer of machine-to-human obscurity.

What’s important to note, however, is that the evolution of programming languages was based on computation itself, not human-computer interaction (HCI). In the mid-latter part of the 20th century, there weren’t that many people using computers, and so HCI wasn’t a priority to be optimised for. But in 2025, we live our whole lives through HCI (for better or worse), and what has constantly been overlooked and under-prioritised is the actual experience of this human-computer interaction, both from the point of view as an end-user experiencing something on a device, and as someone who is crafting that end-user experience on a device.

I speak from experience that as a web developer, it can be challenging to create really great experiences and human-computer interactions when you’re constantly moving between different layers of abstraction and relative obscurity (e.g. design → code as text → user interfaces). Visual development frameworks are a tool to help us get the same outcomes as writing traditional text-based code, without the slow up-front time-costs.

My next step

I'm excited to announce that I have joined Nordcraft.com Head of Developer Education.

Nordcraft is a Web Development Engine. Using Nordcraft, you can create fully-interactive front end websites and apps with any APIs, all via an in-browser visual interface. Nordcraft puts human-computer interaction at the front and centre of what you’re building, for both you as a web developer and your end users. And I'd like to go so far as to say that programming in a different way might actually help you understand some programming concepts in a deeper way. Plus, you’ll never have to configure Webpack again.

The team at Nordcraft is also working hard to make Nordcraft fully open source in 2025 and you can check out the progress towards this on GitHub.

It’s early days, but I’m incredibly excited to help shape the future of Nordcraft, and to help you build the best human-computer interactions on the web you possibly can. If you want to keep up with what we’re working on at Nordcraft, subscribe to the Nordcraft Engine channel on YouTube and join the Discord (it’s very active!), and I can't wait to build more silly websites using Nordcraft, for your entertainment.

You are more than the tools you use: tell your story

Salma Alam-Naylor — Wed, 12 Feb 2025 12:55:55 +0000

How many times have you seen someone introduce themselves via the tools they use? Maybe this looks familiar:

Hi, my name is Salma! I’m currently building an app with Express, Nuxt, and the Twitch API. Let’s connect! 🚀👩🏻‍💻🌐

I understand the need to find shared interests with the online community to make genuine connections, I really do, but statements like this don’t tell people anything about what you actually do. Last year I did exactly what I described above. But what does it even mean? Take the following non-tech examples:

Hi, my name is Salma! I’m currently making music with a piano, guitar, and synthesisers. Let’s connect! 🎹🎸🎵

Hi, my name is Salma! I’m currently making food with pasta, onions, and seasonings. Let’s connect! 🍝🧅🌶️

Hi, my name is Salma! I’m currently making clothes with fabric, thread, and needles. Let’s connect! 👗🧵🪡

You get the idea. The above statements tell people about what you’re using, but not about what you are doing. Let’s reframe the above non-tech examples.

Hi, my name is Salma! I’m currently working on an experimental EP that pushes the boundaries of the human perception of sound through the blending of acoustic instruments and digital noise to produce ethereal and meditative soundscapes. 🎹🎸🎵

Hi, my name is Salma! I really love making unique pasta sauces that combine culinary influences from around the world. This week I’m trying to perfect a Japanese-inspired pasta sauce that takes inspiration from ramen and blends it with the traditional Italian concept of bolognese. 🍝🧅🍜

Hi, my name is Salma! I’m currently making all my clothes from old furniture fabric and thrifted offcuts to prove that fashion doesn’t have to be fast to be exciting and innovative. I recently made a dress from my grandma’s old bedspread and I can’t wait to wear it to a party this week! 👗🧵🪡

The above examples may be a little contrived, to say the least, but they tell a story; they reveal a little more about your personality; and they communicate more about who you are. Now, what about that technical example?

Hi, my name is Salma, and I write code for your entertainment. Last year I built a text-based game for my Twitch stream that blurred the lines between me being online and offline, allowing viewers to interact with my stream 24/7. I love to find ways to help people truly connect through unexpected and fun applications of technology. 💖🔥📺

You are more than the tools you use: tell your story. And your people will find you.

3 reasons you should tour a conference talk

Salma Alam-Naylor — Tue, 11 Feb 2025 13:49:16 +0000

In 2023-2024, I gave my conference talk Entertainment as Code six times. It should have been eight times, but you know, life happens. Writing a full-length conference is no trivial matter; it can take weeks of full-time work to craft a captivating story around your chosen topic, and even longer to build technical and/or representative real-world examples to support your narrative. All of this hard work should not go to waste. I want to share my experience of touring a conference talk, and why you should be touring a conference talk, too.

Each talk is the same, but different

The first performance of Entertainment as Code was very different to the last. This was mainly because this talk centred on a new and evolving project I was working on throughout 2024, but also because the very notion of this conference talk inspired the project itself. Entertainment as Code became kind of an ouroboros; the more I gave the talk and spoke to attendees about how they enjoyed it, the more inspiration I received to evolve the project and the talk into its final form.

By giving a conference talk multiple times, you also learn what works and what doesn’t work about your talk. As a (former) comedian, I learned a lot of hard lessons about what works and what doesn’t work for particular audiences in particular venues. I will never forget the time I referred to a fictional seven year old as the c-word to rapturous applause from an audience of twenty-somethings in Camden (trust me, it was funny), whilst repeating the same to a room full of middle-aged people in Blackburn almost ended up with me getting booed off the stage.

I like to weave in jokes to my conference talks, and telling these jokes multiple times gives me the opportunity to iterate and land them as well as possible. The same goes for the content of the talk. In my opinion, no talk should be given in the same way any two times. On the one hand, as the speaker you will get bored. And on the other hand, conference attendees may attend multiple events and end up seeing you give the talk more than once (this definitely happened to me) and so you owe it to them to give them just a little bit more fun, insight, and technical depth than before. They’ll remember you for that.

You get better at giving the talk

Speaking from experience, musicians, and comedians especially, never give the same performance twice. They also never give a performance just once. Each performance is a practice to make the next one better. As a performer, you have a duty to adapt your material to the room in which you’re in and the audience that is before you. A conference talk is also a performance, and it should be no different. And in intentionally adapting and iterating on your conference talk as you tour it, you learn more about public speaking, how to tell a really compelling story, and the content of the talk itself.

My conference talks usually start with a strict script. As time goes on and I give the talk more times, I know the material more, my confidence grows, and as a result I’m able to improvise and go off-script, adapting the material to the audience and the room with little effort. It is incredibly satisfying for both the speaker and the audience to deliver the material in a way that resonates particularly with that room of people on a particular day.

Your talk reaches more people

According to a quick internet search for “average tech conference attendee numbers”, the average number of attendees at a UK conference is 100. Giving your talk to just 100 people and calling it a day is not a good return on investment for potentially weeks of work. After putting in that work, you owe it to yourself to submit those CFPs, and get yourself an audience. The more people you reach, the more opportunities you may get in the future. And the cycle continues. You become the ouroboros. And the cycle is complete. And if you enjoyed the process, write a new talk, and do it all again.

How I created a newsletter I actually enjoy writing

Salma Alam-Naylor — Thu, 06 Feb 2025 13:09:21 +0000

Lots of developers send newsletters, and as I thrust myself into the online technology space in 2020, it was an item I added to my to do list straight away. Given the incessant algorithmic curation of content on the web, a newsletter is a crucial tool in being able to reach an audience consistently; someone giving you their email address is a powerful indicator of trust. But it took me three more years to actually start sending a newsletter because it felt like such a huge effort amidst everything else I had to do for work and for life.

It turns out I was over-engineering the concept of sending a newsletter in my head. And it really can be as simple as you want to make it. Since January 2024, I’ve sent 56 weekly issues of my newsletter, and I’ve enjoyed writing and sending every single one. Here’s how I approached creating and sending my newsletter, weird wide web hole, to make each issue easy to write, and delightful to send.

Send what you would like to receive

I am a huge fan of weird things and obscure things, intriguing experiences, and things that don’t always appear to be what they seem. Since the early days of the internet, I have always been fascinated with strange websites, curious applications of technology, the vastness of the universe, and unexpected collaborative online experiences. I am always thrilled to discover a non-standard, and perhaps unknown website written by a stranger, because I get to peek inside their head and explore the inner qualities of their soul and expression, and the human condition itself.

I created weird wide web hole to satisfy my own desires to explore the weird side of the web. I send what I would be excited to receive: obscure descriptions of strange and intriguing websites and incantations of wonder and curiosity. Every word I send and every link I collect is intended to make you pause, appreciate, and explore things differently to how we’ve become accustomed on this vast world wide web.

Make it easy for yourself

Lots of newsletters contain lots of words. As a consumer of newsletters, I often find I can’t make the time to read so many words. Newsletters often sit unread in my inbox for days, until I have the time and space to enjoy them. The attention span of the world is disintegrating before our very eyes, and so I purposefully choose to write just a few words. Yet every word I write is written intentionally, and for you to consume deeply and deliberately. I write few words because I mindful of your time and of my own time. And writing fewer words makes approaching each newsletter cognitively easy. Each issue takes around five minutes to put together.

Additionally, each newsletter contains just four links, which I collect throughout the week. Four is a very achievable number, and often I have a collection of links that are lined up for one or two future issues. I write the foreword to each issue on the day I send it, purely inspired by how the links in the newsletter made me feel, or what’s going on in my head that day. I don’t think too hard about what I write, I just let it happen.

Do it for the love, not the numbers

At the time of writing, I have 346 active subscribers to my newsletter. That may seem like a small number compared to the number of people who know me on Bluesky or Twitch or even Youtube, but if you visualise that number of people in a room, it’s actually quite wonderful. I have the attention of almost 350 people, every Thursday.

I know weird wide web hole may not appeal to a vast audience, and I actually kind of like that. I’m not going to sign off this blog post with a call to action to subscribe, because if you wanted to enter the weird wide web hole, you’d already be in there.

goodbye

How I learned to code with my voice

Salma Alam-Naylor — Tue, 04 Feb 2025 15:22:33 +0000

In January 2025, I developed excruciating pain and pins and needles in my hands, which made it very difficult to type and use my trackpad. I panicked. I couldn’t work. And if I couldn’t work, I couldn’t earn money. And if I couldn’t earn money, I couldn’t afford to eat or pay my mortgage. I was actually really, really, scared.

After ruling out potentially genetically inherited rheumatoid arthritis with x-rays and blood tests, I deduced that probably I had carpal tunnel syndrome (which, coincidentally, my mother also suffered with). The most recent development, after seeing a physiotherapist, is that my symptoms don’t actually align with carpal tunnel syndrome, but instead, abnormal pressure on the radial nerve, primarily in my right arm. I’m doing some prescribed daily exercises that are alleviating symptoms somewhat, but the bottom line is that rest is the best medicine in this case: physical rest and mental rest. My physical pain is real, but given the personal events I have endured over the last two years, I also believe that this manifestation of pain has been exacerbated by a combination of a series of emotionally traumatic events. I may write about this at a later date, but in this post I want to talk about how I learned to work and code using my voice, and offer some advice if you, too, find yourself in this extremely difficult situation.

Getting started is challenging

I knew I had to do something to ease the pain to enable me to work, but I had no idea where to start. And so I turned to Bluesky to ask if anyone had any advice. The advice was overwhelming, actually. Ergonomics, exercises, meditation, alternative keyboard layouts, and voice control. And when I asked for advice on how to approach voice control and coding by voice, the advice was even more overwhelming. Everyone was very generous with their advice, but whilst dealing with debilitating pain, I was surrounded by a seemingly endless list of tools, plugins, apps, custom setups, and confusing options that left me feeling incredibly afraid for my short term future. How was I supposed to learn all of this to work effectively right now?

Initially I made the mistake of trying to use all the tools at once. The result? Complete and utter confusion. I felt like I had reached the limits of what my brain was capable of, and this felt devastating. But, I did what every good software engineer does when dealing with a difficult bug: I stripped everything down and pieced the tools and functionality back together, one by one. Next, I’ll detail the tools that worked for me, and I’ll follow with some important advice that I wish I’d found or that someone had given me when I was at the start of my journey.

My voice coding tools

I found success in just two weeks with just four tools.

Talon

Talon enables you to write code, play games, and control your computer with voice, eye tracking, or noises. It is certainly a powerful piece of software — but it is a heavy lift to set up. I was fortunate that I was able to afford some light use of my hands whilst installing and configuring my Talon setup, but it probably would have been impossible if I had zero hands to work with.

Talon is entirely geared towards software engineers. So much so, that setting up Talon requires being able to navigate your terminal, and write or install script files before you can even use any type of voice control effectively. Fortunately, the Talon community gives you a much-needed head start by providing a selection of useful scripts in the community repository on GitHub, which you can clone directly inside your .talon directory created on installation. This repository of Talon scripts allows you to get started relatively quickly in using VSCode and other IDEs, web browsers, email programs, work-based chat programs such as Slack, and even kubectl. Without this community repository, I would have been completely lost.

You can also fork the community repository, make some changes according to your needs, and clone that to your .talon directory. The current recommendation is not to modify too many files in the community repository, and to add your own files to make modifications where possible, to avoid any merge conflicts when pulling in new changes to the community maintained repository.

I also wrote a few of my own Talon scripts to make running commands in my terminal a lot easier, such as npm run dev (rather than having to spell them out), and you can view these in my talon-custom repository on GitHub. I also modified many of the default spellings from American to British English versions. Talon also has a very helpful Slack community, which is a bonus.

Cursorless

Cursorless is a tool to use in conjunction with Talon, to help speed up the way you navigate and interact with code in VSCode. The main superpower I have so far unlocked with Cursorless is instead of having to ask Talon to move the cursor down a few lines, or left a couple words, and then select some text and/or delete it, you can do all of that in one Cursorless command. Now, it is clearly far more powerful than that, but with Cursorless you need to start slowly, and you need to have learned the Talon alphabet before any of this is possible. More on that later.

Apple Voice Control

Whilst trying to get to grips with Talon, I found that Apple Voice Control was a good option for being able to use my mobile devices effectively, and for being able to complete basic tasks on my MacBook such as window switching, natural voice dictation and web browsing. I was particularly impressed with the ease of targeting clickable elements using the “show numbers” command, which assigns each clickable element on a screen a number that you can select with your voice. The way that the functionality of Apple Voice Control is mirrored across different MacOS and iOS devices is really well thought out, and I can see it working well for the most part for people who don’t need to code with their voice.

I will mention, however, that a number of web apps do not yet respond well to the text editing commands provided by Apple Voice Control, in particular Notion, which I use on a daily basis. Bear this in mind if you need to rely on Apple Voice Control for longer periods of time; it might just ruin your day. I had much better success using Talon with Notion when I had learned more of the Talon-specific commands.

Rango

With Talon on its own, navigating the web is still a challenge at first. Often I found myself switching between using Talon and Apple Voice Control so that I didn’t have to use the mouse functions in Talon to click on buttons and other clickable elements, because saying tab over and over again to reach my desired click target was time consuming and frustrating (not to mention that tab orders often suck on web pages, and click targets do not always have clear focus indicators) and I found it difficult to learn the Talon mouse commands. The Rango browser extension in conjunction with the rango-talon user file set gave me the same functionality of the “show numbers” command from Apple Voice Control, but without having to use the command itself, allowing me to click on any clickable target effectively using letters from the Talon alphabet, without having to say “tab” 100 times.

Other tools I tried with less success

Given that learning how to use my voice to work was frustrating, I fell into the trap of trying to find a tool that would give me back the power of typing code as quickly as possible. I tried two more approaches that I currently do not recommend.

Serenade

Serenade claims to offer you the ability to write code using natural speech, which sounds incredibly enticing, but I had limited to no success with this product. The tutorials gave promising results, but I have a feeling that Serenade is geared entirely towards React and Python apps, as when trying to write code inside a Vue/Nuxt app, Serenade didn’t understand at all how to do what it claimed.

Voice dictation to direct AI code generation

An interesting suggestion I received was to use voice dictation as a way to prompt AI code generation tools to write the code for me. I tried this using Claude inside Cursor and hated it. My end goal was to be able to use my voice to work in the way I was accustomed to, rather than switching to an entirely unfamiliar AI-codegen-based workflow.

Important advice for learning to code with your voice

Here are some of the things I wish I had known before learning to work with my voice.

Take it slowly

The one thing I wish that had been communicated to me from the beginning of my journey is that you have to start slowly. Really slowly. Using a computer and coding with voice is an entirely new, and let’s face it, alien skill. And with any new skill, you can’t be expected to go from zero to 100 in a day. The dissonance I felt with this though, is that I could already code, and I was frustrated that I couldn’t reach my typing levels of productivity faster. I had ideas I wanted to get into my IDE, I had a vision for an app that I wanted to build, and I hated the fact that my body wasn’t letting me do it.

Initially I installed Talon and Cursorless, watched two tutorial videos, and wanted to get to work. But I couldn’t; the landscape was entirely unfamiliar. I felt stuck. And then I had to force myself to do what any teacher would tell you when you got stuck: take it slowly. And start from the start.

Start from the start

When learning anything, it can be tempting to try and dive right into the deep end to get a head start. But if you can’t swim, you’ll drown. When learning to use Talon, you have to start from the start: the Talon alphabet.

Talon uses its own proprietary alphabet which allows you to dictate single letters. A common concern is why Talon doesn’t use the NATO phonetic alphabet to avoid needing to learn a whole different map of words to single letters. The answer is that the NATO phonetic alphabet uses a collection of words that are two or three syllables in length, whereas each Talon letter name uses just one syllable. This means that in using the Talon alphabet, you’ll be uttering less than half of the syllables needed compared to the NATO phonetic alphabet in order to be productive.

I learned the Talon alphabet fluently with around one hour of dedicated practise time on a Sunday evening, and this website in particular, which uses a flashcard system, was incredibly helpful: LearnTalon.

Ramp up gradually before trying to code

Before attempting to code, I would recommend learning a few more skills in using Talon to navigate and edit text (rather than jumping straight to Cursorless). This will also help you with general prose writing and navigating the web and your machine. Talon Practise was incredibly useful for this, giving you the opportunity to practise particular skills in small, focussed exercises. My favourite exercise which I was very excited to master was the copying, pasting and selection exercise.

Before using Cursorless, try using just Talon to edit some code. This will make the usefulness of Cursorless much more obvious if and when you decide to use it.

Try small coding tasks before big ones

We’ve all got jobs to do, and you’ve probably got quite a few big tickets looming over you on that project board. But you have to start small. Completing a small coding task with your voice, and committing and pushing the code in the terminal using your new-found Talon alphabet skills (gust sit trap space say commit space dash made space quote say completed small task quote slap), will give you a feeling of accomplishment like no other.

My first all-voice code change and commit was commenting out a function in my Twitch bot which I no longer needed, and committing and pushing that change in the terminal. Watch the clip on Twitch.

You will get better

After two weeks of using my voice to work and code for around 80% of the time, I was able to successfully (yet slowly) use Talon and Cursorless to add a whole new feature to my website, and I wrote about it here: How to build a copy code snippet button and why it matters. You will get better at this, but it will take time and practice. Make sure to take regular breaks, because using your voice so much will be exhausting, not to mention the new cognitive overheads of trying to do your job in such a different way.

Fortunately for me, my pain is also getting better and so I’ve been able to use my keyboard and trackpad more than I was able to over the last few weeks. That being said, given I have become comfortable with using my voice to code, write, and navigate the internet, I find myself switching between using my hands and voice throughout the day. Maybe it’s because I feel like I don’t want to lose this new skill that I had the necessity to learn, or maybe it serves as a cool party trick to demonstrate when live streaming. But more importantly, it hammers home the fact that one day we all might succumb to a temporary or permanent disability, and as web developers we have an important responsibility to build empathy and accessibility into our professional practice at all times.