Jim Nielsen’s Blog Verified ($10/year for the domain)
Theme: This feature requires JavaScript as well as the default site fidelity (see below).

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Jim Nielsen’s Blog

You found my HTML feed — I also have an XML feed and a JSON feed.


Subscribe to my blog by copy-pasting this URL into your RSS reader.

(Learn more about RSS and subscribing to content on the web at aboutfeeds.)

Recent posts

Two Quick Tips When Building With React Router


I’ve been working with the latest Remix-ification of React Router and there are two things I wish I had known when I started.

So I’m writing them down in case anyone else is about to start a React Router app.

1. Flat Action Data When Using JSON

If you’re submitting JSON, e.g.

  { key: "value" },
  { method: "post", encType: "application/json" }

It’s good to keep your data flat because it gives you the easy and flexibility to submit the same data as a native <form> submission later (without JavaScript).

For example: let’s say you have some data for an action in your application. You can submit this as JSON with a structure where you separate the intent of the action from the payload itself, e.g.

  "intent": "update-person"
  "payload": {
      "name": "Jim Nielsen",
      "email": "jim@example.com"

However, once you have a structure like this, it becomes more convoluted to submit and parse that same data using a native <form> element.

But if you use a flat structure, like this:

  "intent": "update-person",
  "name": "Jim Nielsen",
  "email": "jim@example.com"

Then it’s simpler to represent that same action as a form in HTML which doesn’t require JavaScript to submit:

  <input type="hidden" name="intent" value="update-board" />
  <input type="text" name="name" value="..." />
  <input type="text" name="email" value="..." />

And getting/parsing that data from formData to a JavaScript object becomes simpler and more straightforward.

So keep your data as flat as possible because it gives you the flexibility to write your mutations declaratively in HTML or imperatively in JavaScript, depending on the context and needs of each use case (trust me, you’ll thank yourself one day if ever migrate to Remix and introduce a server).

2. Be Specific Naming URL Params

It’s ok to type a little more, I promise.

When coming up with your URL params, you could have patterns like this:


Which you can access in nested routes using hooks:

// At the route: `/files/1234`
const { id } = useParams();
// id = 1234

But you can easily outgrow those generic param names as your features become more rich and the entities in your system develop more relationships which themselves also have IDs.

Then you end up with param conflicts:


One solution to this might be to name your IDs for the kind of ID that they are. For example, maybe one of my IDs is a UUID (e.g. 550e8400-e29b-41d4-a716-446655440000) whereas the other ID is just an int (e.g. 351).


But you can end up in the same place if, later on, you need to switch from one identifier to another (or you get another entity in your system that necessitates using the same kind of identifier).


So, given my experience, I would say: be specific in naming your params. Then the risk of namespace collisions in your params is decreased drastically and you won’t have to refactor your code as you add new entities. Plus the code is — IMO — just flat out clearer.


Accessing those params is now super easy anywhere in the code. In addition, finding those named params anywhere in your codebase is much easier too (vs. the generic id).

// At route: `/teams/0001923-02930-123/users/1234`
const { teamUuid, userId } = useParams();

// teamUuid = 0001923-02930-123..., userId = 1234

Comment? Reply via: Email, Mastodon, or Twitter.

UI=f(org): UI is a Function of Your Organization


The Domino’s “Pizza Tracker” is an intriguing piece of UI.

As an end user, it provides the precision of detail you want in tracking your order:

  • Your order has been received
  • Your pizza is being prepped
  • Your pizza is in the oven
  • Your pizza is being checked for quality by {EMPLOYEE_NAME}
  • Your pizza is being delivered by {EMPLOYEE_NAME}

But think of everything it takes to make that UI possible, where every digital order routes to a local store and every local store has the hardware and software to live track and update the position of your pizza.

I’ve worked on a project like this, a “track my claim” in the insurance world. As a designer, it’s nice to sit at a desk and design an ideal scenario:

  • Something happened to your house
  • You file a claim
  • Your claim is reviewed
  • An adjuster visits your house
  • $$$ is wired to your account

But when the rubber of your UI hits the road of reality within an organization, people and processes often cannot bend and stretch to the automated expectations of a idealized process.

What do you end up with in that scenario? A thousand tiny compromises.

For example (going back to pizza), you find out that not every store can track precisely when an order is received and when it goes into the oven, so the UI becomes a facade — dare I say a lie — where the step from “order received” to “pizza in the oven” happens only because of a timer in the UI (and a corporate policy of, “all orders must be in the oven within five minutes of being received”). It’s not a representation of reality, but a facade of it.

These kinds of facades happen all the time in software. “We think this will complete, at the most, within ___ time.” So we make progress indicators that look like they’re a live, up-to-date representation of progress that poll some kind of technological feedback mechanism for live status updates. But in reality they’re merely clocks counting down from a set time of “this is the most time we think it should take”.

This is why designing UI is designing an organization.

You can only design and make real a UI that matches an organization’s capabilities to deliver on its promise.

This is why startups are best suited to these kinds of radical UIs tailored to reality. Their entire organizational structure, which is small, can orient around a single idea and deliver on it — then build to scale.

Your UIs, and the real life experiences they deliver, can only ever be as good as an organization’s capabilities to deliver on them.

This is what I mean by UI=f(org): UI is a function of your organization.

Comment? Reply via: Email, Mastodon, or Twitter.

Zero to Unmaintainable in 1.2 Commands


Dave posted “The time to unmaintainable is very low” about how pervasive this idea of “get up and going quick” is:

I can burp some npm commands into my terminal, burp some more to setup a deployment pipeline and blam! Website. The time to product demo is so low.

But there’s little to no mention of what comes after that. Buyer beware:

it’s possible you’ve [generated] something way past your ability to maintain.

This resonates. And it got me thinking.

You know how the car industry loves the acceleration measurement of zero to sixty? Like, “This car will do 0 to 60 in 2.5 seconds!”

The front-end industry’s equivalent is how fast you can standup a project. Like, “Get this whole thing stood up and deployed in 2 commands!”

But as Dave points out, you can accelerate from nothing to unmaintainable very quickly and easily.

I realize I’m complaining about moving too fast but that’s not my intent. Although, I could argue that while driving 200mph is fun and exciting, you’re one small fuckup away from a major fuckup. My point is that a key factor of sustainability is making sure maintainability stays on par with growth. At the risk of sounding like a Luddite – which I am – the ability to fancy copy-paste your way into an unmaintainable situation is higher than ever and that’s a trade-off we should think about.

There is such a focus on how quickly you can get going, but so little focus on how you maintain what you just created. Featured in the hero section of every tool is the single command to get started:

> npx create cool-thing@latest

But no mention of everything that comes after, like:

54 vulnerabilities (26 moderate, 23 high, 5 critical)

Have you tried updating major versions across different tools which are iterating at different paces in different directions with different goals?

It feels akin to credit. Credit is a great tool, and readily and easily available in so many places today. But if you’re not careful, your ability to easily borrow and use credit will quickly outpace your ability to pay it back.

They say the two best days in a boat owner’s life are: 1) the day they buy a boat, and 2) the day they sell it.

