GitHub seems entirely uninterested in improving the code review experience (except maybe the stacked PRs thing if that ends up shipping) for well over a decade now.
Things that I’d consider table stakes that Phabricator had in 2016 - code movement/copying gutter indicators and code coverage gutters - are still missing, and their UI (even the brand new review UI that also renders suggestion comment diffs incorrectly) still hides the most important large file changes by default.
And the gutter “moved” indicators would be more useful than ever, as I used to be able to trust that a hand-written PR that moves a bunch of code around generally didn’t change it, but LLM refactors will sometimes “rewrite from memory“ instead of actually moving, changing the implementation or comments along the way.
Yeah, Tesla gets to blame the “driver”, and has a history of releasing partial and carefully curated subsets of data from crashes to try to shift as much blame onto the driver as possible.
And the system is designed to set up drivers for failure.
An HCI challenge with mostly autonomous systems is that operators lose their awareness of the system, and when things go wrong you can easily get worse outcomes than if the system was fully manual with an engaged operator.
This is a well known challenge in the nuclear energy sector and airline industry (Air France 447) - how do you keep operators fully engaged even though they almost never need to intervene, because otherwise they’re likely to be missing critical context and make wrong decisions. These days you could probably argue the same is true of software engineers reviewing LLM code that’s often - but not always - correct.
The US commercial aviation industry did not get to its excellent safety record by simply shrugging and accepting a “no-fault accident”.
There are always systemic factors that can be improved, for example working on street design to separate dangerous cars from children, or transportation policy by shifting transportation to buses, bikes, and walking where the consequences of mistakes are significantly reduced.
Cars are the #2 killer of children in the US, and it’s largely because of attitudes like this that ignore the extreme harm that is caused by preventable “accidents”
"No fault" does not mean "no cause" and air crash investigations always focus on causes, not fault. When you understand causes, you can think about how to prevent them happening again.
I’ve found that adafruit usually includes a cuttable solder pad for the power led when there’s real estate available. Just cut one of those traces this week in fact!
How do I use a laptop while standing on a train each day? It sounds like a laptop is sufficient for you, but I suspect (based on myself and other responses in this thread) that a laptop is not always viable for many people; this tutorial appears targeted toward those people.
I’ve actually considered a neck/shoulder support for a laptop in the past but decided against it because it’d be cumbersome and make me a theft target.
As for AI, personally speaking I use AI coding tools to allow me to continue enjoying some hobby side projects with less free time available with a kid. It’s been a massive boost to my happiness in a generally low stakes area. I’m curious to see if I can get a similar unlock on my short and interrupted commute times as well, which is why I (personally) find this article interesting.
dont try to code while standing on a train. one of many antpatterns a wise engineer should learn to avoid, as part of polishing our craft. also: dont juggle chainsaws, etc ;-)
but also dont try coding on a laptop. use a proper desktop, or better yet, get time on a mainframe. the problem has been solved forever, juat do work from the workplace at a dedicated terminal, built for doing that work at.
Not coding on a laptop is actually good advice?! My argument would be that you shouldn't be doing any work without plugging your laptop into a full size keyboard and mouse at least. And, ideally, at least one external display of some form (I recommend 2 or 3, but it depends on exact setup/total resolution/etc.). But it's your body, not mine.
Regarding terminals, how often does this requirement occur in practice? Assuming it does, you can probably use your laptop for it, in which case, see above.
It’s a simple idea but one that hadn’t occurred to me yet.
I spend hours each week riding transit, and use Claude for a bunch of side projects and have Tailscale set up already, so looks like I’ll be giving this a try this week!
Doom coding might be doomed while I’m in the transbay tube though, with awful cell service…
How’s the diff review? I rely heavily on the vs code integration for nice side by side diffs, so losing that might be a problem unless there’s some way to launch the diffs into a separate diff viewer app on the phone.
I would guess a phone is way too small for side by side diffs, and a simple `git diff` would probably be more useful. If you want better syntax highlighting you could setup bat[0] as your difftool. If you insist on a side-by-side view (neo)vim has a diff mode with the -d flag. It is also possible to setup as the difftool that git uses.
Heh, many years ago I actually started writing a dedicated diff viewer app for Android [0] that specifically had synchronized horizontal scrolling between the two sides, and I remember finding it relatively usable in landscape, and I’m sure modern phones with larger and higher density screens would be even better.
But yeah, you definitely need a native experience to make side by side diffs viable on mobile.
[0] https://github.com/scottbez1/superdiff — I wish I had recorded some videos of the app back then. My code review workflow back then eventually stopped including diff attachments on code review emails, so I abandoned development on it.
Let me know how it goes! From the comments above, seems like you can use tmux to keep persistent sessions when you lose Internet connection - but I haven't tried myself.
Diff review is alright. I'm an amateur programmer. Sometimes I don't look at the code claude generates, but when I'm troubleshooting a bug, I'll ask claude to output all recent changes - which satisfies my untrained eye.
I don’t compile from my phone but I do write code using it. I use fossil for version control. The in browser editor is good enough to get ideas down. It has great diffs which is also nice. I will check in code and move it to a branch then revisit it when I’m home.
Similar for cooktops - I’ve seen IR-reflectance-based touch controls go haywire due to dimmable overhead lights, and heard of frustration with capacitive controls going haywire from liquid splatters.
There are some very real benefits to touch interfaces in cooking (primarily ease of cleaning a solid flat surface, and manufacturers don’t need to worry about moisture ingress), but it’s pretty hard to make one that actually consistently works in a way that won’t accidentally burn your house down when your cat walks across the cooktop in the middle of the night. I’m personally going to stick to knobs and buttons in the meantime.
> it’s pretty hard to make one that actually consistently works in a way that won’t accidentally burn your house down when your cat walks across the cooktop in the middle of the night.
Regardless of how the controls work, you can make a cooktop that, functionally, will not set your cat on fire: use an induction stove. Unless your cat ends up in a pan or your cat is ferromagnetic, the stove won’t heat it :)
Can you be more specific about these “mandates” you take issue with?
IIHS doesn’t have any mandate power over manufacturers (they are not a regulatory body) but they do align with insurance company interests, whose goals are to pay out less for damages from vehicle incidents, and therefore IIHS logically would theoretically be focused on actuarial data-driven analysis. If you have specific examples of where this has not been the case, I’d love to learn more.
Here are some where IIHS punishes cars that don't meet its features with dubious evidence of improving safety...
Automatic Emergency Braking (AEB) with Pedestrian Detection: IIHS rates vehicles on forward collision avoidance, including pedestrian scenarios, but systems often underperform in real-world conditions like nighttime or with larger vehicles (e.g., trucks or motorcycles). Studies show virtually no crash reduction at night, and features can create false alerts, weather-related failures, or a false sense of security, potentially dulling driver awareness without clear evidence of broad effectiveness at higher speeds.
Roof Strength Test: Vehicles must withstand a force equivalent to a certain multiple of their weight (e.g., 4x for a "good" rating) to simulate rollover protection. Critics, including automotive industry analyses, argue there's no statistically reliable evidence that increasing roof strength beyond basic levels (e.g., from 2.5 to 3.5 strength-to-weight ratio) reduces injury risk, with claims relying on unsupported extrapolations from low-strength data and anomalous results.
Updated Side Impact Test (Introduced 2021): This tougher test uses a heavier, faster-moving barrier (4,200 lbs at 37 mph) to mimic modern SUV strikes. It's criticized for disadvantaging smaller vehicles unfairly, incorporating misleading variables (e.g., tire grip affecting results), and prioritizing structural deformation over occupant outcomes, potentially leading to "poor" ratings despite good dummy readings. Detractors view it as more marketing-driven than reflective of common real-world crashes, with little evidence that the changes proportionally save lives beyond the original test.
Very different standards - in its current form of emergency autoland it just needs to be proven to result in equal or better outcomes as a plane with no rated pilot onboard; the best case is another person that knows how to use the radio and can listen to instructions but the more likely case is a burning wreckage when the pilot is incapacitated.
To always auto land it needs to be as good as a fully trained and competent pilot, a much higher standard.
Things that I’d consider table stakes that Phabricator had in 2016 - code movement/copying gutter indicators and code coverage gutters - are still missing, and their UI (even the brand new review UI that also renders suggestion comment diffs incorrectly) still hides the most important large file changes by default.
And the gutter “moved” indicators would be more useful than ever, as I used to be able to trust that a hand-written PR that moves a bunch of code around generally didn’t change it, but LLM refactors will sometimes “rewrite from memory“ instead of actually moving, changing the implementation or comments along the way.
reply