My statement is not super constructive, but yes, I also really liked this article. Local-first, privacy, even the example of managing personal restaurant reviews.
I don't have enough meaningful thoughts here to contribute, but you & OP: I hope we can build a federated protocol for sharing stuff again.
OP: Perhaps it is, but this article honestly took me 12 months to research & write. I really struggled to find trustworthy sources. Do you know of any others I should look at?
Totally agree; I had to cut a few sentences about that :). (I also tried to steel-man the paper as much as possible).
Oddly enough, it seems like, although the value of "blind operation" is well-understood, it's not super well researched. As one of the papers I cite puts it:
> Little research deals with the optimal design of haptic features and how haptic feedback can support the user in searching for control elements.
OP here: I always disliked touchscreens in cars, so I didn't understand why automakers kept shoving them in. I always assumed I was weird in some way, and that most consumers preferred touchscreens or something (Reddit seems to argue this in circles all the time). I planned to keep buying Mazdas, with their lovely buttons and stuff.
But when Mazda unveiled their button-lite 2026 CX-5 about a year ago, I started investigating.
I'm pretty convinced that touchscreens today are primarily a cost-saving measure, and every other justification is secondary. I hope I can convince you, too!
OP here: I really enjoyed learning about the history of industrial design for this.
I wanted to understand the parallels between software engineering and industrial design (well, chairmaking) through the Industrial Revolution. Matthew Bird's [History of Industrial Design series][1] was fantastic, especially this quote [from John Ruskin][2]:
> Now it is a good and desirable thing, truly, to make many pins in a day; but if we could only see with what crystal sand their points were polished,—sand of human soul, much to be magnified before it can be discerned for what it is — we should think there might be some loss in it also.
I've been using "Big noun pages" in my technical documentation for quite some time now, and I wanted to formally explain the concept to my teammates. Thus: this blog post!
Perhaps this is a bit OT, since the article focuses more on self-development ("When training a muscle, you only get stronger with resistance"), but I wonder about the subtitle:
> Every week there seems to be a new tool that promises to let anyone build applications 10x faster. The promise is always the same and so is the outcome.
Is the second sentence true? Regardless of AI, I think that programming (game development, web development, maybe app development) is easier than ever? Compare modern languages like Go & Rust to C & C++, simply for their ease-of-compilation and execution. Compare modern C# to early C#, or modern Java to early Java, even.
I'd like to think that our tools have made things easier, even if our software has gotten commensurately more complicated. If they haven't, what's missing? How can we build better tools for ourselves?
OP here: I thought it might be interesting to document how I (a random engineer) have been using AI day-to-day. I tried to ground everything with real examples, so you can judge for yourself :)
What a timely article! I've been thinking about writing something similar for a bit.
I was doom-and-gloomy about how programming is more complicated now, but then friends pointed out a bunch of things to me:
* Arduinos & ESP32s (<$5): program in a simple app, flash over USB, & you're programming bare metal. ESP32s have Wi-Fi & Bluetooth
* Raspberry Pi ($30-$80): program on a real, self-contained Linux OS. If you trash it, just reset the SD card. GPIO, Bluetooth, Wi-Fi.
* Web (free): like theoa points out, you can make apps that work on any modern computer/phone in a single file with no compilation & instant output (and share it on GitHub Pages).
* Go & Rust (free): 2 easy-to-build-and-install languages, & Rust feels "C enough" to sate anyone who wants to learn "low-level" programming.
* Roblox? (free???): make & share games with your friends
IMO, the hardest things in 2024 (hah) are native app development & "modern" web development/anything that includes a login.
I don't have enough context for your points about learning without adult supervision, but I know that all of these options are very well documented; I bet No Starch has some good books for each?
I did that yesterday with a project: I took a Rust package that compiled a C project, then had the Rust project generate a C-compatible DLL that I could consume in dotnet.
It was so much easier (for me; I am bad at build systems) that I plan to do that for future projects.
Wow! Thanks for sharing. Sometimes I get disheartened about programming, then posts like this remind me how complicated the world actually is. And how much perseverance and elbow grease we put in to make the world simpler.
There’s actually published evidence of exactly that!
Where Do Security Policies Come From found that the websites with the most aggressive policies were those with the least incentive to make the system easy-to-use. Big sites like Facebook and Paypal somehow manage to be safe without the strict password requirements of <random university intranet here>. Likely because they have financial incentive to make their systems easy-to-use.
What would be a good, more academic overview of computing history? Do you have any specific book recommendations? I'd love to read a more "citation-based" version.
I'm not chaxor, but as far as I remember I think you're right:
If I had unzipped all the takeout directories into one giant folder, there'd be no conflicts.
Since I didn't do that, I had to do weird multi-pass parsing, since an album could be split across multiple ZIPs. I get a bit neurotic around backups like this, so I'd have loved some sort of virtualized filesystem that non-destructively represented all of those zips "merged together." But in retrospect, I should have just merged the directories into one folder---would have made parsing easier :)
I don't recall substantial problems with duplicates. Just weird renames and EXIF data mismatches. And since I was trying to archive my data, I definitely didn't want similar photos to be deduplicated.
My problems are probably different than chaxor's, though.
I would be extremely interested in a Google Takeout viewer if you ever end up releasing one.
I dealt with Google Takeout, trying to export my photos to Apple Photos (when Google was planning to charge money for old Google Workspace accounts), and I found it extremely difficult to deal with the file format. The script I wrote (https://github.com/citelao/google_photos_takeout_to_apple_ph...) ended up being decently reliable, but there were a ton of weird mismatches between the EXIF data in Google Photos metadata and the EXIF data in the photos themselves. Although some of that wonkiness was Apple Photos, not Google.
I'd love to see software that could wrangle the mess :)