Similarly, the two best days in a web developer’s life are: 1) the day they scaffold a new app with the latest and greatest, and 2) the day they rewrite it.

Comment? Reply via: Email, Mastodon, or Twitter.

The Case For Design Engineers, Pt. II


Previously: The Case For Design Engineers, Pt. I.

You’re given a design with a note: the dividing line between these two containers should be interactive so the user can drag to resize the respective containers on either side.

Perhaps that note is all you get.

Or perhaps the designer gives you a little more detail, like some mocks depicting an “interaction state” that shows how thick and what color the border should be when the interaction takes place. Maybe they even specify using an appropriate cursor.

Or maybe they don’t tell you any of that and you have to figure it out yourself.

Either way, it’s not everything.

Assuming we’re talking exclusively about a desktop device with fine-grained input like a mouse, many questions remain. For example:

  • Does the interaction have a resize affordance?
  • How does it happen (e.g. on mouse in or mouse down)?
  • When does it happen (e.g. immediately or on a delay)?
  • Where does it happen? Directly on the line itself, or in a target area? How big is the target?
  • Is there some kind of snapping involved?

I recently worked on a feature like this, where there were so many tiny details like symmetrically balancing where the resizing affordance happens between two boundaries.

If you zoomed in super close, this is what was happening:

And it felt off. Why? Because the area that triggered the showing and hiding of the resizing affordance was asymmetrical. You moved your mouse in from one side and the affordance triggered, but if you came in from the same side of the other container it didn’t.

