Blog de Joe Freeman

The overhead that made teams skip internationalization and accessibility is exactly the kind of work coding agents do best. Here is how we set ours up to carry it. Localization and accessibility have been the features teams “get to later” and never do, not out of malice, but out of friction. Localizing strings means tracking and extracting every label and every string. Every change means touching every language file, keeping them in parity, finding an authentic translation, and regenerating bindings. Accessibility means writing labels that no sighted reviewer will ever see, for a screen reader that no one on the team uses. Both are tedious, both are invisible in a demo, and both are the easiest thing on the board to defer under deadline. So they get deferred. Forever. Coding agents change that. The exact qualities that made these tasks skippable — mechanical, repetitive, rule-bound, easy to sp...

Documentation rots because updating it is manual, tedious, and easy to skip. An agent removes the first two problems — it will happily update every page that names a symbol it just renamed. It does nothing about the third. Nobody, human or machine, updates documentation they were never asked to update. So ask. Every change, automatically, as part of the review you already run. This is the mechanical companion to a longer argument I made about design-time and run-time documentation . You do not need to have read it. You need three things: a way to tell which documents are supposed to be true, a rule that fires when they stop being true, and somewhere to write that rule down where the agent will actually read it. 1. Only some documents owe the code the truth Rename a class and grep your docs for the old name. You will get hits in two very different kinds of documentation files. Your reference and how-to pages describe the library as it stands. They are ...

You Have No Excuse for Undocumented Code. Every engineer knows the three excuses, because every engineer has used them. Documentation is too expensive. Writing it well takes hours that could go into features, and it is never the thing that ships. Nobody reads it anyway. You spend a day on a beautiful design doc, and it goes to the wiki to die. Nobody opens it again. Ever. Documentation rots. You write it, the code moves, and within two quarters, the docs are lying to people. A wrong document is worse than no document. All three were true. This was not laziness but a rational response to a real cost-benefit problem. The math did not work. The math has flipped because of LLMs. Documentation stopped being a message from engineers to engineers and became the substrate that the machines building your software run on . LLMs are voracious consumers of documentation — and, it turns out, tireless producers of it. All three excuses are now dead, and here is the sh...

Prescription lens wearers know that their glasses can catch monitor reflections that can be seen whenever they are "on camera", in meetings, or when creating content.  This can be exacerbated by blue light, anti-reflective, or other coatings applied to the lenses. We can remove monitor reflections by covering webcams with polarizing filters. Effect Flat-panel monitors often have polarizing filters that emit light waves oriented in a particular direction. The light on our glasses and in our reflection is essentially polarized. We can remove the monitor reflections by covering the camera with a polarizing filter. The filter needs to be rotated to orient the polarization to the minimum visible reflection.  The picture on the left shows the monitor reflection in my prescription lenses.  The picture on the right shows the lens reflection after putting a polarizing filter in front of my webcam. Polarizing filters will not remove the entirety of the reflection. The monitor l...