DEV Community: Devid E

Building a Yes No Wheel: Why Streaks Look Rigged (and 3 Other Gotchas)

Devid E — Thu, 24 Sep 2026 16:15:55 +0000

I added a Yes or No page to my NameWheelPro project. It's vanilla JS with zero dependencies, so every fix below works in any project.

If you're building your own yes no wheel, here are four gotchas I'd want to know about up front.

Streaks are normal, but they look like bugs

Spin a fair 50/50 wheel and sooner or later you'll see Yes, Yes, Yes, Yes, Yes. Users will assume it's rigged. Don't "fix" it by preventing repeats, because that makes the tool less random. Prove it instead:

function longestStreak(results) {
  let best = 1, run = 1;
  for (let i = 1; i < results.length; i++) {
    run = results[i] === results[i - 1] ? run + 1 : 1;
    best = Math.max(best, run);
  }
  return best;
}

const spins = Array.from({ length: 100 }, () => (randomInt(2) ? 'Yes' : 'No'));
console.log(longestStreak(spins)); // usually somewhere between 5 and 8

Run it a few times. Streaks of five or more show up in most 100-spin sessions, and that's what real randomness looks like.

Holding the spacebar spins repeatedly

A keyboard shortcut is easy until someone holds the key down and the browser fires keydown over and over. Ignore repeats and keep a guard for double triggers:

document.addEventListener('keydown', (e) => {
  if (e.code !== 'Space' || e.repeat) return;        // ignore a held-down key
  if (['INPUT', 'TEXTAREA', 'SELECT'].includes(document.activeElement.tagName)) return;
  e.preventDefault();                                // no page scroll
  if (!state.spinning) spin();                       // second trigger becomes a no-op
});

Show a tally so fairness is visible

A History list is good, but a running count is better because it shows the balance at a glance:

function tally(history) {
  return history.reduce((t, h) => {
    const key = h.result.trim().toLowerCase();       // users can edit entries, so normalize
    t[key] = (t[key] || 0) + 1;
    return t;
  }, {});
}

tally(history); // { yes: 12, no: 9 }

A 12-to-9 split looks suspicious until you know that's normal variance. Showing both the streaks and the tally sets the right expectation.

"Clear All" needs an undo

The default wheel is preloaded, so one accidental click on Clear All wipes it. A snapshot and a toast fix that in a few lines:

let undoSnapshot = null;

function clearAll() {
  undoSnapshot = [...state.entries];
  setState({ entries: [] });
  showToast('Wheel cleared', 'Undo', () => setState({ entries: undoSnapshot }));
}

Destructive buttons should always have a way back.

Wrapping up

None of these is hard, but together they make a tiny tool feel trustworthy: honest about randomness, safe with keyboard input, transparent with results, and forgiving of mistakes.

You can try the live yes no wheel here, with no signup. What's a tiny UX detail that made one of your projects feel finished?

Building a Pick a Number Wheel: 4 Gotchas When Numbers Are Your Data

Devid E — Thu, 24 Sep 2026 13:50:46 +0000

I added a random number page to my NameWheelPro project, and numbers turned out to be trickier than names. The whole thing is vanilla JS with zero dependencies, so every fix below works in any project.

If you're building your own pick a number wheel, here are four gotchas worth knowing, with the code.

sort() puts 10 before 2

The default sort is alphabetical, even for numbers:

['1', '10', '2', '20', '3'].sort();
// ["1", "10", "2", "20", "3"], not what anyone wants

localeCompare has a numeric mode that fixes this and still handles text:

const sortEntries = (arr) =>
  [...arr].sort((a, b) =>
    a.localeCompare(b, undefined, { numeric: true, sensitivity: 'base' })
  );

sortEntries(['10', '2', 'Bob', '1']); // ["1", "2", "10", "Bob"]

Let people type ranges

If your tool accepts custom lists, nobody wants to type 1 through 50 one by one. Parsing 1-10, 15, 20-25 takes a few lines:

function parseCustom(text, max = 500) {
  const out = [];
  for (const part of text.split(/[\n,]+/)) {
    const s = part.trim();
    if (!s) continue;

    const m = s.match(/^(\d+)\s*-\s*(\d+)$/);
    if (m) {
      let [a, b] = [Number(m[1]), Number(m[2])];
      if (a > b) [a, b] = [b, a];                       // "10-5" still works
      for (let n = a; n <= b && out.length < max; n++) out.push(String(n));
    } else if (out.length < max) {
      out.push(s);
    }
  }
  return out;
}

The max cap matters. Without it, someone typing 1-99999999 freezes the tab.

Prove the randomness

crypto.getRandomValues is a good source, but random % 100 isn't perfectly uniform because 2³² doesn't divide evenly by 100. The bias is tiny, but rejection sampling removes it:

function randomInt(max) {
  const limit = Math.floor(2 ** 32 / max) * max;   // largest unbiased multiple
  const buf = new Uint32Array(1);
  do { crypto.getRandomValues(buf); } while (buf[0] >= limit);
  return buf[0] % max;
}

Then test it instead of trusting it:

const counts = new Array(100).fill(0);
for (let i = 0; i < 1_000_000; i++) counts[randomInt(100)]++;
console.log(Math.min(...counts), Math.max(...counts));
// both should land roughly between 9,700 and 10,300

If one number wins far more often, you have a bug. It's a 10-second test that builds real confidence.

Tell users when you drop input

Capping entries protects performance, but silently discarding the rest looks like a bug. Return how many were dropped so the UI can say so:

const MAX_ENTRIES = 500;

function addEntries(current, incoming) {
  const room = Math.max(MAX_ENTRIES - current.length, 0);
  const accepted = incoming.slice(0, room);
  return {
    entries: [...current, ...accepted],
    dropped: incoming.length - accepted.length,   // "12 entries were not added"
  };
}

Wrapping up

None of these is hard, but together they make a number tool feel trustworthy: correct sorting, forgiving input, verified fairness, and honest feedback.

You can try the live pick a number wheel here, with no signup. What's the sneakiest "it works on my machine" bug you've hit with numbers?

Building a Color Spin Wheel: 4 Small Fixes That Made It Feel Finished

Devid E — Thu, 24 Sep 2026 10:36:30 +0000

I added a "Wheel of Colors" page to my NameWheelPro project. You add colors, spin, and get a random one. The whole thing is vanilla JS with zero dependencies, so every fix below works in any project.

If you're building your own color spin wheel, here are four small problems worth solving early, with the code.

#F80 and #ff8800 are the same color

Users paste colors in every format, so a plain string comparison misses duplicates. Normalize before you compare:

function normalizeHex(hex) {
  let h = hex.replace('#', '').toLowerCase();
  if (h.length === 3) h = [...h].map((c) => c + c).join(''); // f80 -> ff8800
  return '#' + h;
}

function addColor(list, name, hex) {
  const key = normalizeHex(hex);
  if (list.some((c) => normalizeHex(c.hex) === key)) return list; // already there
  return [...list, { name, hex: key }];
}

Deduping by hex, not by name, also stops "Red" and "Crimson" from being two identical slices.

Share links should stay short

A shareable wheel needs no backend if you put the colors in the URL. The trick is a compact format, so 16 colors don't become a 1,000-character link:

function buildShareUrl(colors) {
  const payload = colors
    .map((c) => `${encodeURIComponent(c.name)}:${c.hex.slice(1)}`)
    .join(',');
  return `${location.origin}${location.pathname}?c=${payload}`;
}

function readShareUrl() {
  const raw = new URLSearchParams(location.search).get('c');
  if (!raw) return null;
  try {
    return raw.split(',').slice(0, 100).map((part) => {
      const [name, hex] = part.split(':');
      return /^[0-9a-f]{6}$/i.test(hex)
        ? { name: decodeURIComponent(name), hex: '#' + hex }
        : null;
    }).filter(Boolean);
  } catch {
    return null; // malformed link, fall back to defaults
  }
}