This is what we wanted:

It’s hard to even articulate this scenario with words and pictures. Sometimes you just have to feel it, use it, to understand the nuances.

This all might seem obvious — but the obvious is not always implemented. Sometimes it’s not as obvious as you might think. And sometimes the obvious is just too much work, so it gets skipped.

The point is: look and feel is hard to design, let alone spec, in a design tool. You need someone who understands what’s possible in the medium (and I mean the medium you’ll deliver the interaction in, not the medium you’ll design it in — those can be different).

You need someone who can do design work with code.

That's right: design work with code.

Pixels of an interface from a GUI tool are a static representations of a dynamic form. It’s the difference between a picture of me and the living, breathing, moving me.

Design engineers don’t just push pixels around in a GUI tool, they do it in a web browser — the medium of delivery — designing not just the visuals but the interactions that make sense for a living, breathing, moving interface.

This approach to design — designing with code — doesn’t result in one artifact that approximates the final deliverable to drive consensus, then requires a translation to the deliverable artifact itself.

Instead, the artifact is the deliverable — just in embryonic form.

It may seem obvious, but a designer’s deliverable is not a customer’s product.

Going back to the resizing example, building the micro interactions in the browser is design work. The “design review” is building something, sending people links, and saying, “What do you think?” Collecting feedback, then iterating again.

The value of this “design critique” is that it takes place on the actual artifact you put into the hands of your customers, not some faux interaction that must be later implemented in the final medium. It’s not the approximation of an idea but the idea itself, implemented iteratively.

And you need either 1) a person who understands and can work in both forms, or 2) two people who can work closely together to nail down all these details and make decisions along the way until you have something that feels right, that feels intentional, that feels designed all the way through — not “designed” then “implemented”.

Comment? Reply via: Email, Mastodon, or Twitter.

A Golden Era of Blogging


Matt has an interesting post titled: “Today’s YouTubers are repeating the mistakes of yesterday’s bloggers”. While I’m not super into the YouTube scene, his observations sound right from where I sit.

He points out how some of the YouTube creators he loves and follows are beginning to squander the craft of their work, the very thing that brought them followers in the first place, in order to chase percentage points of revenue doled about by the mysterious mechanisms of the YouTube payroll. It’s a scenario, he suggests, we’ve seen play out before:

It reminds me a lot of how blogging changed around 2005-2009, when ad money came pouring in, and while it was great for bloggers that previously were just publishing for the heck of it (myself included), eventually the money tainted the process as many people rushed to improve their bottom line, often at the expense of whole reason they created their sites.

And what was the outcome of this shift?

Eventually, the blogging ad market changed so much that if you were consistently making money with blogging your site had to morph and change drastically to fit the needs of advertisers, not your readers. And you tend to lose lots of readers in the process, as your site strays so far from its original intentions.

Platforms are like Rumpelstiltskin: they promise to spin you some gold, but in the end demand your first-born child.

