I'm not going to defend capital's ability to ruin things, but this is framing is not helpful. Enshittification as it was described by Cory Doctorow, who invented the term, requires two additional things:

1. A platform that tries to attract both producers and consumers. Amazon is the canonical example. The platform does what it can to attract enough consumers that producers have to use the platform to reach them. Then it squeezes out the value to the producers (e.g., hiking acquisition fees, etc.; competing with them and underselling them with cheaper alternatives). The final step is to destroy the value to the consumer, by degrading quality and increasing price. By this time, neither producers nor consumers have many levers to fight back.

2. Non-physical pricing levers. Enshittification requires the ability to observe consumer behavior and jigger pricing at great speed. We see this in Amazon again; ridesharing apps introduced surge pricing; ads are priced according to what platforms know about you. In a physical store, the logistical cost of changing the price of goods is nontrivial, so we don't see the same sort of gaming there.

Enshittification is a novel and illuminating concept, so we need to be careful not to let it turn into some vague "things got worse" meaning.

I've always felt that the biggest problem with the Javascript ecosystem is that it's entirely too preoccupied with syntax. Remember CoffeeScript!? Some of the most influential forces in the community can waste entire years bikeshedding some syntactic thing that is mostly a matter of personal aesthetics. And this trickles down to the grunts trying to ship a product.

It's a fundamental drawback to Javascripts other strengths. And that's the reason it's so easy to find Express apps that are hot garbage. It's one of the most enduring myths that If you know Javascript, you can write a Node app.

It only works because software has been such an economically productive force, that having thousands of professionals spending weeks deciding whether semicolons are good or bad, or fighting their webpack configs, or migrating for loops to array methods... whatever... it still makes money at the end of the day.

I lean toward the pro-functional style, but I also put a few strong constraints on when to use reduce. Namely, I would almost never use it in cases where I either want to (a) mutate something other than the accumulator or (b) include more than two branches of control flow in the reducer function.

This kind of goes for all the functional array methods. Many people are tempted to use them simply as alternate syntax for iterating through the array (i.e., a simple loop), where the loop body could contain several statements -- i.e., data mutation side effects, taking different execution paths based on certain conditions, etc. The functional style is way less clear in this sort of code.

The benefit of the functional style in the context of javascript array methods is when you can see at a glance what the shape of the resulting value is with respect to that of the source array. This is usually best done when the body of the reducer/mapper/filterer is a single expression.

Why is he so popular? And how did he get so rich on Wall Street if he just thinks randomness blows all the statistical experts out of the water? I know I'm missing something.

Comments URL: https://news.ycombinator.com/item?id=18084834

Points: 2

# Comments: 0

I have had to push for leveraging postgres for data validation (including typing columns with enums where applicable), and sometimes it's hard to convince people, but all you have to do is (a) poke around your existing data and find cases where you have junk because of some out-of-band process that created data without using your main app's validation, and (b) do a couple out-of-band things like an ETL or two and see how it saves you from creating junk.

I don't know where I picked this adage up, but it's also something I constantly think about:

Your data will outlive your application code.

IME, if you value the data's integrity, it's not really a question whether you should be pushing validations down to the db layer.

I can't imagine you'll find a sane place to work where senior people are only capable of learning something after consuming a tutorial or a manual. The nature of the work is to drill down one layer below what you're working on. Do you need to know how to smelt steel in order to be a good car mechanic? No, of course not, but it sure helps to have taken an engine apart. And if you're trying to build the next, better engine, it's really great to see the internals (and the commented motivations!) of previous implementations.

Of course you won't understand everything on first read. But you will learn really good things if you know how to look at something confusing and identify what it is you don't understand; then you can go find didactic materials to fill in the gaps.

This is an amazing way to learn. You get to see how some of the most used, or cutting-edge tools are implemented (for free!). You learn about the tools themselves and thus gain expertise in them. And, you gain the meta-skill of working in unfamiliar territory, which I think is a fundamental key to being considered "advanced".

We started using Asana so that we could stop having nervous breakdowns every week. It worked. Now we use it for stuff like coordinating anything that doesn't fit on a notecard. Shopping lists generally are just on a kitchen whiteboard and you take a pic before you leave.