michaelwu

It's actually 2x...

Even if the risk of transmission from surfaces turns out to be low, I suspect it’s still >0%. Given the potential of developing chronic conditions from covid and the number of times we come into contact groceries, deliveries, etc., it seems rational to keep wiping down surfaces.

If you by chance have a mac or an iPhone, you can use Safari's reader mode read all the text comfortably after the page loads. Most of these sites load the text and then load some js to hide it from you. I've found reader mode works reasonably well on NYT and Bloomberg.

I kind of like it though. The lack of the usual "social network" features makes it much easier to focus on the merit and content of each comment.

I think bureaucracy is not specific to academia but is rather something that just arises when a group of people try to coordinate work among themselves.

In industry, we often also face an incredible amount of uncertainty in the form of unknown future functionality, UX, requirements, etc. As long as a business continues to adapt to changing market conditions, it's rare for its software to reach completeness. Some components' rate of change certainly slows down over time but newer components might rapidly grow in complexity or face major refactors. Successfully scaling to meet increased demand may also demand a pretty fundamental architectural shift. While not entirely the same, your evolving understanding of a problem and its effect on software requirements isn't too different from what we see regularly in industry.

It's very difficult to foresee what changes will be required 1-year's time, let alone 3. To that end, devs try to be extra thoughtful during the planning phase so that the end product is made up of well-behaved components. The extra time taken to come up with a sensible architecture goes a long way when business requirements eventually call for new or enhanced functionality and someone needs to understand the codebase in a reasonable amount of time. To be clear, this doesn't guarantee clean code -- bad architectural decisions happen, planning can occur without a clear requirements, no one held the quality bar during implementation, etc. -- but the outcome is always better than a laissez-faire design "strategy".

Perhaps scientific code churn is much more frequent than commercial code churn. In which case you would want to balance that by perhaps spending less time coming up with a good architecture -- and in the case of throwaway code, perhaps none at all. That being said, I would be surprised if new scientific knowledge always results in you having to discard every line and restart completely from scratch. I imagine that spending more time upfront architecting your software would instead allow you to more quickly react to new research results -- paying dividends on your time, in the long run.

Hitting a 404 now. Maybe all the comments here made them the blog editors realize they posted some bizarre advice.

They have an English UI now :)

Didi has been accepting payment via credit card for at least a few months now. It can be a pain to set up and doesn't always work but at least it's possible now.

Interesting that there is no mention of eslint. I've always found that the best way to learn a new language is to immediately install the linter and its associated plugin for whatever IDE you're using for instant feedback about potential anti-patterns / dangerous code while you work. Also curious that there's no mention of typescript: a lot of companies have already made the transition because it makes huge projects much easier to manage and read.

All of the things you mentioned are best practices when building something that you want other people to use in production. The author was trying to build this with the absolute minimum amount of code as an exercise so I don't think any of your comments here apply.