One thing I love about the blogging world right now — and by “world” I mean the “webdev tech blogging world” that I live in — is that there are very few, if any, substantial monetary incentives. All the incentives to make a living producing content are over on other platforms, which means those who are blogging are doing it out of love, passion, or some other reason that’s (yet) to be tainted by substantial outside influence. As Matt says:

obsessing over how to eeek out every last cent from your work will make your work suffer.

On one hand, I’d love to see people get paid for their writing. On the other hand, it’s awfully hard to not let money change motivations — and I love seeing what people write about when monetary influence is negligible.

Love, passion, and curiosity — more than money — fuel the majority of posts that show up in my RSS feed every day and I love it.

Forget the days of Google Reader, now is a golden era of blogging.

Comment? Reply via: Email, Mastodon, or Twitter.

Using Quadratic to Discover Newsletter Links


I built myself a daily email digest that informs me who is linking back to my blog.

It’s a fun way to discover new people, blogs, and newsletter that I didn’t know existed.

I recently saw links to my blog from the tldr newsletter but didn’t know which posts specifically they were linking to.

Screenshot of tldrnewsletter.com showing up in my analytics email digest.

I visited their site to find out, but it appeared to be an archive of daily newsletters. I realized it would take way too long to go through every newsletter trying to find a link to my blog.

So I tried doing a site-specific search, but their domain didn’t appear to be indexed by Google as there were zero results. Bing and DuckDuckGo didn’t have any useful results either.

I could’ve just stopped investigating at that point, but my curiosity was triggered. “Oh yeah, think you can hide your links from me?” I thought.

Challenge accepted.

I started investigating their site structure and discerned that all their newsletters were archived by date following this pattern:


For example:


Once I discovered that, I was already writing a script in the back of my head that would fetch one newsletter per day, going back 30-60 days, and find any links to blog.jim-nielsen.com.

The cumbersome part about doing something like this is getting all the tooling in place to do it. For example, as a little node script, I’d need a couple packages off npm (e.g. for parsing HTML and finding links). Then it’s a matter of writing some code, running the script, logging stuff to the console, tweaking and repeating until I have what I want.

But then I thought, “Wait a second. This is a perfect use case for Quadratic!”

(Quick aside: Quadratic is the developer-focused spreadsheet I’m working on for my day job. Imagine if Excel and Figma and VSCode had a baby. That’s Quadratic. A spreadsheet, on an infinite canvas, that runs code. Granted right now it’s only Python code, and I’m no Python expert, but it has AI integration so novices like myself can quickly ask things like, “How do I add data to an array?” And it will give me back working code. So I can become productive quickly.)

Quadratic was a fabulous tool for this scenario because:

  1. I don’t want to setup (and maintain) a whole environment to run a little script (node + npm + 3rd party packages, etc.) This all runs in the browser, so all I need is a URL and “it works on my machine”.
  2. I want to visualize the data I’m working with. Rather than just logging strings of JSON data to the console and parsing/tweaking as I go, Quadratic lets me render data to the structured grid of a spreadsheet. This makes it easy to do things like: fetch data, render to column 1; read data from column 1, filter, massage, do logic, then render to column 2; highlight resulting data as the answer I’m looking for!
  3. I can share the results of whatever I discover easily by copy/pasting a link.

So I opened up Quadratic and wrote a little script. It:

  • Creates a list of dates going back n number of days, e.g. ['2024-01-29', '2024-01-28', '2024-01-27', ...].
  • Fetches[1] the HTML for each of those dates from tldr.tech.
  • Uses Python’s Beautiful Soup to parse the HTML and pull out all external links.
  • Render the links to a column in the spreadsheet along with what newsletter date they were found in (and print to the console any newsletters it didn’t find).

Screenshot of Quadratic with a spreadsheet of data on the left, contaning links. And on the right is a code editor with a Python scrpt that retrieved the links in the spreadsheet, along with a console that logs output from the script.

