Ditto. If anything, trying to add it into an existing codebase via JSDoc has only really been a detriment via being a massive time sink. It might have caught maybe 4-5 bugs in the code but none that presented a large enough issue to warrant the time investment. If you're starting from scratch with TS instead of JSDoc, it might be worth it, but even on the best of days trying to figure out typing oddities from library typings being wrong and such have only really added headache. As always YMMV
Help is an interesting word choice for what is essentially undercutting our entire domestic automotive manufacturers and ensuring, on a pure cost front, that the majority of Americans purchase and rely on maintenance for a product produced in China. Doing so would have major negative consequences for our own strategic interests, hence why there has been such a massive tariff on it for several years now. China isn't being altruistic when they're attempting to sell us their much more affordable EVs. It's not a uniquely US perspective on the threat of Chinese EVs either, as the EU also has lesser but still non-trivial tariffs on Chinese EV brands.
If the US and the EU had invested in EVs 15 years ago like China did instead of scrambling to do so in the last 5, then China would not have the advantage it has now on the other carmakers.
Also if the governments want people to move away from ICE cars, then maybe they should stop putting tariffs on cars coming from China.
At some point, you need to make a decision and stick with it.
The way I see it as a consumer in the EU is that the EU is simultaneously saying we need to transition to a lower carbon economy as quickly as possible but then increases the price of goods that could be used in this transition. Make it make sense.
Is it my fault that the carmakers in the EU failed to invest EV tech?
So why am I being asked as a consumer to subsidize the legacy carmakers who were very happy to rake in billions of euros in the last 10 years while selling Diesel engines all the while knowing the the Chinese EVs were just around the corner?
Well, isn't it a good thing that they can help fight climate change without being altruistic? The entire western capitalist model is based on the premise that capitalism is good because people can help improve society through selfish means. Altruism doesn't scale. It's best when incentives are aligned.
The problem isn't with keeping Chinese cars out through tariffs. It's keeping them out, and at the same time not stimulating domestic green energy development enough. Why should the energy transition be bottlenecked by incumbent interests' profit margins?
> Well, isn't it a good thing that they can help fight climate change without being altruistic? The entire western capitalist model is based on the premise that capitalism is good because people can help improve society through selfish means. Altruism doesn't scale. It's best when incentives are aligned.
Yes, that's why you should let people buy cheap Chinese goods.
> The problem isn't with keeping Chinese cars out through tariffs. It's keeping them out, and at the same time not stimulating domestic green energy development enough.
Didn't you just say capitalism was good, and now you argue the opposite?
Really no idea what you're getting at. It's really simple and not some nefarious scheme. The Chinese government wants to be energy-independent so they don't have to import foreign oil and gas. Developing domestic green energy happens to align with fighting climate change, as well as transitioning the economy to a high-tech based one in order to escape the middle income trap. The incentives with the private sector are also aligned because this development is profitable. So they do it, by whatever means possible.
They sell some cars to Europe and North America, but the amount is negligible compared to what they sell domestically, and still much smaller than what they sell to ASEAN and the Middle East.
It's that simple. This isn't some grand plan to destroy foreign car manufacturers. If foreign car manufacturers get destroyed then that's by accident, as a result of them not staying competitive enough, not because that was the end goal from the start.
Of course it's in western governments' and manufacturers' rights to not accept this fate. But the most productive way to avoid that fate is by increasing their own competitiveness and by moving faster themselves, not closing themselves off while at the same time staying lazy about the energy transition. That's just rent collection.
The Chinese subsidise their own manufacturers of some goods. [0]
They do that partially as you say to develop their own energy independence. But there would be more efficient ways to do that, and specifically they wouldn't need to give gifts to foreign consumers.
I'm not sure why you think that I think it's nefarious? Western consumers (and other foreigners, like in ASEAN and the Middle East etc) get stuff for cheaper, that's nice for them.
The Chinese government subsidises these companies with tax payer money that they take from other parts of the economy; it's a net loss for the Chinese economy overall; but perhaps a net plus, if you focus on just the politically connected companies.
If you want to find anything nefarious: it's that rest of the Chinese economy that's being shafted.
> I'm not sure why you think that I think it's nefarious?
Most conversations on the Internet I've seen about this topic paint Chinese subsidies and Chinese car exports as a grand, deliberate, evil plan to cripple western companies and industries.
> But there would be more efficient ways to do that
I really doubt it. We have not seen any other examples of green energy rollout that is better. The improvement in Chinese air quality in just 15 years is staggering: Shanghai now often has better air quality than Berlin. Health outcomes do not easily show up in GDP figures.
Not when the domestic companies which manufacture the same product wither as a result. Don't get me wrong, I don't believe in defensive national economic policy as a blanket protection we should do to protect all industries, but in special circumstances such as this one where losing all of our electric vehicle production capability and specialization is at play, I think it certainly is in our strategic interest to avoid that from happening.
A company being unable to compete with another one on price will result in a drop in revenue, as consumers purchase the product with the cheaper price. Revenue going down is bad for a business. How exactly is any of what I've just stated wrong? How exactly is another company selling a similar product at a much lower price point good for the company? Perplexing position that somehow introducing a much cheaper product into the market from company B is good for company A.
I think the best test for a Junior is to ask them to submit some of their OSS or personal fun projects they've worked on. From my perspective, especially with Juniors who aren't expected to be extremely knowledgeable, displaying a sense of curiosity and a willingness to learn is much more important.
If, hypothetically, there's two candidates, one who is more knowledgeable but has no personal projects versus someone who has less knowledge but has worked on different side projects in various languages/domains, I'm always going to pick the latter candidate since they clearly have a passion, and that passion will drive them to pick up the knowledge more than someone who's just doing it for a paycheck and could care less about expanding their own knowledge.
To go one step forward, you can ask them to go into detail about their side project, interesting problems they faced, how they overcame them, etc. Even introverts who are generally worse at small talk are on a much more balanced playing field when talking about something they're passionate about.
Most engineers, including good ones, that I've interviewed have no interesting GitHub contributions. GitHub is also game-able. Bootcamps, in particular, push their graduates to build an interesting GitHub portfolio.
I've found that talking through projects is a weak indicator of competence. It's much easier to memorize talking points than to produce working code.
It may be a result of personal preference, but I struggle to see how talking through challenges encountered with a personal project are a poor indicator of competence. If you ask some boilerplate list of questions, sure, but few if any candidates could memorize all of the random in-the-weeds architecture questions one could ask while talking through someone's project. For a junior specifically, even a non-answer to these questions provides valuable insight into their humility and self-awareness. I also think that it'd be pretty easy to visually weed out personal projects created for the sake of saying one has personal projects, like a bootcamp may push to create, versus an actual passion project, and even easier to weed out during any actual discussion. I suppose YMMV, but in my experience, the body language and flow of discussion are vastly different when someone is passionate about a subject versus not.
Most of this isn't even necessary; just look for passion and <anything> that gets them excited from a relevant technology area, then probe for legitimacy and learn about their interests. Being a jr. is all about the individual learning and skilling up, you really shouldn't be looking for existing expertise.
You're dead sure? I wouldn't say anything definite about technology advancements. People seem to underestimate the last 20% of the problem and only focus on the massive 80% improvements up to this point.
Never really understood any company of any size that pushes for this type of workload. Do you really produce high-quality work on hour 100 of the workweek versus hours 0-40? For every startup that succeeds with this type of 996 dystopian work schedule, I'd argue more fail because of high employee churn, low worker motivation, and burnout even in a high-paid tech startup. In my opinion, even for those highly motivated, the human body simply can't do productive work in that type of environment. Some of the best startups I've seen are those with actual work-life balance. Not necessarily saying in and 9 and out at 5 on the dot, but certainly far from 996 or 997.
Ran into the same issue when I purchased a .ml domain (naively not looking into why .ml is such a cheap TLD to buy good names for, it has a super high spam risk). Purchased a different .com domain and haven't had any issues since. I didn't change content or anything, besides changing the domains in all of my links, and the same google ad campaigns and workspace for the new URL were able to be created without issue.
Fair point but I think the key point here is unnecessary complexity versus necessary complexity. Are zero-downtime deployments and load balancing unnecessary? Perhaps for a personal project, but for any company with a consistent userbase I'd argue these are a non-negotiable, or should be anyways. In a situation where this is the expectation, k8s seems like the simplest answer, or near enough to it.
Every time I see one of these posts and the ensuing comments I always get a little bit of inverse imposter syndrome. All of these people saying "Unless you're at 10k users+ scale you don't need k8s". If you're running a personal project with a single-digit user count, then sure, but only purely out of a cost-to-performance metric would I say k8s is unreasonable. Any scale larger, however, and I struggle to reconcile this position with the reality that anything with a consistent user base should have zero-downtime deployments, load balancing, etc. Maybe I'm just incredibly OOTL, but when did these simple features to implement and essentially free from a cost standpoint become optional? Perhaps I'm just misunderstanding the argument, and the argument is that you should use a Fly or Vercel-esque platform that provides some of these benefits without needing to configure k8s. Still, the problem with this mindset is that vendor lock-in is a lot harder to correct once a platform is in production and being used consistently without prolonged downtime.
Personally, I would do early builds with Fly and once I saw a consistent userbase I'd switch to k8s for scale, but this is purely due to the cost of a minimal k8s instance (especially on GKE or EKS). This, in essence, allows scaling from ~0 to ~1M+ with the only bottleneck being DB scaling (if you're using a single DB like CloudSQL).
Still, I wish I could reconcile my personal disconnect with the majority of people here who regard k8s as overly complicated and unnecessary. Are there really that many shops out there who consider the advantages of k8s above them or are they just achieving the same result in a different manner?
One could certainly learn enough k8s in a weekend to deploy a simple cluster. Now I'm not recommending this for someone's company's production instance, due to the foot guns if improperly configured, but the argument of k8s being too complicated to learn seems unfounded.
I've been in your shoes for quite a long time. By now I've accepted that a lot of folks on HN and other similar forums simply don't know / care about the issue that Kubernetes resolves, or that someone else in their company takes care of those for them
k8s makes it easier to build over engineered architectures for applications that don’t need that level of complexity
So while you are correct that it is not actually that difficult to learn and implement K8S it’s also almost always completely unnecessary even at the largest scale
given that you can do the largest scale stuff without it and you should do most small scale stuff without it, the number of people for whom all of the risks and costs balancr out is much smaller than the amount that it has been promoted and pushed
And given the fact that orchestration layers are a critical part of infrastructure, handing over or changing the data environment relationship in a multilayer computing environment to such an extent is a non-trivial one-way door
You really need to learn about the burden of proof, since you'd (hopefully) be able to figure out that in this case, the burden of proof is on you to prove what you're saying is accurate. HN isn't a place for hand waving arguments where your only supporting proof is "logic".
The truth of the premises do not require empirical evidence as you seem to require, they require the premises be true.
- Oncology is a for-profit business
- Curing customers reduces profits
- Treating customers increases profits
- Curing cancer is bad for business
Do you understand how logic works or is your brain fried by "where's the study bro..." Give me a break, man. Do you have any interest in sincerity or is your job at stake otherwise?
