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.
Latency makes this hard even with local connections, it’s essentially impossible due to physics to do it offshore.
And I believe Waymo remote access only allows providing high level instructions (like pull over, take the next right, go around this car, etc) precisely because full direct control with a highly and variably latent system is very hard/dangerous.
And in an emergency situation you’re likely to have terrible connectivity AND high level commands are unlikely to be sufficient for the complexity of the situation.
Yeah, the correlated risk with AVs is a pretty serious concern. And not just in emergencies where they can easily DDOS the roads, but even things like widespread weaknesses or edge cases in their perception models can cause really weird and disturbing outcomes.
Imagine a model that works real well for detecting cars and adults but routinely misses children; you could end up with cars that are 1/10th as deadly to adults but 2x as deadly to children. Yes, in this hypothetical it saves lives overall, but is it actually a societal good? In some ways yes, in some ways it should never be allowed on any roads at all. It’s one of the reasons aggregated metrics on safety are so important to scrutinize.
This doesn’t seem that crazy to me - a broadly applicable coordinated OTA zero day applied across cars during US rush hours has the potential to result in likely hundreds of thousands of deaths in a few hours if safety critical systems like airbags can be tampered/inhibited by OTA-capable systems.
The scale of car travel plus the inherent kinetic energy involved make a correlated risk particularly likely to lead to a mass casualty event. There are very few information system vulnerabilities with that magnitude of short-term worst case outcome.
Sure but you could just nuke us too, given that the response to a mass civilian death event would be the same. Same reason the US would be foolish to destroy the Three Gorges Dam.
It doesn't need to be a mass civilian death event. They can wait, collect data and kill 90% of our most important soldiers, heads of state, spies and everyone needed to maintain critical sectors of our economy. They could kill everyone who is anti-china. They could kill all the members of one political party (any one) as a false flag and cause a civil war.
Surveillance technology is nessisarially selective, so these "all or nothing" hypotheticals do not apply.
There was already a million vehicle recall for a vulnerability that allowed remote control of safety features (steering/breaking/acceleration control) that could be abused by anyone with a sprint mobile sim.
.... and the second US civil war starts up and one side has hacked into the automobile kill switches ...
"security" and "war" come in all sizes and shapes. Even inter-national warfare can be of the "cold" variety, in which nobody is nuking anybody else, but making automobiles randomly unreliable could be extremely effective (for a while, anyway).
Not really convinced by your argument. If you want to achieve your scenario you just take a sysadmin from the Tesla shanghai plant and next time they go to the US HQ they gain access to a coworkers laptop and deploy an OTA update to the tesla fleet. And this is assuming that the Tesla OTA update deployment mechanism is actually separated between countries, and not simply accessible from the Tesla intranet.
No need to design & ship another low-cost car model for this.
Flashing can be easy, sure. Compiling that binary, including library management, is not, unless you’re using something like micropython. CMake is not hobbyist/student-friendly as an introductory system. (Arduino isn’t either, but platformio with Arduino framework IS! RPi refuses to support platformio sadly)
Arduino took over for 3 reasons: a thoughtful and relatively low cost (at the time) development board that included easy one-click flashing, a dead-simple cross-platform packaging of the avr-gcc toolchain, and a simple HAL that enabled libraries to flourish.
Only the first item, and a bit of the second), is really outdated at this point (with clones and ESP32 taking over the predominant hardware) but the framework is still extremely prominent and active even if many don’t realize it. ESPHome for example still will generally use the Arduino HAL/Framework enabling a wide library ecosystem, even though it’s using platformio under the hood for the toolchain.
Even folks who “don’t use Arduino any more” and use platformio instead are often still leveraging the HAL for library support, myself included. Advanced users might be using raw esp-idf but the esp-idf HAL has had a number of breaking API changes over the years that make library support more annoying unless you truly need advanced features or more performance.
CMake doesn't spark joy, but it's not something you need to touch constantly. I figured out how to set up a basic cmake file and now I mostly need to touch it to set a project name, add or remove modules etc.
It was a while since I used arduino, but I remember having a harder time setting up a workflow that didn't need me to touch the arduino IDE.
reply