Kind of a lot of data to fit into a small screenshot, but here’s what you’re looking at:

Screenshot of Quadratic with a spreadsheet of data on the left, contaning links. And on the right is a code editor with a Python scrpt that retrieved the links in the spreadsheet, along with a console that logs output from the script. Arrows and text overlay the image pointing out the different panes of the application.

A lot of links! The spreadsheet lives on an infinite canvas, so it’s easy to zoom out and see the shape of the data I’m looking at:

Screenshot of Quadratic with the canvas zoomed all the way out, reveleaing a sheet with approximately 600 rows of links.

Approximately 600 rows of link data!

Now that I have all the raw data in a column in the sheet, I start another column of data that reads in the first column of links, looks for ones that contain blog.jim-nielsen.com and then renders that to the sheet in a new column.

Screenshot of Quadratic with spreadsheet data on the left, containing a giant list of links and a filtered down list of those links. On the right is the code editor with a few lines of Python code that filter the list of links in the previous column.

Again, annotated:

Screenshot of Quadratic with spreadsheet data on the left, containing a giant list of links and a filtered down list of those links. On the right is the code editor with a few lines of Python code that filter the list of links in the previous column. The screenshot is annotated with red boxes, lines, and text pointing out the relationship between these different pars of the application.

And that’s it! Pretty quickly I had found all the individual newsletters that linked to my blog. From there, it was easy to visit the link of each newsletter and find where they linked to my blog (and what they said).

And the best part was I could do all of this from my browser in a visual way. No local environment setup. No garbled strings of text in a console with me trying to parse and decipher the data. Simply fetch data, render it to a structured grid, filter/manipulate it, and find exactly what I want.

I even ended up using a couple cells as “input variables” to my script — like what domain to search for or how many days back to look — then I could change that cell and the whole script would automatically re-run. Here’s a screenshot of my final sheet:

Screenshot of a spreadsheet in Quadratic with data about links from tldr.tech to blog.jim-nielsen.com

Even better than a screenshot, we recently shipped file sharing and multiplayer so you can dive right into the app and see the sheet for yourself (no need for an account):

My link parsing spreadsheet in Quadratic →

That said, you gotta have an account to clone the sheet and play with it yourself (sorry I didn’t set it to publicly editable because I don’t want my sheet messed up — not that you would dear reader, but you know, the internet).

I’ve built a fair number of little discovery tools like this in Quadratic over the last few months. I hope to share more soon.

  1. Because the code uses the fetch API natively, CORS can be a problem. We’re working on this, but for my purposes I used a CORS proxy.

Comment? Reply via: Email, Mastodon, or Twitter.

Tagged in: #quadratic

Treating the Symptoms


If you haven’t seen it yet, the folks behind The Browser Company recently introduced a new app called “Arc Search”. Its key feature? It’ll browse the web for you.

What happened? “Surfing the web” used to be — and still can be — the funnest part about being on the web!

How did “surfing the web” become “doomscrolling”? But I digress.

When you tap “Browse for me”, the app goes out to the internet, consumes numerous websites on your behalf, and then creates a custom web page amalgamating what it found — a custom webpage for every search query.

Interesting, but not that different from what Google has already been doing for a while where it pulls information out of individual web sites and puts it into its own search results.

Now I do appreciate that people are trying new things. I always love a novel take on an age-old problem.

But critique is valuable too and through that lens I appreciate Ben’s recent post “Stripping the web of its humanity”. He articulates what struck me the first time I tried Arc Search:

Finally, obviously, the sources themselves are automatically browsed by the app but don’t see the benefit of a human visitor. Real people sometimes pay to access content, or donate to support a nonprofit publisher, or watch an ad. Those things can be annoying but pay for the content to be produced in the first place. If we strip them away, there’s no writing, information, or expression for the app to summarize. A world where everyone uses an app like this is a death spiral to an information desert.

