Y7ZCQtNo39

It's simple, but requires a great deal of time to take advantage of compound interest. It's simple, but it requires dedication: you must say the course. Invest early, invest often, and invest for the long term.

It is a happy realization, though, to recognize how simple it really is.

It clears it up but personally, I'd rather just write `app.route(login, ...)`. Isn't a lot clearer to use more conventional language features? What exactly is this buying me?

I don't know if me saying 'Just, why?' is a good enough reason to throw my arms up and say it's an idea I'm not a fan of. I'm willing to say that it's a rather subjective attitude.

I guess my retort is that, it's far more confusing to have that syntax, then explain what it meant, when I could've just used the conventional syntax.

It's not like it's offering me something substantially simpler. For example, the spread operator that was introduced. It actually allows you to write clearer JavaScript code. This syntax isn't intuitively clear like the rest operator is.

It sounds like a single entity is helping many workers take individual cases (under unique circumstances). This sounds just like a class-action lawsuit, except with extra steps.

If it proves worthwhile, it could potentially give workers an option to fight back against agreements that prevent class-action suits in the first place.

And with the economy structured as it is, we all certainly know the working class could use a win.

I'm not a huge fan of decorators since they obfuscate the state of the runtime. What exactly does the call stack look like when login gets invoked? What variables are in scope? I find it difficult to reason about.

I understand that this function will execute when the HTTP server receives a GET or POST request at `/login`. The semantics of the decorator is clear-- I don't particularly take issue with that.

