{ "version": "https://jsonfeed.org/version/1", "title": "George Mandis", "description": "This is my blog where I write about web development and travel.", "home_page_url": "https://george.mand.is", "feed_url": "https://george.mand.is/feed.json", "favicon": "https://s3-us-west-2.amazonaws.com/george.mand.is/me-sketch-avatar.jpg", "author": { "name": "George Mandis" }, "items": [ { "id": "https://george.mand.is/2026/05/meet-patui-ms-paint-for-the-terminal-with-vim-controls/", "url": "https://george.mand.is/2026/05/meet-patui-ms-paint-for-the-terminal-with-vim-controls/", "title": "Meet PaTUI: MS Paint for the Terminal, with Vim Controls", "content_html": "

Every once in a while, a revolutionary product comes along that changeseverything. One is very fortunate if they get to work on even one of these intheir career.

Today I'm proud to introduce three revolutionary products of this caliber. Thefirst is a state-of-the-art image editor channeling the elegance of MS Paint.The second is an unparalleled user-interface experience continuing thelong-standing, intuitive traditions of Vim. And the third is software leveragingthe blazingly performant, brilliantly designed programming language that isJavaScript.

So that's three things: an image editor in the class of MS Paint. Anunimaginably intuitive user-interface paradigm rivaling Vim. A software productfinally realizing the raw horsepower and sensible typing decisions ofJavaScript.

MS Paint. Vim. JavaScript.

Are you getting it?

\"The

These are not three separate products. This is one product, and we're callingit PaTUI.

\"The

Welcome to PaTUI

Homage toone of the most iconic product launches of this centuryaside, what is PaTUI?

PaTUI is a terminal-based image editor. Load an image (PNG or JPEG, locally orvia URL), and it renders as colored block characters in your terminal. Thenpaint on it in visual "paint" mode, erase, fill, type text or apply retrofilters. When your masterpiece is complete you can export your work as a JPEG,PNG or ANSI art. In all exports, WYSIWYG.

No, we don't dare impose the dogma of higher-fidelities on your artistic vision.What are we, Photoshop? Please.

This isn't an Arby's Photoshop. This is PaTUI.

"Zoom, Enhance"

Each pixel in the image is represented by block characters wrapped with ANSIescape codes to render colors. We're using "True" color with RGB escape codes(e.g. echo -e "\\e[48;2;255;0;255m \\e[0m") so the vibrance of your originalimage always shines through.

And, because the original image really is kept around in memory, you can use the"zoom and enhance" feature to zero in on as much or little detail as you need.

\"The

What pixels want: Vim-based controls

It has Vim-style modal controls (i for paint mode, hjkl to move, dd todelete a "row" of pixels, yy to yank, u to undo), a 16-color palette you canselect with !@#$%^&*(), an extended CSS-compatible color palette you canaccess with :set color <cornflowerblue|salmon|rebeccapurple,etc>, and commandslike :w mona-lisa.png and :wq.

Now you can draw shapes and touch up pixels with the most intuitive controlsever invented in computing: arbitrary keys with a generous amount of Shiftthrown in.

You can always use :help for a more exhaustive list.

\"The

Vim motions on pixels. 5j moves down 5 rows. dd clears a row. yy yanksit, p pastes. W jumps to the next color boundary. dG deletes from cursorto bottom. If you know Vim, you already know how to navigate. If you don't knowVim, well, you're going to learn!

Retro palette filters. :palette gameboy limits your image to the originalGame Boy's four shades of green. :palette cga gives you the CGA palette.:dither applies Floyd-Steinberg error diffusion dithering. Combine them::palette gameboy then :dither and suddenly your photo looks like it belongson a 1989 handheld.

Find-and-replace for colors. :%s/blue/red/g replaces all blue pixels withred. :%s/~blue/red/g does a fuzzy match -- anything in the blue family. TheVim regex muscle memory just... works here.

Text rasterization. Press t to enter text mode and type charactersdirectly onto the image in the current foreground color. Font size scales withbrush size. It's exactly as janky and charming as it sounds.

Export to ANSI art. :w painting.ans exports your work as ANSI escapecodes. :wc copies the ANSI art to your clipboard. Paste it into a terminal andit renders in color. Paste it into Slack and confuse your coworkers.

Wh...Why? Why the terminal? Why any of this?

There's something satisfying about creative tools that work in environmentsdesigned for text. The terminal gives you a grid of cells, each of which candisplay a colored block character. That's your canvas. Each cell is a pixel. Theconstraints are the point.

It's also just funny. The idea of bringing Vim motions to pixel art, of typing:wq to save a painting, of having a tool sidebar in a terminal -- it's absurdin a way that makes me happy to work on it.

How it works

PaTUI is a Bun app built withInk, which is React for terminal UIs.Image loading and manipulation use sharp.State management is zustand.

The rendering pipeline: load an image with sharp, downscale it to fit theterminal viewport (accounting for the 2:1 aspect ratio of terminal characters),map each pixel to a 256-color ANSI escape code, and render it as a grid of ▀(upper half block) characters. Each character encodes two vertical pixels usingforeground and background colors.

Edits modify the source image buffer. Undo/redo is a stack of image snapshots.Filters (grayscale, palette limiting, dithering) are applied at render time andincluded in exports.

How do you pronounce PaTUI?

It sounds like "patooey," because that's what your images will look like.

Try It

# Homebrew (macOS / Linux)brew install georgemandis/tap/patui# Or from sourcebun install && bun src/index.tsx mona.png

Is it practical? Absolutely not. Is it fun? Easily the most fun 5 minutes you'llprocrastinate with today.

Built during my time at the Recurse Center on alark. View the source and open a PR if you think you can help improve it.

", "date_published": "2026-05-06T00:00:00.000Z" }, { "id": "https://george.mand.is/2026/04/soft-launching-little-irons/", "url": "https://george.mand.is/2026/04/soft-launching-little-irons/", "title": "Soft-launching Little Irons", "content_html": "

I built a tool to help people keep track of their job applications. In an instance of domain-name-driven application development, the project is called Little Irons (littleirons.com)—a tool for helping you keep track of "all your little irons in the fire."

\"The

It's free, it's early, and I would love feedback: https://littleirons.com

The inspiration was an ancient Google Sheet I'd used forever as part of my own job + opportunity explorations. I wanted to see if I could run with this as the base and add nicer features on top inspired by software I enjoy (like Linear) and some thoughtful affordances and "AI flourishes" sprinkled on top, including:

The heart of the tool is a kanban view of all the job applications you have in motion, with the columns aligning to an overall "status" for that particular opportunity. The furthest left column labeled "Exploring" is a place to put any jobs you're interested in applying to. The "Applied" column to the right is, hopefully, self-explanatory. Any columns further to the right are for when you move forward with the process.

\"Little

In my experience there is often enough a distinction between the initial screening and the rest of the interview process that it's worth ratifying these as proper top-level statuses. The interview process itself though can take many forms and even multiple phases, from one-on-one conversations with stakeholders to panel-style interviews. This is where the individual "events" associated with an opportunity come into play.

Click any job to open its detail panel without leaving the board. You get the full picture: status, salary, location, relevant skill tags, and collapsible sections for upcoming events, contacts at the company, the full job description, your notes, and attached documents. The "Next Actions" section surfaces what you need to do next so nothing falls through the cracks.

\"Little

Adding or editing a job happens through a single modal—fill in the basics and expand the Contacts and Events sections to track who you're talking to and what's scheduled. The Job Description tab stores the full posting text for easy reference later.

\"Little

Beyond the board, there are a few other ways to look at your search. The Calendar gives you a monthly overview of your activity—color-coded dots mark application dates, follow-ups, and scheduled events like interviews. Click any date to see what happened that day. You can also generate an iCalendar feed to sync everything into Google Calendar, Outlook, or Apple Calendar.

\"Little

The Stats page turns your job search into numbers. Top-line metrics show total jobs tracked, applications sent, response rate, and offer rate. A pipeline funnel breaks down how many jobs sit at each stage, and an outcomes section tallies your offers, rejections, withdrawals, and ghostings. The activity chart tracks your momentum over the last 30 days—helpful for keeping yourself accountable during a long search.

\"Little

The Timeline presents your job search as a chronological story—every status change appears as an entry on an alternating feed with color-coded dots. It's a useful way to look back and see how active you've been or spot patterns in your pipeline.

\"Little

And for people who prefer spreadsheets, the List view shows everything in a sortable table. Click any column header to sort, filter by status, or select multiple jobs for bulk actions.

\"Little

The UI is admittedly a bit rough around the edges—something I plan on improving as I get more users to test with. Press Cmd/Ctrl+K to open the Linear-inspired command palette to quickly search jobs, jump between views, change statuses, or create new entries without reaching for the mouse.

\"Little

To be clear: this is not intended to be an automated bulk-application tool. It's a simple, focused place to try and organize a real job search.

The site is completely free—all features, including the AI ones—and all you need to join is a GitHub account. If you find it useful and want to support ongoing development, I have a GitHub Sponsors page.

Give it a shot and let me know what you think!

", "date_published": "2026-04-15T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/09/more-dynamic-cronjobs/", "url": "https://george.mand.is/2025/09/more-dynamic-cronjobs/", "title": "More dynamic cronjobs", "content_html": "

I remember learning about cronjobs in the early 2000s. I could tell the computer to go do something, on a recurring basis, forever, even when I wasn't there. They felt like magic!

We didn't have Crontab.guru or AI to ask for figuring out some of the more complex specifications. Just the man pages and good old-fashioned trial and error—mostly error in my case.

But while you could do fun, complex specifications of recurring intervals, you couldn't quite specify something quite as dynamic as "run this script every Tuesday at 7am unless it's the last Tuesday of the month..."

Or at least, you couldn't strictly through the crontab specification syntax. But I had a recent, mildly embarrassing epiphany that it's not hard at all to add arbitrary checks to your crontab to account for more complex and dynamic scenarios.

Want to run a script every Tuesday of the month at 7am except for the last Tuesday? That's easy—set up your crontab to run every Tuesday at 7am, but add a little check to make sure the next week is still part of the same month:

0 7 * * Tue [ "$(date -v+7d '+%m')" = "$(date '+%m')" ] && /path/to/your_command

If it's not part of the same month, that means we're on the last Tuesday for the month and the script won't run.

Note: The -v flag is for the macOS/BSD flavors of date. On Linux you'd want to use -d +7 days instead.

This really has nothing to do with cronjobs at all and everything to do with the POSIX "test" command which is the thing we're using with those square brackets. I'm used to seeing and utilizing them in shell scripts, but for whatever reason I never thought to reach for that tool here in the crontab.

You could just as easily rewrite it like this, skipping the bracket shorthand, which is probably easier to read:

0 7 * * Tue test "$(date -v+7d '+%m')" = "$(date '+%m')" && /path/to/your_command

It never crossed my mind until recently to add slightly more complex checks at the crontab level.

Other clever cronjob things you can do:

Holiday-only cronjobs

Maybe fetch a list of all the US Holidays for a given year and store them in a handy HOLIDAYS.txt file somewhere:

curl -s https://date.nager.at/api/v3/PublicHolidays/2025/US | jq -r '.[].date' > HOLIDAYS.txt

Now you can update your cronjob to run every Tuesday at 7am except on Holidays:

0 7 * * Tue ! grep -qx "$(date +%F)" HOLIDAYS.txt && /path/to/your_command

Or inversely, maybe run a holiday-only script that checks once a day

@daily grep -qx "$(date +%F)" HOLIDAYS.txt && /path/to/your_special_holiday_command

Only run on sunny days

The National Weather Service makes all kinds of fun data available (if you can find it...). How about a script that runs every hour, but only when the weather is clear?

@hourly curl -s "https://api.weather.gov/gridpoints/TOP/32,81/forecast/hourly" | jq -r '.properties.periods[0].shortForecast' | grep -qi clear && /path/to/your_command

Or maybe when the weather is cloudy?

@hourly curl -s "https://api.weather.gov/gridpoints/TOP/32,81/forecast/hourly" | jq -r '.properties.periods[0].shortForecast' | grep -qi cloudy && /path/to/your_command

Only run when there's something newsworthy

Or maybe we get in line with every-other-startup I'm aware of and throw AI at the problem, only running our script when the LLM gods have decided there is something newsworthy:

@hourly curl -s "https://news.google.com/rss?hl=en-US&gl=US&ceid=US:en" | llm --system "Reply strictly 'yes' or 'no'. Does anything in the news today suggest it is a good reason to run a script that I only want to send when the world is on fire and crazy and terrible things are happening?"  | tr -d '[:space:]' | tr '[:upper:]' '[:lower:]' | grep -qx yes && /path/to/oh_no
", "date_published": "2025-09-21T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/07/building-a-go-link-toy-with-deno/", "url": "https://george.mand.is/2025/07/building-a-go-link-toy-with-deno/", "title": "Building a Go Link Toy with Deno", "content_html": "

\"Screenshot

For some reason I've been thinking about go links, which are really just a fancy word for link shorteners. They're useful at larger companies for providing static, easy-to-remember URLs that can take employees directly to pages for benefits explanations, requesting time-off, internal documentation and all sorts of things.

Some companies go the extra mile and make these links available on aesthetically pleasing URLs that only work when you're plugged into the corporate network. Something like:

If you work at a company utilizing go links, there's a chance these links might even work for you! If that last link works, you might want to consider finding a new job.

Projects > Solutions

I wanted a simple personal go link system I could run on my machine, mostly for fun. I decided I wanted to make my own go link implementation just for me, local only to my network and perhaps even just my particular machine.

You might be thinking "Why not just bookmark the links in your browser?" to which I would say "Hey, I'm looking for a Sunday afternoon project, not a solution!"

Other requirements:

If you want to cut to the chase and play with the toy I built, check out the repo:

I also used this as an opportunity to continue exploring Deno. I've been intrigued with it ever since it came on the scene, and I've found it particularly nice for building little one-off CLI toys.

Another fun aspect is you can run the following and install my golinks tool globally:

deno install --global --allow-read --allow-write --allow-env --allow-net --allow-run jsr:@georgemandis/golinks

I published the package on JSR just to get a feel for what's going on over there. Might save that for a different blog post.

Fancy URLs

Half the fun is having those fancy TLD-less URLs. I elaborate a little bit in the README for the repo, but it boils down to adding additional aliases for the loopback address (i.e. localhost) on your machine.

To do that in Unix and MacOS environments all you have to do is add a row to your /etc/hosts file:

echo "127.0.0.1 go" | sudo tee -a /etc/hosts

Note, tee command is just a nice way to write our input to a file and stdout at the same time. It’s not a command I use often, so I thought I’d explain it.

Running the Server

For me, I'm happy to just run it in the background and forget about it:

golinks --server &

I always have my terminal open, so this very lazy solution is Good Enough™ for me. The & runs it as a background process and if I want to stop it I can ps -e | grep "golink" it, find the PID and kill -9 it.

But a few more fun options are available if you want to be less lazy:

Future Considerations

Like any good project, this one has plenty of rabbit holes to fall into. Here are some other ways I could continue to invest in the project:

I don't foresee myself investing more time in this unless I really find it useful or people start contributing to/forking/using it, but it was a fun Sunday afternoon project.

", "date_published": "2025-07-13T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/06/openai-charges-by-the-minute-so-make-the-minutes-shorter/", "url": "https://george.mand.is/2025/06/openai-charges-by-the-minute-so-make-the-minutes-shorter/", "title": "OpenAI Charges by the Minute, So Make the Minutes Shorter", "content_html": "

Want to make OpenAI transcriptions faster and cheaper? Just speed up your audio.

I mean that very literally. Run your audio through ffmpeg at 2x or 3x before transcribing it. You’ll spend fewer tokens and less time waiting with almost no drop in transcription quality.

That’s it!

Here’s a script combining of all my favorite little toys and tricks to get the job. You’ll need yt-dlp, ffmpeg and llm installed.

# Extract the audio from the videoyt-dlp -f 'bestaudio[ext=m4a]' --extract-audio --audio-format m4a -o 'video-audio.m4a' "https://www.youtube.com/watch?v=LCEmiRjPEtQ" -k;# Create a low-bitrate MP3 version at 3x speedffmpeg -i "video-audio.m4a" -filter:a "atempo=3.0" -ac 1 -b:a 64k video-audio-3x.mp3;# Send it along to OpenAI for a transcriptioncurl --request POST \\  --url https://api.openai.com/v1/audio/transcriptions \\  --header "Authorization: Bearer $OPENAI_API_KEY" \\  --header 'Content-Type: multipart/form-data' \\  --form file=@video-audio-3x.mp3 \\  --form model=gpt-4o-transcribe > video-transcript.txt;# Get a nice little summarycat video-transcript.txt | llm --system "Summarize the main points of this talk."

I just saved you time by jumping straight to the point, but read-on if you want more of a story about how I accidentally discovered this while trying to summarize a 40-minute talk from Andrej Karpathy.

Also read-on if you’re wondering why I didn’t just use the built-in auto-transcription that YouTube provides, though the short answer there is easy: I’m sort of a doofus and thought—incorrectly—it wasn’t available. So I did things the hard way.

I Just Wanted the TL;DW(atch)

A former colleague of mine sent me this talk from Andrej Karpathy about how AI is changing software. I wasn’t familiar with Andrej, but saw he’d worked at Tesla. That coupled with the talk being part of a Y Combinator series and 40 minutes made me think “Ugh. Do I… really want to watch this? Another 'AI is changing everything' talk from the usual suspects, to the usual crowds?”

If ever there were a use-case for dumping something into an LLM to get the gist of it and walk away, this felt like it. I respected the person who sent it to me though and wanted to do the noble thing: use AI to summarize the thing for me, blindly trust it and engage with the person pretending I had watched it.

My first instinct was to pipe the transcript into an LLM and get the gist of it. This script is the one I would previously reach for to pull the auto-generated transcripts from YouTube:

yt-dlp --all-subs --skip-download \\  --sub-format ttml/vtt/best \\  [url]

For some reason though, no subtitles were downloaded. I kept running into an error!

Later, after some head-scratching and rereading the documentation, I realized my version (2025.04.03) was outdated.

Long story short: Updating to the latest version (2025.06.09) fixed it, but for some reason I did not try this before going down a totally different rabbit hole. I guess I got this little write-up and exploration out of it though.

If you care more about summarizing transcripts and less about the vagaries of audio-transcriptions and tokens, this is the correct answer and your off-ramp.

My Transcription Workflow

I already had an old, home-brewed script that would extract the audio from any video URL, pipe it through whisper locally and dump the transcription in a text file.

That worked, but I was on dwindling battery power in a coffee shop. Not ideal for longer, local inference, mighty as my M3 MacBook Air still feels to me. I figured I would try offloading it to OpenAI’s API instead. Surely that would be faster?

Testing OpenAI’s Transcription Tools

Okay, using the whisper-1 model it’s still pretty slow, but it gets the job done. Had I opted for the model I knew and moved on, the story might end here.

However, out of curiosity, I went straight for the newer gpt-4o-transcribe model first. It’s built to handle multimodal inputs and promises faster responses.

I quickly hit another roadblock: there’s a 25-minute audio limit and my audio was nearly 40 minutes long.

Let's Try Something Obvious

At first I thought about trimming the audio to fit somehow, but there wasn’t an obvious 14 minutes to cut. Trimming the beginning and end would give me a minute or so at most.

An interesting, weird idea I thought about for a second but never tried was cutting a chunk or two out of the middle. Maybe I would somehow still have enough info for a relevant summary?

Then it crossed my mind—what if I just sped up the audio before sending it over? People listen to podcasts at accelerated 1-2x speeds all the time.

So I wrote a quick script:

ffmpeg -i video-audio.m4a -filter:a "atempo=2.0" -ac 1 -b:a 64k video-audio-2x.mp3

Ta-da! Now I had something closer to a 20 minute file to send to OpenAI.

I uploaded it and… it worked like a charm! Behold the summary bestowed upon me that gave me enough confidence to reply to my colleague as though I had watched it.

But there was something... interesting here. Did I just stumble across a sort of obvious, straightforward hack? Is everyone in the audio-transcription business already doing this and am I just haphazardly bumbling into their secrets?

I had to dig deeper.

Why This Works: Our Brains Forgive, and So Does AI

There’s an interesting parallel here in my mind with optimizing images. Traditionally you have lossy and lossless file formats. A lossy file-format kind of gives away the game in its description—the further you crunch and compact the bytes the more fidelity you’re going to lose. It works because the human brain just isn’t likely to pick-up on the artifacts and imperfection

But even with a “lossless” file format there are tricks you can lean into that rely on the limits of human perception. One of the primary ways you can do that with a PNG or GIF is reducing the number of unique colors in the palette. You’d be surprised by how often a palette of 64 colors or fewer might actually be enough and perceived as significantly more.

There’s also a parallel in my head between this and the brain’s ability to still comprehend text with spelling mistakes, dropped words and other errors, i.e. transposed letter effects. Our brains have a knack for filling in the gaps, and when you go looking through the world with magnifying glass you'll start to notice lots of them.

Speeding up the audio starts to drop the more subtle sounds and occasionally shorter words from the audio, but it doesn’t seem to hurt my ability to comprehend what I’m hearing—even if I do have to focus. These audio transcription models seem to be pretty good at this as well.

Wait—how far can I push this? Does It Actually Save Money?

Turns out yes. OpenAI charges for transcription based on audio tokens, which scale with the duration of the input. Faster audio = fewer seconds = fewer tokens.

Here are some rounded numbers based on the 40-minute audio file breaking down the audio input and text output token costs:

SpeedDuration (seconds)Audio Input TokensInput Token CostOutput Token Cost
1x (original)2,372NA (too long)NANA
2x1,18611,856$0.07$0.02
3x7917,904$0.04$0.02

That’s a solid 33% price reduction on input tokens at 3x! However the bulk of your costs for these transcription models are still going to be the output tokens. Those are priced at $10 per 1M tokens whereas audio input tokens are priced at $6 per 1M token as of the time of this writing.

Also interesting to note—my output tokens for the 2x and 3x versions were exactly the same: 2,048. This kind of makes sense, I think? To the extent the output tokens are a reflection of that model's ability to understand and summarize the input, my takeaway is a “summarized” (i.e. reduced-token) version of the same audio yields the same amount of comprehensibility.

This is also probably a reflection of the 4,096 token ceiling on transcriptions generally when using the gpt-4o-transcription model. I suspect half the context window is reserved for the output tokens and this is basically reflecting our request using it up in its entirety. I suspect we might get diminishing results with longer transcriptions.

But back to money.

So the back-of-the-envelope calculator for a single transcription looks something like this:

6 * (audio_input_tokens / 1_000_000) + 10 * (text_output_tokens / 1_000_000);

That does not quite seem to jibe with the estimated cost of $0.006 per minute stated on the pricing page, at least for the 2x speed. That version (19-20 minutes) seemed to cost about $0.09 whereas the 3x version (13 minutes) cost about $0.07 (pretty accurate actually), if I’m adding up the tokens correctly.

# Pricing for 2x speed6 * (11_856 / 1_000_000) + 10 * (2_048 / 1_000_000) = 0.09# Pricing for 3x speed6 * (7_904 / 1_000_000) + 10 * (2_048 / 1_000_000) = 0.07

It would seem that estimate isn’t just based on the length of the audio but also some assumptions around how many tokens per minute are going to be generated from a normal speaking cadence.

That’s… kind of fascinating! I wonder how John Moschitta’s feels about this.

Comparing these costs to whisper-1 is easy because the pricing table more confidently advertises the cost—not “estimated” cost—as a flat $0.006 per minute. I’m assuming that’s minute of audio processed, not minute of inference.

The gpt-4o-transcription model actually compares pretty favorably.

SpeedDurationCost
1x2372$0.24
2x1186 seconds$0.12
3x791 seconds$0.08

Does This Save Money?

In short, yes! It’s not particularly rigorous, but it seems like we reduced the cost of transcribing our 40-minute audio file by 23% from $0.09 to $0.07 simply by speeding up the audio.

If we could compare to a 1x version of the audio file trimmed to the 25-minute limit, I bet we could paint an even more impressive picture of cost reduction. We kind of can with the whisper-1 chart. You could make the case this technique reduced costs by 67%!

Is It Accurate?

I don’t know—I didn’t watch it, lol. That was the whole point. And if that answer makes you uncomfortable, buckle-up for this future we're hurtling toward. Boy, howdy.

More helpfully, I didn’t compare word-for-word, but spot checks on the 2x and 3x versions looked solid. 4x speed was too fast—the transcription started getting hilariously weird. So, 2x and 3x seem to be the sweet spot between efficiency and fidelity, though it will obviously depend on how fast the people are speaking in the first place.

Why Not 4x?

When I pushed it to 4x the results became comically unusable.

\"Output

That sure didn't stop my call to summarize from trying though.

Hey, not the worst talk I've been to!

In Summary

Always, in short, to save time and money, consider doubling or tripling the speed of the audio you want to transcribe. The trade-off is, as always, fidelity, but it’s not an insignificant savings.

Simple, fast, and surprisingly effective.

TL;DR

If you find problems with my math, have questions, found a more rigorous study qualitatively comparing different output speeds please get in touch! Or if you thought this was so cool you want to hire me for something fun...

", "date_published": "2025-06-24T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/06/what-it-takes-to-be-a-good-engineering-manager/", "url": "https://george.mand.is/2025/06/what-it-takes-to-be-a-good-engineering-manager/", "title": "What It Takes to Be a Good Engineering Manager", "content_html": "

There is no shortage of opinions on this topic. The most honest answer is probably “it depends” but that’s also the least helpful.

After 4.5 years leading multiple engineering teams, here’s my single-sentence answer to what makes a great manager:

A good manager balances high empathy with high expectations and knows when to pull which lever.

High expectations without empathy might “succeed” but at the cost of toxicity. It’s not my definition of success or something I want to be part of.

High empathy without expectations can leave a team adrift. It comes at the cost of growth, learning and output.

In interviewing for new engineering leadership positions I’ve found this line lands very well when trying to describe my own engineering leadership philosophies and values. I like to think this is because I really mean it. This isn’t a pithy mantra I picked up in an engineering management book—it’s a core tenet I’ve seen, felt, and lived.

I've been in situations where I could see I was pushing people too hard and needed to back-off without making them feel like they've failed. There have also been situations where I knew people could do more and found ways to gracefully challenge them. It's all part of navigating the tricky calculus of people, projects and priorities.

What you’re really calibrating for is the right amount of tension. It looks different for each individual, and each person's tension has to be balanced with the team as a whole. Think of it like a musical instrument with strings. There’s an appropriate amount of tension to achieve the desired frequency for each string and there’s an overall amount that the instrument itself can withstand.

I’m a firm believer in the Recurse Center's self-directives. They've been a significant part of my "high expectations" for people on the various teams I managed. They're a beautiful set of principles to build any community around.

This approach engenders a culture that tends to attract and keep curious, life-long learners. People who holistically care about their work and how it fits into the whole. On its best days it feels like a fun class everyone has elected to take.

There’s no substitute for giving a shit—about every person, the team, and the work we do together.

❧ If you care as much about people as outcomes and you’re looking for an engineering leader who’ll pull the right levers, let’s chat.

", "date_published": "2025-06-19T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/06/exploring-phonics-with-openai/", "url": "https://george.mand.is/2025/06/exploring-phonics-with-openai/", "title": "Exploring phonics with OpenAI", "content_html": "

As a child of the 80s and 90s, I have the vaguest memory of Hooked on Phonics commercials on television. More specifically their catchphrase "hooked on phonics worked for me!" Reconciling this message in the D.A.R.E era felt like mixed-messaging. Do you or don't you want me hooked on things?

Today I was reminded of this musical sign-off—for Hooked on Phonics, not D.A.R.E—after an introductory conversation with an ed-tech organization for an engineering leadership position. They described the product and platform and how it teaches kids to read. "Oh, I'm old enough to remember phonics being a thing that was pushed in schools," I said.

It turns out old ideas never stray far.

An interesting thing that came out of that conversation was noting that the text-to-speech models don't do a great job with the phonetic sounds.

This makes some sense to me. I imagine the way the models are built, they're going to do a better job of producing entire words. Phonemes—distinct units of sound that make up a word—probably don't map well to tokens, even if tokens themselves can map to parts of words.

This isn't a researched take—it's just my intuition at the moment.

\"Screenshot

I'll have to dig deeper if I stay curious, but if the TTS models are using tokens in a way similar to how LLMs do, I could see how they would map more cleanly to words and partial words than the distinct sounds that necessarily comprise them.

After the call I immediately thought of a way to leverage AI shenanigans to try and prototype a phoneme-to-audio pipeline using OpenAI’s APIs:

I hacked together a quick demo to test this out. Behold, my mediocre exploration of phonics via OpenAI:

You can view the source code for my phoneme explorer here on GitHub:

The actual structured output of phonemes, to my extremely untrained eye, didn't seem that bad! It seemed to map to the way words were presented in various Wikipedia articles as I compared them. That's an extremely unrigorous test, but it surpassed my expectations.

The audio however met my expectations, which is to say it was fairly... mediocre. It handled my name with aplomb, which seemed promising at first. A relatively simple but multi-syllabic word like "continental" was a borderline disaster.

Still, it’s a fun proof of concept—and enough to make me curious about what better phoneme-focused datasets or synthesis models might look like.

If I want to keep exploring this idea I think the next step might be to look for a more canonical reference set of audio samples out there that map to the IPA. Cursory searching didn't lend itself to an obvious source, but I’d be surprised if something like that isn’t out there already.

", "date_published": "2025-06-12T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/06/future-proofing-my-blog-for-an-ai-audience/", "url": "https://george.mand.is/2025/06/future-proofing-my-blog-for-an-ai-audience/", "title": "Future-proofing my blog for an AI audience", "content_html": "

There is nothing more meta than blogging about your blog, but I had to start somewhere after a six-month hiatus.

Let's cut to the chase. I've been thinking a lot about LLMs and llmstxt.org in particular. Although LLMs are pretty darn good at reading HTML and parsing meaning between the brackets, it still seems to do best when the source is as close to plain-text as possible.

So I made a few changes to facilitate this and make the plain-text versions more discoverable:

It all makes sense to me. What's good for us tends to be good for the machines: legible systems, up-to-date documentation, well organized projects, etc. I have a whole separate article in the back of my brain about trying to understand why an industry is so eager to treating machines better than we treat ourselves. These same tools and affordances make people more productive too, but for some reason investing time in them for the benefit of people—not machines—always seems to be a harder sell.

My favorite little trick was this Nunjuck loop to match the length of the title for a given post with enough "=" characters to visually underline it:

{{ post.data.title }}{% for i in range(0, post.data.title | length) -%}={% endfor %}

So the end result for the plain-text version looks like this:

Future-proofing my blog for an AI audience==========================================

Silly, little things that make me happy.

You might be asking why is there plain-text version and a Markdown version when the plain-text version looks like... Markdown.

That... is a great question. I kind of improvised this evening and will probably go back to the drawing board on this concept. The Markdown files as they are currently served are literally how my posts are stored in the repo. The plain-text versions are formatted a little bit differently (i.e no frontmatter).

On a different note, my professional obligations have recently changed and I have some free-time on my hands. I want to write about that and reflect on all the things I've learned, but mostly I want to use this time to rebuild the discipline of writing more. Technology, travel stories, creative explorations, opinions and even metacommentary about how I've constructed this blog.

", "date_published": "2025-06-11T00:00:00.000Z" }, { "id": "https://george.mand.is/2025/06/agi-elevators-and-other-thoughts-i-didnt-mean-to-publish/", "url": "https://george.mand.is/2025/06/agi-elevators-and-other-thoughts-i-didnt-mean-to-publish/", "title": "AGI, elevators, and other thoughts I didn’t mean to publish", "content_html": "

Note: I accidentally published this before it was ready! I decided to tweak the typos, remove a couple terrible fragments and otherwise leave it as-is.

Ideas have always been cheap; it's the execution that's the multiplier. In the AI world we're hurtling toward, which is driving down the cost of execution, I guess that means ideas are more devalued than ever?

Cheaper still than an idea is an observation. It's the Xerox of an idea run through a filter—artifacts and fidelity sometimes lost, but perhaps a bit of unique character introduced.

Everyone seems to have their own AI thoughts these days. Fresh off 4.5 years leading engineering efforts around a SaaS product through the birth of this LLM era we're all living in now, I thought I'd offer a scattershot collection of my own half-baked ones:

Abstractions on Abstractions

Computing is the history of abstractions. We've gone from punching holes in cards to perform calculations to talking to pocket devices in our mother tongue, asking what the weather will be—all in less than a century.

The advent of computer languages to create instructions led to software as we know it. From peeking and poking at individual memory addresses to writing scripts that imitate language to (now, with LLMs) literally using language as we're hard-wired to learn it from birth—conversing with machines.

What happens when the next "hello world" program is just: "ask the computer to write a hello world program"? Sure, behind the scenes it may literally write an entire operating system from scratch in some virtualized container, all in service of simply spitting out the words Hello World—but it doesn't matter.

I think there's an inevitable discomfort living through this kind of progress. You see what's lost. You see the depths of understanding falling short of your own. But there's progress on the other side of that that will outweigh anything lost. Feelings that end up bordering on nostalgia cannot slow this train.

And that's okay.

Probabilistic Elevators

At some point the interface to everything becomes a machine you talk to. In the same way microcontrollers have found their way into all manner of things. They're fast, cheap, and out of control. Wait until we have highly capable LLMs on chips. In that world, why create a unique electronic component for a button when you can manufacture a magical component that you kindly ask to behave like a button? Shrunken to microscopic sizes, how close does this start to resemble magical nanotechnologies capable of anything?

Imagine a grid of elevator buttons, floors 1–10. Each programmed with a simple prompt: "Send the elevator to floor X."

Now, if you're thinking about the probabilistic nature of elevators, you might be thinking: "That is insane. I would like a deterministic elevator, please."

But the truth is: if it's cheaper and easier, it will win.

And the other truth is: we're already living in a probabilistic world. This future is simply embracing it.

Also, Probabilistic Elevators would be a great band name. Please steal it.

AGI

The psychology of AGI, SGI, and trusting our robot overlords fascinates me. Science fiction has always been aspirational, but you have to remember that it's ultimately fiction. Real life always lands differently.

You achieve AGI when you're willing to trust the machine blindly. I think that's a product of comfort over time more than capability. At the end of the day, it's a marketing term for a highly capable version of this tool that hasn't quite landed yet. But I can squint and see it. We're talking about tools, not machines with will. We always have been.

It says more about us when we decide to feel comfortable making that leap than about the capabilities of the thing. I have a personal feeling that AGI is also only perceivable to the extent you've given the brain-in-a-jar tools to act on its scattered thoughts. I can't really conceive or understand an intelligence in the abstract, independent of tools that help me recognize that level of cognizance—writing, speaking, actions.

There’s a whole era of study dedicated to pretty much the opposite of my intuition that goes back to the 1950s called symbolic AI. I trust those people are much smarter than me—that my intuition is missing the point and that there’s something there—but I do suspect my ability to relate to this kind of intelligence is diminished absent relatable tools. A brain-in-a-jar absent the tool of language to talk to me is just a brain-in-a-jar, no matter what's going on in there. It feels more like philosophy than engineering something in the real world. At least today.

It’s like anthropomorphizing Excel or a bash script, to some extent. Or maybe asking Deep Blue or Watson to operate a forklift.

Anyway, debating AGI strikes me as a distraction. A fun distraction, but not a particularly useful one beyond feeding the marketing hype. Discussing the inevitable capabilities of these tools—and the agency we might feel comfortable granting them—is not.

AGI happens when you're ready.

", "date_published": "2025-06-07T00:00:00.000Z" }, { "id": "https://george.mand.is/2024/12/kagi-orion-and-gopher/", "url": "https://george.mand.is/2024/12/kagi-orion-and-gopher/", "title": "Kagi, Orion and Gopher", "content_html": "

The last week of the year is a time for rest and reflection. During that downtime, I decided to try Kagi and Orion and spent more time than I should have setting up a Gopher site, just for kicks.

Kagi & Orion

Kagi is a paid search engine and Orion is a privacy-minded browser they built on Webkit—not Blink!—exclusively for macOS, at least for now.

Everything about those choices sounds like someone actively whittling down their market share to something so small and specific most VCs would scoff. But somehow, they seem to have cobbled together a surprisingly robust business?

I listened to Vlad Prelovac (the founder) talk about the history of the company, their design choices and a lot of other things on The Talk Show (the companion podcast to Daring Fireball):

There's something charming and inspiring about this product's success. So, for the first time in well over a decade, I decided to open my mind to the idea of ditching Google and Chrome and trying something new.

The old adage of "If you're not paying for the product then the product is you" was a great quip in the early 2000s when I first heard it, and almost everything about the way the internet has evolved since then reinforces it for me. It's refreshing to try to consciously take a step out of that world and see what else is out there.

It's only been a week, but so far... I might really like it? I love the clever twists like how adding a question mark at the end of your search query invokes their AI assistant, which is kind of like how Google's AI suggestions appear above the search results. There are no ads, of course.

There are thoughtful filters you can toggle if you want to move from searching the entirety of "the web" to just segments of their index—a mixture of topics like Programming or Recipes or sources like PDF or Fediverse Forums. It's thoughtful and clever, and their endearingly branded "Small Web" portal gives me nostalgic StumbleUpon vibes.

I'm actually somewhat more enamored with Orion than Kagi at the moment. It's fast, the memory footprint is low, all the built-in anti-tracking and blocking features are baked in. They've put a lot of time into supporting any and all Chrome Extensions as well as they can, which is pretty wild.

All-in-all, similar to Kagi, there are just lots of little thoughtful touches sprinkled all over the app. It's fine as a "set it and forget it" kind of browser, but also has lots of power-user features that are easy to find. For example, I switched my user agent to Safari iPhone to trick the wifi portal on the plane to think it's my phone so I could take advantage of the free wifi my T-Mobile plan gets me. Can you do that on other browsers? Yeah, but even with Chrome and Safari I have to go through at least one more click to make it happen. This was evident and elegant out of the box.

Gopher

Apropos of nothing, I decided to setup a Gopher site:

If you don't have a browser that knows what to do with that link (Orion will not help you here) I'd recommend Lagrange, Gophie or Bombadillo if you're more of a TUI person.

The saga of how I setup that site I will leave for a future post.

Happy New Year to anyone reading! May the good things be more and the harder things easier for you all in 2025.

", "date_published": "2024-12-31T00:00:00.000Z" } ] }