creatornator

A user might not know to look for that sort of thing. That's why we rely on regulators, safety standards, etc.

I didn't even know what "immobilizer" meant in this context before hearing about the issue with Kia and Hyundai a while ago.

No, it's day trading and picking stocks which is betting against wall street firms, obviously that's not the way to go. But that's not all of investing. If you are diversified and tune a portfolio for risk, it's more like a bet that the long term trend will be for the global economy to become more productive as time goes on. And this is usually true, besides the transitory periods of recession.

Yeah it's definitely a balance--the big company-wide meetings can be good for context but could also be too broad in scope. On a couple occasions I've enjoyed medium-sized informal get-togethers with my team, and I can sort of pick people's brains. Just having that social environment means I can sometimes talk one-on-one with folks I would rarely interact directly with otherwise.

I would think if you depend on data stored in a container being persistent, it's an indication you really should be mounting a volume to the container and persisting the data there. Then container restarts won't matter. Best practices are generally for containers to be "cattle" instead of "pets", and data persistence usually has a different solution.

Regarding using a container for distributing static site generators, does anyone really do that? I think you may be building up a straw man here, I haven't seen anyone recommend this workflow. Could you elaborate on how this relates to the parent comment's mention of using less space when running many containers? What the parent comment mentions is, in fact, highly relevant to some of the main use-cases of containers, which is running many containers of the same service on one or many hosts. Space can be saved there with layer caching.

I completely agree--in my day-to-day, I'm very much in my head about the problem at hand. I respect folks who can keep the long-term vision in their sights while applying that to short-term decisions which will help in the future. Some of the more valuable things I could learn from the higher-ups at my work, I feel, are related to big goals, changing landscape, rising opportunities and problems in the industry.

Pretty sure they meant Guix the OS not the package manager. The OS uses GNU Shepherd. Of course if you install the package manager on another OS, you get whatever that OS chose for an init system.

Which part of it is sad?

It's possible this is including many misclassified listings (e.g. hourly paid internships). Additionally, I've seen some listings for higher level jobs for absurdly low salaries ($19,000) which I can only imagine are typos. I wonder if the average somehow includes other regions too with very different cost of living. I wouldn't put too much stock in those average numbers. If you are looking to get an idea for the market for entry level SWE positions, it might make sense to narrow the search to known companies in your region.

Your assumption seems to be that if: 1) an existing language has finite utility 2) a language where any string is a valid program has no utility

, that it must be true that utility decreases with the unconstrained-ness of a language (and thus increases with more constraint).

However, this is not true. You only have to look to the other extreme to see there must be a middle ground. A language where there is only one valid program has no more utility than one where any string is a valid program.

Because this relationship of constraint and utility is clearly not simple, we can't use those extrema to judge if C++ is less useful because it gives so much control. There might be some "local extrema" where a language fits a niche. C++ might fill that niche, or it might not, but I think it needs a bit more of a nuanced consideration than "less constraint, bad".

I agree with other comments suggestions:

- Use the app, see what is slow from a subjective UX perspective

- Profile your code, find hotspots

- Use system monitoring to determine if there are any hardware/network bottlenecks

One thing I would add on these, perhaps a bit more specific: You mention you are using NodeJS, and it is a CRUD app. What is your database? Are you using an ORM? Sometimes the choice of especially an ORM can cause some performance issues behind the nice opaque interface. I have no specific reason to believe this is causing the performance issues for you, but I've had issues myself in the past so thought it might be a helpful suggestion to look into (for example, N+1 query issues).