Another factor of purchasing in "the old days", particularly for Sears, was that it was usually quite easy to get replacements for faulty products. None of this business of packaging things up, mailing them away and waiting. Walk up to the counter, show that the item was nonfunctional, and a cheery salesperson would go out back and get a new one for you. Sometimes they didn't even ask for a receipt. Sears had products that were "good enough", and they wanted customers to keep coming back. Of course it didn't last, but that wasn't just this particular company.

I think that kind of behaviour ought to be controlled by the green dot at the top-left of windows, not by some particular mouse movements.

There was a time when the changes to the mac UI were quite good, or at least not annoying. Sometimes it seems as though they are changing stuff just to change stuff.

The teaching model is much like that proposed by the originator of this thread. Classes are 50 minutes instead of an hour (and similar for 1.5 hour classes). The start time is 5 minutes past the hour and the end time is 5 minutes before the hour. This gives students and professors enough time to get from one lecture to another (unless they have to commute across a big campus, in which case they simply do not sign up for classes that are too close in time).

I've served on a big committee on campus that solve the timing problem simply. It starts exactly on time. Every item has a designated number of minutes. And if it appears that we will not finish on time, there is a vote on whether to extend the meeting by 30 minutes.

I realize that a lot of the discussion on this thread involves bosses and employees, which is quite a different thing, of course. There's no point in starting a meeting at a designated time if the big boss is running late.

As the author of an R package, my release notes are much drier and businesslike. The package is quite static, so releases are mainly bug fixes. I start each item with either 'Add' or 'Change', then I name the function, and then I supply a short descriptive phrase and end with a link to the github issue where where users can see why the change was made, and what the code differences were.

I realize that this is not an answer to the question, really, because all users of the R package are basically on an even footing, in terms of knowing the R language and the science that the package is intended to support. If there is something transferrable to the OP's use-case, I guess it is to be systematic and terse, and to use a fairly fixed way of writing (being aware that not all users have English as the first language).

I maintain an R package that is quite stable and is widely used. But every month or so, the GHA on one of the R testing machines will report an error. The messages being quite opaque, I typically spend a half hour trying to see if my code is doing something wrong. And then I simply make a calendar item to recheck it each day for a while. Sure enough, the problems always go away after a few days.

This might be specific to R, though.

Of course, there will be complaints from many students. However, as a prof for decades, I can say that some will prefer an exam-based solution. This includes the students who are working their way through university and don't have much time for busy-work, along with students who write their essays themselves and get lower grades than those who do not.

The process of writing in latex for journals (and textbooks -- I've written for both things) is really very easy. Publishers almost always provide a sample .tex file that has items you just fill in. For example, there will be something like `\authorNames{}` and you just put the names between the braces. The same goes for titles, equations, figures, etc. There will be sample paragraphs as well. And they will have examples of various citations styles, too.

Speaking of citations, latex has good support for citation databases. (Typst and markdown also provide this support.)

I'd say most people I know write their early drafts in latex. They have a target journal in mind from the start of the writing process, so they just grab the latest sample file and stylesheet(s) from the publisher's website and start entering text.

As you say, using latex for freeform documents is a different matter. That's where I've started to use typst. And I do recommend it for such things. You may find yourself wanting to make some typst templates for common tasks (meeting notes, position papers, etc.) but it's not terrible hard to make such templates. I've made a few, but often I don't bother -- I just put a few lines of customization at the start, if I want to alter how section headings look, or I want a different font from the default one.

Like other academics, I plan to stick with latex for journal articles and books, unless publishers provide support for typst.

Markdown still has a place for files on github, because that means that web browsers will display formatted material, not just the raw code. A similar thing applies to code documentation, with many systems (R, Julia, etc) supporting various flavours of markdown.

I recommend typst to students for small tasks like assignments. It offers more typesetting power than markdown, it's a great replacement for msword, and it's easier to learn than latex.

Long story short, typst fills a niche. But it's not the be-all and end-all, at least in my (natural science) field.

I teach in a classroom that had blackboard that had stood the test of time for decades. When it was replaced with a whiteboard, things went downhill. The markers dry out quickly, without much notice, so that students often have trouble reading the material. And the whiteboards get harder to erase year after year.

I guess the advantage of whiteboards is that a variety of colours can be used. But some students have deficiencies of colour recognition, so that's not really helpful. (I never used coloured chalk, for the same reason. Maximal contrast is the key.)

And the noise. That click drag click of chalk. Students after the transition to whiteboards told me that they really missed that. It enlivened the lectures. And when students were writing down notes, they knew to look up when they heard the sound.

Back to the point about the "visual show" and doing slides in real time. Yes, yes, yes. Once in a while I need to show something on the projector. The moment I turn it one, I see students start to disengage.

1. There are a lot of build checks for problems involving mismatches between documentation and code, failed test suites, etc. These tests are run on the present R release, the last release, and the development version. And the tests are run on a routine basis. So, you can visit the CRAN site and tell at a glance whether the package has problems.

2. There is a convention in the community that code ought to be well-documented and well-tested. These tend not to be afterthoughts.)