I use , and : as delimiters because encodeURIComponent always escapes them inside names. The hex check and the slice(0, 100) cap matter too, since data from a URL should never be trusted.

Don't rely on color alone

A color picker has an obvious accessibility trap: the result is only a color. For color-blind users, or anyone using a screen reader, that isn't enough. Always show and announce the name and hex:

function announce(color) {
  const live = document.getElementById('result-live'); // <div aria-live="polite">
  live.textContent = `Result: ${color.name}, ${color.hex}`;
}

The swatch is the fun part, but the text is what makes the result usable for everyone.

History that survives a refresh

The History tab keeps recent results. Capping it and wrapping storage in try/catch keeps it from ever breaking the app:

function saveHistory(history, color) {
  const next = [{ name: color.name, hex: color.hex, at: Date.now() }, ...history].slice(0, 30);
  try {
    localStorage.setItem('colorwheel:history', JSON.stringify(next));
  } catch { /* storage full or blocked: keep working in memory */ }
  return next;
}

Storage can be full, disabled, or blocked in private mode. The wheel should still spin.

Wrapping up

None of these are hard. Together they separate a demo from a tool people trust: normalized data, compact sharing, accessible results, and safe persistence.

You can try the live color spin wheel here, with no signup. What small detail made your last side project feel finished?

Building a Random Name Picker: 4 Small Problems, 4 Small Fixes

Devid E — Thu, 24 Sep 2026 07:03:18 +0000

I recently shipped NameWheelPro, a spinning wheel that picks a winner from a list of names. Building it looked easy, but the small details took most of the time. Things like duplicate entries, unreadable labels, and motion-sensitive users all needed handling.

If you've ever wanted to build your own random name picker, here are four problems I hit and how I solved them, with the code.

Bulk import creates duplicates

Users paste lists from spreadsheets, chat threads, and class rosters. Duplicates and blank lines are guaranteed. Cleaning the input on import keeps the wheel tidy:

function importNames(text, existing) {
  const seen = new Set(existing.map((n) => n.toLowerCase()));
  const fresh = [];

  for (const raw of text.split(/[\n,]+/)) {
    const name = raw.trim();
    if (!name || seen.has(name.toLowerCase())) continue;
    seen.add(name.toLowerCase());
    fresh.push(name);
  }
  return [...existing, ...fresh];
}

A Set gives O(1) lookups, and lowercasing catches "alice" vs "Alice".

Four themes without four codebases

The wheel has four color themes: Rainbow, Pastel, Neon, and Slate. Instead of hardcoding colors in the drawing code, I store each palette as CSS custom properties and let the canvas read them:

:root[data-wheel="rainbow"] { --s1:#e8192c; --s2:#fdc835; --s3:#8cc924; --s4:#1a7fc4; }
:root[data-wheel="neon"]    { --s1:#ff00e5; --s2:#00f0ff; --s3:#39ff14; --s4:#ffea00; }

function getPalette() {
  const css = getComputedStyle(document.documentElement);
  return [1, 2, 3, 4].map((i) => css.getPropertyValue(`--s${i}`).trim());
}

Adding a fifth theme now means adding one CSS block, with no JavaScript changes.

Trust, but verify the winner

After the animation ends, I don't rely on the animation math alone. I derive the winner from the wheel's final angle and check that it matches the intended result:

const TAU = Math.PI * 2;

function indexAtPointer(rotation, count) {
  const arc = TAU / count;
  const angle = ((-rotation % TAU) + TAU) % TAU; // pointer angle relative to wheel
  return Math.floor(angle / arc);
}

If the two ever disagree, I know there's a bug in the animation code. It's a one-line safety net, and it's caught real off-by-one mistakes for me.

Respect reduced-motion settings

A five-second spinning animation is fun for most people, but it can be uncomfortable for others. Browsers expose a media query for this, so I shorten the spin when it's set:

const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
const spinDuration = reduceMotion ? 800 : 5000;

The result is the same and the wheel is just as fair, but the animation is gentler. It took two lines and made the app noticeably more inclusive.

Wrapping up

None of these fixes is complicated, but together they're what separates a demo from something people actually use. If you're building a similar tool, start with data cleaning, theme tokens, a verification check, and accessibility.

You can try the live version at NameWheelPro. I'd love to hear what you'd add. What's the smallest detail that made one of your projects feel finished?

What Should Programmers Do While the AI Writes Code?

Devid E — Wed, 23 Sep 2026 16:29:21 +0000

There's a moment that didn't exist three years ago. You type out a task, hit enter, and then you just sit there. The agent is reading files, thinking, editing things. A little spinner goes around. Maybe it's forty seconds, maybe it's six minutes.

The first few times, I didn't know what to do with my hands.

What I did, for a while, was open Twitter. Then a Slack channel. Then a tab about a mechanical keyboard I had no intention of buying. By the time the AI finished, I'd lost the whole thread of what I asked for, and I'd read its output with the attention of someone reading terms and conditions.

That's the failure mode nobody warns you about. The AI didn't make me slower. It made me shallower, in the gaps. So I've spent the last while trying to figure out what to actually do in those gaps, and this is what I landed on. Some of it works every time, some of it only works on good days.

First, admit the wait is real work time

The mental shift that helped most was to stop treating the waiting as dead time. It isn't a coffee break the tool gave you. You've handed off the typing, but you still own the outcome. If the code is wrong, nobody is going to blame the spinner.

Once I saw it that way, the question changed from "how do I fill the time?" to "what part of the job is still mine while this runs?" And it turns out that's a lot.

Read the plan while it's still a plan

Most agents will tell you what they're about to do, or you can ask them to. That plan is the cheapest place to catch a mistake. If it says it's going to add a new table and you already have one that does the same job, you can stop it right there. Correcting that in a plan takes ten seconds. Correcting it after it's been threaded through eleven files takes an afternoon.

So while it works, I read the plan properly. I don't skim it. I ask myself a few boring questions:

Is it touching files I didn't expect?
Is it adding a dependency when the standard library would do?
Is it solving the problem I described or a slightly bigger, more exciting problem it invented?

That last one happens more than you'd think. These tools love to be helpful in ways you didn't ask for.

Start reviewing before it's done

You don't have to wait for the final diff. Files land one at a time, and you can start reading the early ones. By the time the whole thing finishes, you've already got a feel for the shape of it, and the review at the end is more like a final check than a cold read.

I noticed my reviews got a lot better when I did this. Reading a 600-line diff cold is exhausting and you start approving things just to make it stop. Reading it in pieces as it arrives is much easier on the brain.

And a note on review, since it's now the biggest part of the job: the code looking clean means very little. AI-written code is almost always tidy. Good naming, nice comments, consistent style. That's exactly what makes it dangerous, because tidy code feels correct. I've had to train myself to distrust the polish and go look for the actual logic. Where are the edge cases? What happens on an empty list, a null, a timeout, a user who clicks the button twice?

Write the tests, or at least the test list

This is my favorite thing to do in the gap, and it pays off the most.

While the AI is writing the implementation, I write down what "correct" means. Sometimes that's real test code. Sometimes it's just a rough list in a scratch file:

- empty cart returns 0, not an error
- discount can't push the total below zero
- two identical items merge into one line
- currency rounding: 3 items at 0.333 each

That list does two jobs. First, it forces me to think about the behavior independently of whatever the AI decided to build, so I'm not just anchoring on its version of the problem. Second, when it finishes, I've got a ready-made way to check the work that doesn't depend on trusting it.

If you've ever wondered why tests matter more now, not less, this is why. When you didn't write the code yourself, the tests are how you find out what it actually does.

Use the time to sharpen the next prompt

Vague instructions are the root of most bad AI output. "Add caching to the API" will get you something, and something isn't what you want.

While one task runs, I'll often draft the next one properly. What's the goal? What should it not touch? Which existing pattern in the codebase should it copy? Is there an example file I can point to? Spending three minutes on a tight request saves me from three rounds of "no, not like that."

It's a small habit, but it's basically the new core skill. Describing a problem precisely used to be a nice-to-have. Now it's most of the work.

Do the adjacent stuff nobody wants to do

Every project has a pile of small tasks that never quite get done. The README that's slightly wrong. The ticket that needs a real description. The changelog. The comment in a config file that says "TODO: explain this" from two years ago.

The gaps are the perfect size for these. They don't need deep focus, they don't need a big context switch, and you can drop them the moment the AI finishes. I've cleared out a shocking amount of backlog this way, mostly by accident.

Actually learn something

Here's one I don't see people talk about much. If the AI is using a library or a pattern you don't know well, go read about it while it works.

Open the docs. Skim the source. Figure out why it picked that approach. Otherwise you slowly turn into someone who ships code they can't explain, and that catches up with you at the worst possible time, like 2 a.m. when something is broken and the AI is confidently wrong about why.

I try to make sure that anything I merge, I could explain to a teammate without looking at it again. If I can't, I go and learn it. The gap is a good time for that.

Sometimes, run a second thing (carefully)

Yes, you can run multiple agents on multiple tasks at once. Some people love this. I have mixed feelings.

It works well when the tasks are truly independent, like a bug fix in one service and a small feature in another. It falls apart when you're juggling things that touch the same code, or when you're the bottleneck reviewing everything. There's a point where you're not being productive, you're just being busy, and you're reviewing four diffs at half attention instead of one at full attention.

My rule is roughly: two things at once is fine, three is where quality drops off a cliff. Your review capacity is the real limit, not the AI's speed.

And sometimes, do nothing

I know how that sounds. But I mean it.

Some of my best decisions came from standing up, walking to the window, and letting my brain chew on the problem without a screen. When you're no longer typing all day, there's a strange new risk that you never actually think all day. You're just reacting to output.

Getting up for water, stretching, staring at a wall for a minute. It's not laziness. Deep thinking about design and tradeoffs is what you're being paid for, and it doesn't happen while you're refreshing a feed.

What I try not to do

A short list of things that have burned me:

Approving without reading. The most tempting one, and the most expensive.
Starting a huge Slack thread. You'll come back with no memory of the task.
Stacking so many tasks that I can't review any of them well.
Treating "it runs" as "it's right." Code that runs and code that's correct are different things, and AI is very good at the first one.
Should you still write code by hand?

Yes. Regularly, and on purpose.

I don't say that out of nostalgia. It's the same reason pilots still practice flying manually even though autopilot handles most of it. If you never write anything yourself, your ability to spot a subtle bug or a bad design slowly fades, and that ability is exactly what makes you useful when you're supervising a machine that writes code faster than you ever could.

Pick something small each week and just do it the slow way. Notice how it feels. It keeps the instincts alive.

So, what's the job now?

If I had to boil it down: the AI is fast at producing code, and slow, or bad, at knowing whether that code is the right code. That gap is where we live now.

While it types, we do the parts that need judgment. We check the plan, define what correct means, learn what we don't understand, keep the project healthy, and think about the bigger picture. The typing was never the whole job. It was just the most visible part.

I don't know exactly where all this is heading, and anyone who claims they do is guessing. But for now, the gaps are what you make of them. You can spend them scrolling, or you can spend them getting better at the parts of the work that can't be handed off.

What do you do while the spinner spins? I'm genuinely curious, because I'm sure I'm missing good ideas. Drop them in the comments.