DEV Community: Ben Newton

How Voice Input Transformed My Solo Development Workflow

Ben Newton — Mon, 04 Aug 2025 03:16:53 +0000

I've been developing software for almost 3 decades, and I've lost count of how many brilliant ideas vanished between conception and keyboard. You know the feeling – that perfect solution hits you in the shower, during a run, or right as you're falling asleep.

Last month, I started dogfooding my own tool – VoiceCommit – to create GitHub issues directly from voice. The results surprised me: I've created 20+ actionable GitHub issues from ideas that would have 100% disappeared within minutes.

Here's the truth: It's not about saving time. It's about saving ideas.

1. The Ideas That Actually Make It To GitHub

The Old Reality:

Have idea while walking → "I'll remember this" → Open laptop 2 hours later → What was that idea again?
Success rate: Maybe 1 in 10 ideas survived

The New Reality:

Have idea → Pull out phone → 30-second voice note → GitHub issue exists
Success rate: 10 out of 10 ideas captured

Last Saturday night at 9:57 PM, I had a flash of inspiration about adding social sharing to VoiceCommit. In bed, no laptop nearby. I grabbed my phone and said:

"I want to add a social piece to VoiceCommit that allows users to share what they said and the PR or Issue that was created. The output should be text for the voice entry and an image of the PR."

By Sunday morning, this detailed GitHub issue was waiting for me. Without voice input, this idea had a 0% chance of survival. I know because I've lost hundreds just like it.

2. Bug Reports With Actual Context (Not "Thing Broken")

We've all been there. You find a bug on mobile, make a mental note, then later create an issue titled "Login redirect issue" with no other context. Future you hates past you.

Here's what I actually captured at 11:00 PM on a Thursday:

"Login page is doing this weird double-redirect thing. User clicks login, goes to auth provider, comes back, then redirects again to dashboard. Feels like we're handling the auth state twice. Need to check the useEffect in AuthProvider component."

The difference isn't time saved – it's context preserved.

Without voice: "Fix login redirect" (useless)

With voice: Full reproduction steps, hypothesis, and where to look

3. Feature Ideas With The "Why" Still Fresh

Here's my favorite example. One simple sentence while walking my dog:

"I have an idea for my blog. I want to add a feature where a progress bar shows across the top of a post's page and as you scroll, the progress bar advances."

Twenty seconds of speaking preserved:

What I wanted (progress bar)
Where it goes (top of page)
How it behaves (advances with scroll)
The context (blog posts specifically)

The magic: I spoke this naturally, including details I wouldn't have remembered to type later. The full context was preserved because I was describing what I was visualizing in that moment.

4. Mobile UX Issues Captured Where They Happen

Testing on your phone, notice something broken, and... what? Switch to laptop? Email yourself?

I caught this at 10:20 PM while browsing on my iPhone:

"The mobile navigation needs a hamburger menu that slides out from the left. Current tabs are too cramped on iPhone SE. Should use CSS transforms for smooth animation, maybe 300ms duration."

This isn't faster than typing on a laptop. But I wasn't at my laptop. This idea would have evaporated by morning. Instead, it became a proper GitHub issue with implementation details.

5. Meta Development: Building The Tool With The Tool

The ultimate dogfooding – I've created 12 VoiceCommit features using VoiceCommit itself:

"Make VoiceCommit a PWA so I can add it to home screen"
"Add pictures to voice commands and have AI analyze them"
"Create a blog post about using VoiceCommit to build VoiceCommit"

Each of these was captured in the moment of inspiration, not reconstructed later from memory.

Let's Talk About "Time Saved"

I'm not saving time. I'm saving ideas.

Traditional time comparison:

Writing a GitHub issue: 5 minutes
Voice recording + AI processing: 1 minute
"Time saved": 4 minutes ❌

The real comparison:

Ideas that make it to GitHub without voice: 10%
Ideas that make it to GitHub with voice: 90%
Ideas saved: 80% ✅