But the second my assumptions about the decorator break down (e.g., I think I've defined a decorator properly, but I have not), all bets are off on how to make it function properly. It's not as simple as going to the source code for the module and see what API's I'm calling.

"Increasing engagement" is probably a KPI in nearly every consumer-facing product these days. And as time goes on, it becomes more obvious, desperate, and frankly, annoying. Like when I receive FB notifications since I haven't posted in awhile. Really de-values the functionality of what a notification is, and now I don't care about them much since receiving a notification doesn't mean I've had an interaction with a FB Friend.

Yeah, that's another angle I didn't touch on. You don't have to publish all the feedback data. You can choose just to goes with the quantitative results.

Comments are tricky since they're both qualitative and might need to be scrubbed for anything personally-identifying.

I don't understand how that's a third option because either the review data is open and publicly available, or it isn't.

That 'third option' is just an opinion about the data.

When you review feedback collected (in any situation analogous to what you mention), you take that into account.

What if the feedback also said the doctor wasn't personable? Maybe the doc could be a bit warmer with his patients... and a patient would be absolutely qualified in determining whether or not that bedside manner is present.

I wasn't questioning the price --and I get that static sites are fairly trivial to create and host-- just the idea of a full-blown website for a wedding.

I know they're very common.

I always found the concept of a whole website, domain name, etc dedicated to a wedding to feel a little... heavy. I understand it's a big occasion. It just feels like a lot for a single event and domain that will become irrelevant after the event is over.

In some aspects yes, in others no.

I accidentally cut myself a little too deep while doing dishes a couple years ago (opaque, soapy water and sharp surfaces don't mix well). I couldn't get the bleeding to stop (without constant pressure held for about an hour), so I went to urgent care. I knew that I needed stitches or that "glue" they use to seal wounds. I didn't care which solution the Doctor picked, but I knew I needed something.

Students have some sense of what a generally good instructional experience looks like. It's better to collect this feedback, and have people that are experts in instruction examine the reviews, synthesize with their own knowledge of what makes instruction great, and use that information to improve.

But saying we should totally close out students since "they don't know what they need" removes a fruitful data source in determining where professors can improve.

Students aren't reviewing the quality of their campus on-site gym when they review their professor.

There's genuine concerns that should be reasonably heard. One example is slowness in grading homework/exams/etc. What happens is professors get backlogged, and you have multiple homework/exams and the student missed on understanding some concept they were later graded on. If the student had regular grade updates, they would know where they needed to focus more on the course material to master it. Instead, those misunderstandings snowball and you end up doing worse on a final exam since you didn't know what course concepts you correctly understood and missed.

I agree broadly with the wholistic assessment of what American colleges have become. But the review process is still germane-- classes are the core offering of college.

We made our own review system, to compete with the contracted-out system they used for their siloed data we didn't have access to.

We agreed to not launch the system, in exchange for limited access to the data, as I described above.

Professors en masse opposed opening up this data. That opposition alone made me feel we were doing good work. If they had to stand by their public reviews, hopefully they could stand by the quality of the instructional experience provided.

I ended up making a startup to deal with issues like this, to sell SaaS solutions directly to student governance groups, rather than to institutions. Both control fairly significant budgets (student governance groups at mid-to-large sized institutions have 6/7 figure budgets to easily afford enterprise pricing). My platforms are student-first. It's more a passion project than trying to get me Zuckerberg levels of wealth.

Very few professors are granted tenure, as was the case in the past. It's weakly non-zero: times have changed. There are far more adjunct professors today. Universities are more run like businesses than in decades past.

We pushed very hard at my alma mater to publicize course/teacher evaluations. We eventually got the University to accept iff a minimum participation rate was met (on a per course basis-- so it wasn't all or nothing. We'd get a subset of the data when enough participation occurred. We considered this reasonable, since if very few students participate, the data isn't all that meaningful).

Regarding professors wanting to keep review data tightly sealed: in my view, if you can't by public disclosure of your evaluation, then you either don't feel you're meeting expectations, or have no desire to improve in areas where students feel improvement could be made.

Also, the biases pointed out in these reviews aren't unique to academia. Gender and age biases exist everywhere. This article sounds like it's just pushing the idea that students should have less influence in the hiring and promotion decisions of professors. You know, the very people that the teachers first and foremost serve at a university.

I don't think we should necessarily be gatekeeping here. What makes life challenging is subjective to the individual. There are young people out there subject themselves to a lot of stress because they want to be successful.

Working really hard can take a serious toll on you. Not quite in the same way that common midlife stressors can pull you in 20 different directions (kids, aging parents, etc). But in the moment, the stressors are very real to the individual.

No need to be impolite. For one, no I haven't, since I'm not 40 years old. Second, they risk losing their core constituencies: the creative industry, and developers.

It actually has a different result, for someone like myself: it makes me not buy a new iPhone at all.

I like the ability to charge my phone and listen to music simultaneously, without having to worry about my headphones also dying. Usually this is in a travel scenario.

The hope is that you'd buy the Apple-branded one. Obviously Bluetooth is an open standard -- but that was the business intent.

An adapter is less convenient to use than having the Headphone jack on the device.

Is it really that farfetched to think they removed the Headphone jack to increase profits? Clearly, I'm arguing for it, but if this absolutely out there, I'd like to be brought back more sensible thought processes.

Not even the included earbuds with an iPhone purchase come with a 3.5mm jack. It's Apple's proprietary port, so you can only use Apple's wired earbuds with Apple products.

Removing the 3.5mm headphone jack was pretty rent seeking-- they hoped you'd buy the AirPods instead. It wasn't deliberately stated, but it would be in poor taste for them to state it as such.

The headphone jack removal wasn't comparable to past deprecations, like removing the CD drive from laptops -- which provided a significant new amount of space in the chassis.

A more mature project wouldn't have just React as a dependency. Point is, it's a lot of code to vet. React may have 5 indirect dependencies, but in my projects, I have 30 or more direct dependencies.

It's the kind of thing where, if everyone with this problem chipped in $5/month, we could have a central repository of vulnerabilities. So, not absolving yourself of responsibility, but also way more efficient to outsource.

This resonates with me, as my alma mater definitely doesn't have much (compared to the top endowments out there). It's not amount to sneeze at, but still, there are others ahead of us.

It's impractical, on an individual level, to vet your entire dependency tree. Installing something like react alone will put 100+ modules in your dependency tree.

A more mature project will have a 4-figure number of dependencies.

Things like Node Security Platform (which was absorbed by NPM) exist for a reason. There's no reason for every person to vet every single package they use -- it'd be an awful lot of duplicated energy.

If there was no implicit trust in the community, and we had to act as vigilant as you describe, there would be no community.

In my experience, academia is largely driven by money. Professors at my university were recognized for the money they brought to the university first and foremost it seemed, rather than for any discoveries/innovations in a particular field.

I can't remember the last time I've read a headline about the peer-reviewer that confirmed some groundbreaking finding.

Maybe it gives you the opportunity to network with higher-profile contributors to your field, if you offer to peer review their work (though to be honest, I don't know how the peer review process works, and if you can even "offer" to perform it for a specific paper).

I think it's strange since I can download software for MacOS anywhere. The only reason that it's accepted that you must use the App Store is because Apple was first to the smartphone scene.

Had Apple tried to force everyone into using a gatekeeping App Store after smartphones took hold, end users would've rejected it.

How do peer reviews happen, then, if nobody gets paid to do them? Does research money (that goes to the production of the paper) not also cover peer-reviews?

I wouldn't see any incentive for any work to be peer-reviewed, ever, then.

I have no desire to live in a 250 s.f. unit. What does my future look like? How would I raise kids, if I wanted to have them? I don't know how anyone outside of the top 3-5% pulls it off in San Francisco.

It wouldn't be seamless. But it wouldn't be difficult for a competitor to create a "competitor import" feature that moved over most of it in a few clicks.