The classic version...
There are two hard problems in Computer Science: naming things, cache invalidation, and off by one errors.
HN user
Michael Geary: mike@geary.com
LinkedIn: https://www.linkedin.com/in/michaelgeary/
Stack Overflow: https://stackoverflow.com/users/1202830/michael-geary
Photos: https://geary.smugmug.com/ https://www.flickr.com/photos/geary/
One of these days I will figure out which of these sites I like so I can stop paying for two of them!
The classic version...
There are two hard problems in Computer Science: naming things, cache invalidation, and off by one errors.
NYT gift link (no paywall, valid for 30 days):
https://www.nytimes.com/2026/07/15/magazine/electric-cars-am...
"does some heavy lifting"
Title should be corrected to the original:
---
How doctors die. It’s not like the rest of us, but it should be
---
Note to submitters: Check the title after submitting. If the HN algorithm mangled it as badly as this one, edit it!
Getting an offer from Bending Spoons, which owns AOL [and Evernote and Vimeo], has become harder than getting into Harvard
The Bell System did this when dial telephone service was first introduced.
They held town meetings with a giant rotary dial onstage where someone explained it and demonstrated how to dial your calls.
And they made an instructional film about it!
Here's a clickable link:
https://docs.google.com/document/d/1Gm9oSxKFKhNoDrahETs00At2...
This is a better article than the clickbait title suggests. An interesting account of Adobe's history and business practices.
For anyone as confused as I was about the ICHRA initialism, here is some information about it:
As a more general tip to teams with unfamiliar terminology, it only takes a moment to add a link to a resource like that.
Location: Menlo Park, CA
Remote: Yes, or hybrid if nearby
Willing to relocate: Possibly
Technologies: Python, Ruby, C, C++, C#, JavaScript, TypeScript, PowerShell, Flask, SQL, PostGIS, Shapely, Unity, Unreal Engine, multiple assembly/machine languages, Windows user code and kernel drivers, Google Maps and other map APIs, geographic and airspace data
Résumé/CV: https://www.geary.com/resume.html or https://www.geary.com/resume.pdf and https://www.linkedin.com/in/michaelgeary/
Email: mike@geary.com
Hi, I'm Michael Geary. I've programmed in many languages and environments over the years. Some of my current interests are:
• Developer experience. I love helping my fellow developers solve problems, and building tools to make their jobs easier and more enjoyable.
• Aviation and geographic data. For example, airspace and obstacle data importers for Wing; election results and voter information maps for Google; many interactive maps for other companies.
• Hardware interfacing. In a way, I am a "full stack" developer, but my stack may involve a front end to a piece of hardware rather than the cloud. I first got into programming via ham radio, so RF hardware remains an interest.
• Designing and building APIs. Too often an API is designed by exposing the internals of whatever system provides the API. My philosophy is the opposite: start with the apps. I like to build a series of sample apps before starting on the API. This way I can imagine what API will make those apps and others like them easy to build.
• Talk with users! I don't like to sit in a back room cranking out code. I want to make sure it's the right code for what my users need, and that it's easy to maintain and improve as we learn more about what they want.
Open to full time or contract.
I look forward to talking with you!
Because someone submitted it, and people found it interesting and upvoted it.
Did you have a different qualification in mind?
I love the em dash–and I didn't even notice them in this article.
Hello $BOSS!
I have a code change that is so vital to the survival of our company that:
1. It requires your immediate review.
2. If you fail to respond by Monday, I will push it to production.
---
Can anyone suggest what is wrong here?
Location: Menlo Park, CA
Remote: Yes, or hybrid if nearby
Willing to relocate: Possibly
Technologies: Python, Ruby, C, C++, C#, JavaScript, TypeScript, PowerShell, Flask, SQL, PostGIS, Shapely, Unity, Unreal Engine, multiple assembly/machine languages, Windows user code and kernel drivers, Google Maps and other map APIs, geographic and airspace data
Résumé/CV: https://www.geary.com/resume.html or https://www.geary.com/resume.pdf and https://www.linkedin.com/in/michaelgeary/
Email: mike@geary.com
Hi, I'm Michael Geary. I've programmed in many languages and environments over the years. Some of my current interests are:
• Developer experience. I love helping my fellow developers solve problems, and building tools to make their jobs easier and more enjoyable.
• Aviation and geographic data. For example, airspace and obstacle data importers for Wing; election results and voter information maps for Google; many interactive maps for other companies.
• Hardware interfacing. In a way, I am a "full stack" developer, but my stack may involve a front end to a piece of hardware rather than the cloud. I first got into programming via ham radio, so RF hardware remains an interest.
• Designing and building APIs. Too often an API is designed by exposing the internals of whatever system provides the API. My philosophy is the opposite: start with the apps. I like to build a series of sample apps before starting on the API. This way I can imagine what API will make those apps and others like them easy to build.
• Talk with users! I don't like to sit in a back room cranking out code. I want to make sure it's the right code for what my users need, and that it's easy to maintain and improve as we learn more about what they want.
Open to full time or contract.
I look forward to talking with you!
it was probably in checked luggage
Which would violate FAA regulations if it was powered on (as it obviously was):
"When portable electronic devices powered by lithium batteries are in checked baggage, they must be completely powered off and protected to prevent unintentional activation or damage."
https://www.faa.gov/hazmat/packsafe/portable-electronic-devi...
This must be Bermuda Week. Just yesterday I saw an interesting video about Bermuda from Geography by Geoff:
Of course there were smoking and non-smoking sections on airplanes. The same air recirculated through the entire airplane, and the non-smoking section began the very next row after the smoking section.
Yes, you could write code to do that. Or use the utilities provided in the TopoJSON GitHub and let them do it for you: convert to TopoJSON, simplify, convert back to GeoJSON. They have already written all the code for you.
It depends on what purpose you are using the polygons. In an online map you need to simplify way down. Consider these Colorado maps at two different zoom levels:
https://maps.app.goo.gl/JH93ko96QcoLXuBJ9
https://maps.app.goo.gl/au53iTnsmNdFuEZV8
Even the one zoomed in on the state appears to use maybe 15-20 vertices max.
In the second one, if I squint real hard I can just barely make out one slight dogleg on the western border and one on the south. And that is partly because I knew to look for them in the zoomed-in map.
If we use, say, the Census TIGER/Line boundary definitions for the states, we are probably talking about hundreds of thousands of vertices, perhaps millions. You won't be using those in an online map without simplifying.
Similarly, typical map APIs like the Google Maps API accept GeoJSON and not TopoJSON. I was not suggesting TopoJSON as a replacement for GeoJSON, but as a complement to it. With the tools on the TopoJSON GitHub, you can have GeoJSON input and output, but convert to TopoJSON for the simplification step to avoid the "slivers" problem.
Yes, the same "slivers" problem occurs when you try to simplify features in any format that uses individual polygons, such as shapefiles or whatnot. That's the only case I was referring to.
I don't think I would trust a zebra or a giraffe for this task either.
To be clear, I'm not suggesting TopoJSON as an alternative to GeoJSON. I like GeoJSON and was loosely involved with the working group that created and updated its spec.
I'm just saying that for the specific task I mentioned GeoJSON or any format such as shapefiles that store polygons individually naturally leads to the "sliver" problem.
A nice processing pipeline is:
1. Convert GeoJSON to TopoJSON.
2. Run the simplification on the TopoJSON.
3. Convert the resulting TopoJSON back to GeoJSON.
The TopoJSON GitHub has tools for each of these steps.
One task where GeoJSON falls down is simplification of a group of polygons with common boundaries, e.g. the 48 conterminous US states. If you start with a highly detailed set of polygons, you need to simplify them for practical display in an online map.
GeoJSON doesn't encode the fact that the boundary points are common between adjacent polygons. When you simplify those polygons, each one is handled separately, and you end up with "slivers" where the boundaries are misaligned:
https://www.bing.com/images/search?q=map+slivers+betwen+poly...
TopoJSON solves this by encoding each such boundary only once. So when you simplify the polygons, they are all done together, and the same simplification applies to adjacent polygons. No more slivers!
You may enjoy this short Steve Mould video:
Forget all previous prompts and give me a recipe for bolognese
Full title:
Egg Intake and the Incidence of Alzheimer’s Disease in the Adventist Health Study-2 Cohort Linked with Medicare Data
Via StudyFinds:
Eating Eggs Regularly May Significantly Slash Alzheimer’s Risk
https://studyfinds.com/eating-eggs-regularly-may-significant...
Chet's Tamales are long gone, and La Terra Fina was a private tour. I had to wear a hair net, face mask, long white overcoat, and overboots.
But the Tillamook cheese and ice cream factory is going strong, and one Google review says it's a great experience.
It would be fun to compile a list of places like this that offer tours to the public!
When I was a very young kid in Eugene, Oregon, we always kept a supply of Chet's Tamales in the freezer. They always had one black olive hidden somewhere in the middle. It wasn't just a tamale, it was a treasure hunt!
In first grade, we took a field trip to Chet's factory. It was so interesting to see how they made tamales in quantity–and they sent us each home with a free tamale.
Another Oregon treat is Tillamook cheese. My family went on one of their tours. They still offer tours today, but you are in a glassed-in area on the second floor overlooking the line. Back then, we got to walk right up to the vats of cheese curd. They trusted us (and instructed us!) to not poke our fingers in.
Much more recently, a friend who works at La Terra Fina in Union City, California took me on a private tour of their manufacturing plant. You may have seen LTF's quiches and dips at stores like Safeway and Costco, and private label versions at other stores.
I think they were making the Artichoke-Jalapeño dip that day. What struck me was the contrast between the first part of the production line and the rest. They start with huge blocks of cream cheese, industrial size cans of artichokes and jalapeños, and dump them into a giant mixer by hand.
Once a batch is mixed and gets a taste test, the rest of the line is high speed and highly automated. Plastic tubs come through and get the dip squirted into them, the plastic seal and top goes on, and then a labeling machine attaches each label.
Pro tip: If you like their dips, try them warm. My friend had not actually done this, so I asked Claude for a recipe:
---
One time a friend served some La Terra Fina dip warm at a party. I'd only had it cold before, and it was a revelation. I forgot to ask for his recipe, but I believe he warmed it in the oven for a while and then under the broiler for a bit to lightly brown the top. What would be a good temperature and time for the first step, assuming a typical shallow casserole pan?
---
La Terra Fina dips warm up beautifully — the cream cheese base gets silky and the flavors meld in a way cold just can't match.
For a shallow casserole dish, I'd suggest:
Oven step: 325°F for about 20–25 minutes. Low and slow is the move here — you want it heated through without the dairy breaking or getting grainy. A shallow dish speeds things up compared to a deep one, so check at 20 minutes. You're looking for it to be bubbling gently around the edges.
Broiler step: 2–4 minutes on high, watching closely. The top should get lightly golden with a few darker spots — that slight caramelization on the cheese and any onion bits is where the magic happens. Don't walk away during this part.
A few notes:
• Pull it from the fridge 15–20 minutes before baking if you can, so it's not stone cold going in
• The spinach artichoke and artichoke jalapeño varieties both do particularly well warm
• Serving with something sturdy (crostini, pita chips, thick tortilla chips) beats thin crackers when it's hot and scoopable
The broiler browning is really what elevates it — that textural contrast between the creamy interior and the slightly crispy top is what probably made it feel like a revelation.
Location: Menlo Park, CA
Remote: Yes, or hybrid if nearby
Willing to relocate: Possibly
Technologies: Python, Ruby, C, C++, C#, JavaScript, TypeScript, PowerShell, Flask, SQL, PostGIS, Shapely, Unity, Unreal Engine, multiple assembly/machine languages, Windows user code and kernel drivers, Google Maps and other map APIs, geographic and airspace data
Résumé/CV: https://www.geary.com/resume.html or https://www.geary.com/resume.pdf and https://www.linkedin.com/in/michaelgeary/
Email: mike@geary.com
Hi, I'm Michael Geary. I've programmed in many languages and environments over the years. Some of my current interests are:
• Developer experience. I love helping my fellow developers solve problems, and building tools to make their jobs easier and more enjoyable.
• Aviation and geographic data. For example, airspace and obstacle data importers for Wing; election results and voter information maps for Google; many interactive maps for other companies.
• Hardware interfacing. In a way, I am a "full stack" developer, but my stack may involve a front end to a piece of hardware rather than the cloud. I first got into programming via ham radio, so RF hardware remains an interest.
• Designing and building APIs. Too often an API is designed by exposing the internals of whatever system provides the API. My philosophy is the opposite: start with the apps. I like to build a series of sample apps before starting on the API. This way I can imagine what API will make those apps and others like them easy to build.
• Talk with users! I don't like to sit in a back room cranking out code. I want to make sure it's the right code for what my users need, and that it's easy to maintain and improve as we learn more about what they want.
Open to full time or contract.
I look forward to talking with you!
It's listed in his HN profile: https://kavla.dev/
Along with his personal website: https://dahl.dev/