The Data: 14 Days of Voice-First Development

From my actual VoiceCommit database:

20+ voice submissions → 20+ GitHub issues
Capture locations: In bed, walking the dog, shopping, out to dinner (don't tell my wife)
Capture times: 40% after 9 PM, 30% before 9 AM
Average time from idea to issue: 47 seconds

The key insight: 0% of these would exist without voice input. Not because I'm lazy, but because ideas are ephemeral.

Getting Started With Voice Capture

Accept the reality: You will forget that idea in 5 minutes
Make it frictionless: Phone shortcut, PWA, whatever works
Speak naturally: Include context, don't self-edit
Trust the AI: It's better at formatting than your memory is at remembering

Try This For One Week

Don't think about time saved. Think about ideas saved. Every time you have a development thought away from your keyboard, capture it with voice.

After one week, count how many ideas made it to GitHub that normally would have vanished.

That's the real metric.

How many development ideas do you lose each week? Have you found other ways to capture fleeting thoughts? Share your experience in the comments!

P.S. Want to try VoiceCommit? Free tier includes 25 voice submissions/month: voicecommit.com

My Take on the NPM Calling Card

Ben Newton — Thu, 03 Jan 2019 03:46:14 +0000

Originally posted at https://benenewton.com/npm-calling-card/

I've recently noticed a trend among some javascript developers in which they are publishing a simple NPM package that they use to share their contact information. I have seen this in the past but I'm not sure who's I saw first, I believe it may have been Elijah Manor. After reading about it again on this dev.to post by Conlin Durbin,

Setting up a `npx username` card!

Conlin Durbin ・ Dec 26 '18

#beginners #tutorial #javascript #node

I decided to create my own.

Make Your Own

You can view my Repo on GitHub here:

bennewton999 / bennewton

NPM Contact Card

My take on the NPX me contact card.

To run - npx bennewton

To make your own, fork this Repo and update the myData.js, add ascii art to asciiArt.js or leave file empty. When updated, publish to npm as your own new package.

View on GitHub

To make it your own, you can fork it and do as little as update the info in myData.js and package.json then publish as a new NPM module. Or you can go further and customize the text output with chalk, add your own data, etc. I used tagged template literals, so modifying the output is a breeze. You can just add a modifier like {red ${name}} to an output function to change the color and/or font variant.

I also added some ascii art for old times' sake (and because why not??). I originally used image-to-ascii to generate the ascii art from a .png on my website, however an external dependency of GraphicsMagick was required for it to work properly. So I removed it and copied the output to a file. I was unable to keep the color, which stinks. I would like to know how to keep the color referenced in the file, I'm not sure what format and how to output that, so if anybody has any ideas, let me know.

See It In Action

To see it all in action, run the following from your command prompt:

npx bennewton

After a quick, temporary install, the downloaded npm module will display the following in your terminal leaving nothing behind on your drive.

The npx command downloads and runs a NPM module on your machine without installing it permanently. This is perfect for this type of text output module.

What's It For?

Of course, this serves very little purpose, it's just for fun. After reading the artice, it reminded me of Apple II games from the 80s. These games were "cracked" and would have the "pirate's" name on the splash screen along with some BBS phone numbers where you could download other games. Those were the days...

So my thought was why don't we use these as calling cards as signatures for our own modules. We are downloading hundreds if not thousands of modules as developers, most of the time knowing nothing about the author and paying little to no homage to them. A simple post-install script calling the author's own NPM calling card could be the answer to get them the recognition they deserve. I think it would be cool and at least make waiting for NPM installs more entertaining. Just a thought, what do you think?

How To Handle Pesky Modals In Your Puppeteer Tests

Ben Newton — Fri, 03 Aug 2018 03:32:34 +0000

If you've worked on any large e-commerce sites, you've probably run into an iPerception Modal. Every major brand seems to have this survey and it will inevitably pop up right as you are trying to do something important. The good news for most users is you won't ever see it again if you close it. But, for developers, you'll see this modal over and over if you're running visual regression tests or integration tests.

What's the iPerception Modal?

The Problem with the Modal

In my partucular case, I was running integration tests on an ecommerce funnel of a site I'm currently working on. The flow starts at the home page and then clicks through a series of steps to the confirmation page. As I wrote the tests, I would run the test after each additional step to make sure they were passing. While working on step 3, I suddenly began to get test failures on step 2 which had been passing previously.

I set headless to true in the Puppeteer config and watched the tests in the browser. I quickly realized the iPerception modal had began popping up in step 2, blocking my test from clicking the proper CTA to continue the flow, hence the failing test.

Find and Handle the Modal in Puppeteer

I had to check for the modal on each page and close it if I wanted the test to pass and continue to the next step. I was hoping there was simple way for me to set up the modal not to show, after all, this is on my local environment. But in this case, it is a large code base with many agencies working on it and I don't have access to the code that is triggering the modal. So I had to find a way to test for the modal and close it before trying to click the CTA to the next step of the funnel.

I tried to identify the modal by an ID or a class, but they use neither. My guess is this is to avoid ad blockers. I figured out the only selector in the modal I really need to target was the 'NO' CTA. I just had to check for this CTA on the page and if it exists, click it to close the modal. I found since it was an image, I could just use the src attribute as a selector. So now, before each screenshot and click of a CTA, Puppeteer checks for the 'NO' CTA, if it exists, it clicks it and continues with the test. I added this as a helper library as I would have to call it multiple times in multiple tests.

Below is the module I added to my test. I ended up having to call it on every page. The modal is not set for just the home page. In my case, it came up in every page over the course of writing the tests.

// Checks for survey modal and clicks "NO" if it is on page during testing.

const checkForSurvey = async page => {
  const SELECTOR =
    'img[src="https://ips-invite.iperceptions.com/images/templates/Layer/theme1/no_1.png"]';

  if ((await page.$(SELECTOR)) !== null) {
    await page.click(SELECTOR);
  }
};

export default checkForSurvey;

Here is an example of how I used the module above in my tests. I now use this in all my Puppeteer tests for this particular site. Without it, my tests would fail randomly all the time.

import puppeteer from 'puppeteer';
import { toMatchImageSnapshot } from 'jest-image-snapshot';
import config from './config';
import checkForSurvey from './checkForSurvey';

expect.extend({ toMatchImageSnapshot });

let page;
let browser;

beforeAll(async () => {
  browser = await puppeteer.launch({
    args: ['--no-sandbox', '--enable-features=NetworkService', '--ignore-certificate-errors', '--disable-web-security'],
    headless: !config.showBrowser,
    // slowMo: 80,
    ignoreHTTPSErrors: true,
    devtools: config.showDevtools
  });

  page = await browser.newPage();
});

afterAll(async () => {
  await browser.close();
});

describe('Visual Regression Test Home Page', () => {
  test('Home page screenshot should match', async () => {
    await page.setViewport({ width: 1280, height: 800 });
    await page.goto(config.homePageUrl);
    // Check for iPerseption Survey Modal and close if it exists.
    await checkForSurvey(page);
    const screenshot = await page.screenshot();

    expect(screenshot).toMatchImageSnapshot();
  });

  test('Page 2 Page should match screenshot', async () => {
    await page.click('.linkToPage2');
    await page.waitForNavigation();
    // Check for iPerseption Survey Modal and close if it exists.
    await checkForSurvey(page);
    const screenshot = await page.screenshot();

    expect(screenshot).toMatchImageSnapshot();
  });
});

This helper became a necessity for every test I have written so far. If you have something similar that may take over the pages you are trying to write Puppeteer tests for, I hope this helps you. Let me know in the comments if you use this to remove an iPerception modal on your tests. And let me know if you have a different way of handling this.