3. if the author of package x makes changes, then all CRAN packages that use x will be tested (via the test suite) for new problems. This (again because of the convention of having good tests) prevents lots of ripple-effect problems.

4. Many CRAN packages come with so-called vignettes, which are essays that tend to supply a lot of useful information that does not quite fit into manpages for the functions in the package.

5. Many CRAN packages are paired with journal/textbook publications, which explain the methodologies, applications, limitations, etc in great detail.

6. CRAN has no problem rejecting packages, or removing packages that have problems that have gone unaddressed.

7. R resolves dependencies for the user and, since packages are pre-built for various machine/os types, installing packages is usually a quick operation.

PS. Julia is also very good on package management and testing. However, it lacks a central repository like CRAN and does not seem to have as strong a culture of pairing code with user-level documentation.

High-school and undergraduate science classes tend to pair lectures with labs. Practical work is very much the focus of those labs, and the lab instructors work closely with students who need help. And a postgraduate degree typically involves a student working side-by-side with a professor on practical work.

As for the pyramid model, I think the author makes some good points, especially for the grade-school level. However, it's simply a fact that being comfortable with adding comes in handy before moving on to multiplying.

Good teachers find ways to motivate students, and adjust those ways as the years flow by. They know how to do their job, and I trust them to find the best practices.

One thing I've heard from many teachers, especially those who are notably effective, is that teaching theorists are not of much help. And I see that in the silly trends that higher-ups impose on teachers. That way of teaching multiplication that has worked for generations? No good -- we must scrap it. The practice of teaching students to write cursive? So quaint - time to toss that in the trash bin. Years later, I see the results of these trends, when students come to university.

The problem of teaching theorists coming up with silly ideas is a result, I fear, of the system of educating educators. How do you get a PhD in a subject? You have to come up with a new idea. Nobody got an advanced graduate degree in education by writing a thesis that said "teaching is fine as it is." No, that PhD student has to say "this is broken, and here's how to fix it." But some things just aren't quite broken, not really. Sure, some adjustments might be helpful. More one-on-one tutoring would be great. Although then, the non-theorist immediately sees a problem: we don't have enough teachers, as it is.

Today, many university students struggle with basic calculations. I'm not talking about long division of 8-digit numbers. I'm talking about things like expressing 2/10 as a percentage or knowing how many zeros to use when writing 1/1000 in decimal form. Many very bright students, at both undergraduate and postgraduate level, struggle with such things. It's heartbreaking.

Huh?

Also, oral examinations are costly to administer. This work needs to be done with a panel, to avoid complaints. And the panel members cannot include TAs, who are after all just students themselves. A 10-minute examination can have start-up problems, and doesn't allow for in-depth followup questions.

With a panel of say 3 professors replacing 1 professor, and interviews of say 1 hour replacing what might be 20 minutes of grading, we are talking about quite a lot of increased workload.

A big annoyance of the early web was all the stupid blinking text and pointless little animations. Luckily we've moved past them. Of course, today it's all about ads, which is the tip of a spear that is quite unpleasant.

Plus ça change.