To be fair, most of the work environments people are romanticizing are not about the cubicles, but the startups. Smaller teams, kinda scrappy, but mission driven.

In a way, it hasn't changed a ton. Except, the startups now are not so scrappy, and the mission is pretty hotly debated (and for understandable reasons0.

Assuming no one surreptitiously swaps out the pages!

You still gotta keep it secure. ;)

Or uses white-out and splices numbers into different places. It's happened before.

The Web is meant to have links and interactive content and be navigated, sure.

But to expect every author also upload a PDF? I mean, TeX is great for what it is, but there's a reason _the web_ adapted print stylesheets.

Even if (La)TeX (or Typst, or Postscript or anything else) were easy to learn, you're left with maintaining 2 copies or a compilation system which is also a challenge.

It's ridiculous this is a problem, and has been for many ages.

I do a lot of teaching, and for many reasons share PDFs of articles in addition to the web pages and URLs. I know how to work around these things, but lots of reasons to print and article and what are normal folks supposed to do? Hell, sometimes I don't even notice until the cut is buried in the middle of the long document...

While everyone probably should learn something about their devices, the defaults you provide to users should be good ones.

Drawing a line can be hard, but clearly the basic font should be contrast-y enough so that most people can read it, no? The user can control the defaults of many things on their devices, but we shouldn't require them to change settings to have a good experience. We already customize websites a lot.

I think it depends on the goals of the print version, but people spend a lot of time picking fonts and styles so things look good on a screen. I take this as saying you should supply the same type of attention to your print style sheet.

I teach CS at Berkeley, as a lecturer. i.e., I'm contingent and on a contract. And don't really have grant money—though, y'know I actually try to supplement my income so I can live in the Bay Area. I spent years working in EdTech as well.

Others have already say why TA's (and graders) often do the grading. That's also not the same as the prof not paying attention to the work students do.

But I do want folks to think about the time faculty are actually allocated to teach courses. I have a 2 unit course I teach, ~70 students this term, and 2 hours of class. I'm paid for maybe 8 hours per week for all the prep class time, planning. Doesn't actually leave much time at all for grading. There are definitely qualified students who could be TAs who would give the students much more time and feedback than I am able...

For other courses, I have a bit more time allocated, but hundreds of students and still one of me. The only way students get feedback is when TAs grade.

Anyway, that's just the practical bits...

A lot of faculty are moving to 100% proctored assessment, and I think it sucks. For me, reading at least some of the student responses and seeing the data are helpful. Faculty do want to engage with their students and are similarly demoralized when everything is reduced to a transaction. It's hard not to be nihilist about it. Our own jobs, even at a public University are just capitalistic transactions with fewer profits. Students want the degree because it's the only thing they can hold on to as a token of hope for the next few years. Both students and faculty can fall into patterns of really low trust, and it's hard to be the 'outlier' trying to trust students when most of your colleagues say people don't do the work.

I don't actually have great solutions for building intrinsic motivation in students, except talking to them and minimizing the extent to which everything is a transaction. But I'm required to assign grades, still.

Parsing basically works!

Whether using text with LLMs in Snap! is actually a good idea is up for debate, but it is doable.

To some extent, that’s not the point. You don’t need to learn all of CS in one tool.

That said, I think you can learn good fundamentals of SWE with tools like Snap!. You can still learn testing, design patterns, working with APIs, modularity etc.

No it’s not a distributed system, and perhaps the biggest pain point is collaboration is tricky. But still you can learn a ton of cool things without going that far into CS. :)

Honestly this is still a great way to deploy apps and still some of the best DX there is, IMO.

Costs a crap ton for what it is, but it is nice.

I don't think complexity comes just from the number of tools, but the disparate things you "need" them to do. Redis, Vite, large CSS toolkits -- you're learning a bunch of large components.

I mean complexity comes from many places, but compared to the 'Unix philosophy' most of these tools are quite large. Obviously, there's quite a bit to learn about the way a *nix OS works, but if you treat tools as small and composable for simpler interfaces it helps a lot.

The web dev example of pub/sub is funny, because chances are if you're using Rails your primary DB (probably Postgres) already has a pub/sub system in or. Or you can just use any RDBMS for your job management system.