What’s ironic here is that Josh Miller, CEO of The Browser Company, tells the story on Twitter of why they built Arc Search and one of the big impetuses for building the product was based on this observation:

we realized...the mobile web is so broken & frustrating

Perhaps, you could argue, Arc Search fixes the problem of browsing the mobile web from a technology perspective.

But the state of the mobile web is not a technology problem. It’s a people problem. People and incentives.

And while I appreciate as much as the next person technology that bypasses people problems — popup blockers, ad blockers, tracking blockers, etc. — I am under no illusion that these don’t solve problems. They treat symptoms.

The incentives for publishing anything on the web continue to receded more and more — as Baldur points out in his piece about the web’s broken social contract:

Our incentive recedes in lockstep with the increasing dominance of generative AI content. As it recedes, fewer and fewer people and organisations will contribute to the digital commons. More and more stuff will be locked behind a paywall.

The incentives are increasingly being structured so that the free and open web will become neither.

Comment? Reply via: Email, Mastodon, or Twitter.

An Inbox Full O’ Receipts


Dave parodying those pesky “Dear business owner” emails one tends to get:

I clearly have no ethics, but you should enter a business relationship with me, a guy who found your email on the internet.

That’s the subtext of those emails.

You are now signed up for a no-opt-out email drip campaign to send you automated replies every day for the next week to get you to reply.

Dave’s post is in the context of drive-by email spamming.

But what triggered me was the similar subtext communicated when you purchase products (that you sought out) from legitimate businesses.

You know that feeling when you just need to buy one thing online, your email is required as part of the transaction, and now you are subscribed to an email campaign until the end of time (unless you then explicitly opt-out)?

Yeah, that “standard” practice. This is the subtext:

“Hello. You just purchased some of our ___. Thank you for signaling your interest in our product. You had to enter your email to complete that transaction, and now we have opted you in to a campaign that will send you automated emails of our latest offerings and information about our business. You had no choice in this. You will now receive these emails forever unless you find the little tiny unsubscribe link in these emails and click it. Once clicked, you will be taken to a page where you have to click a button to actually unsubscribe (this is because some email clients automatically follow links in our emails, like the “Unsubscribe” one, so we have to ensure you actually want to unsubscribe to these emails which you never subscribed to in the first place). Thank you for doing business with us. We hope this will hook into giving us more money in the future.”

It reminds me of those really long receipts you get from places like CVS. You buy one thing, you get a receipt that’s two feet long.

That’s how I feel buying things online. You buy one thing and the default is you now get an infinitely-long receipt.

A photography of a series of receipts that get progresively longer right-to-left. On top of the photo is superimposed a series of email screenshots which represents the longest “email” in the series.

Comment? Reply via: Email, Mastodon, or Twitter.

Online Handles: A Round-Up


After asking about the origin of online handles, I heard back from a number of folks and loved the stories.

It’s fascinating to see an online name like “Apple Annie”, read the origin story, and see this wonderful, multi-faceted human being with a rich history behind the seemingly-random string of characters on screen.

It makes the internet more human and I love it.

So I wanted to follow up with a collection of what I heard from folks.

First, the two people mentioned in my original post:

  • Jeremy’s handle adactio is a secret that he’s keeping — which means we’re all free to speculate wildly on its origin and meaning. Here’s my guess: the adac represents a series of musical notes, depicting his love of music; the t is shorthand for “tea”, noting his English background; the io stands for “input/output” which means he is both a tea input/output machine but also references his nerdy love for computers. So the meaning of adactio is “your music-loving, tea-loving, computer-loving, man from England”.
  • Dave named his cardboard box robot costume from summer camp davatron5000. Due (at least in part) to peer pressure, he still uses that handle today.

A few replies from Mastodon:

  • Kristof was around early enough to snag the terse kiko which later became the envy of business. It’s always fun to hear about individuals who were on the scene before the internet became commercial and, as such, were able to grab coveted names. As I noted, early bird gets the worm domain.
  • Philip noted how he would borrow handles from whatever was the craze of the time, such as The Lord of the Rings. It reminded me of when I was a teen and we scoured the Bible dictionary looking for obscure names that would make good online handles.
  • Keith used his middle initial to differentiate himself from all the other Keiths of the same name and now his middle initial is part of his career identity. I suspect this a common occurrence. Tell all new parents: in the global namespace, middle names just became a lot more important, ha!
  • As I alluded to in my original post, it seems many folks had quirky names but then felt the need to “grow up”. For example: Maurice had “madbrain” while Mary used her roller derby name “Captain Painway” (imagining myself in a dark roller skating rink, that is a terrifying name).
  • Mia’s story has so many familiar elements. Her first handle was a familiar algorithm: name + repeat a character until the system says it’s unique. Then she chose a handle that was close to her real name, but off slightly, and found people started calling her by that in real life which became annoying. So then she found terribleMia and stuck with it as a way to fight professionalization.

Folks who published their stories on their blogs:

  • Paul Traylor was inspired to use KungFuDiscoMonkey through his time in Boy Scouts, which he later abbreviated to kfdm which, turns out, is also a TV station in Texas.[1]
  • Thomas dug into the family tree to come up with hryggrbyr and now I don’t know how I ever missed tapping the well of genealogy as a source of inspiration for online handles.
  • Thomas has a long, winding origin story with a handle that started as kingkong in 1993. I love it — ask anyone who has been around computers for a long time and they’ll always have a great story to tell about the history of their online handles.

  1. When I was a teen in scouting, we always had to introduce our “troop” (a group of scouts) by doing our troop-branded cheer. The other troops always had some cheer about integrity or group spirit — the kind of stuff we thought was lame. So, much to the chagrin of our scout leaders, we always introduced our troop, number 376, to others with this jingle: “Three-seventy-six. Buff-a-lo chips. Rumble, rumble, rumble, rumble, [fart/poop sound].”

Comment? Reply via: Email, Mastodon, or Twitter.

The Origin of Online Handles


There are a few people online whose ubiquitous usernames I’ve always wondered about.

For example: Jeremy Keith is “Adactio”. I have no idea what that word means. A quick internet search reveals no hints. Even ChatGPT has no idea.

Screenshot of ChatGPT which says “The word 'adactio' doesn't have a meaning in English or in any widely recognized language. It appears to be a coined term or a username, particularly known in web development and design circles. Jeremy Keith, a well-known web designer and developer, uses 'adactio' as his username on various platforms and his personal website is also named 'adactio.com'. ”

Dave Rupert is davatron5000. I wonder where that comes from? My brain always jumped to thinking it was a Powerman 5000 reference (nostalgic plug for their song from Tony Hawk’s Pro Skater).

What about you? Where did your online handle come from?

I bought my domain jim-nielsen.com because the hyphen-less jimnielsen.com was already taken by some guy who wasn’t using it but didn’t want to sell it to me.

That was when I realized trying to land-grab jimnielsen on every future social site would be a struggle with all the other (imposter) Jim Nielsens in the world.

So I decided a more distinct username for my online accounts was in order.

But what?

patinar15 was my first email username — because I was 15, liked to skateboard, and learned in middle school Spanish class that “patinar” meant “to skate”. But I needed something more…grown up.

When I started my first “real” web design job out of college, a co-worker started calling me "jimmyniels". Then one day, when faced with the “Choose a username prompt” for some website, I thought “jimmyniels, that seems pretty unique…” So I punched that in and voilà: unique!

But then I thought, “Nobody has called me ‘jimmy’ since I was a toddler.” So I thought “Drop the ‘y’. It’s cleaner.”

And thus was jimniels born.

Comment? Reply via: Email, Mastodon, or Twitter.

Other posts that link here: Online Handles: A Round-Up