Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
I agree with you about that, but why would an ill-defined report be kept open in the first place? It shouldn't be. Give the user an opportunity to provide more detail - for my own use I have some auto-text "scripts" set up, to make prompt questions easy - and then auto-close after a few days.
[Edit, answering my own question: they're left open because they were ignored to begin with.]
I write excellent bug reports, the vast majority of which (I'm thinking of one service-provider in particular, may they live in shame) get ignored. Or escalated and ignored; somehow that feels worse, though I don't know if it should. I guess it's the hope. It's the hope that kills you.
Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.
the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion.
if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.
otherwise you're just throwing away useful information.
edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
sure. But you can say put "please verify whether it is still present" via bot before doing so. Which apple did and I'm not sure why blogpost author is complaining about that
> you can say put "please verify whether it is still present" via bot before doing so. Which apple did
No, that's not what Apple did. They said, "Please verify this issue with macOS 26.4 beta 4", a very specific version, implying that they actually fixed the bug in that specific beta version (spoiler: they didn't). And I would have to go out of my way to install that specific beta just to "verify" the bug. Moreover, they gave me only 2 weeks to verify before closing the bug that they hadn't responded to at all in 3 years.
They suddenly created artificial urgency for no apparent reason.
While I fundamentally agree with the basis of compute getting cheaper by the year, I think a missed consideration here is the fact that these models are also requiring exponentially more compute with each iteration to train, in a way that arguably has outscaled the advances in compute.
Whether a generalized and broadly usable model will be able to trained within some N multiple of our current compute availability allowing the price to come down with iterative compute advances is yet to be seen. With the current race to the top in terms of SOTA models and increasingly iteratively smaller improvements on previous generations, I have a feeling the scaling need for compute will outpace the improvements in our hardware architecture, and that's if Moore's law even holds as we start to reach the bounds of physics and not engineering.
However as it stands today, essentially none of these providers are profitable so it's really a question of whether that disconnect will come within their current runway or not and they'll be required to increase their price point to stay alive and/or raise more capital. It's pure conjecture either way.
Circularly passing around tens to hundreds of billions of dollars for things which don't exist and may never exist to fund a technology that hasn't A. lived up to the hype they've marketed and B. proven any strategy to breakeven is fundamentally not that much different than the way in which Enron strategically boasted their revenue numbers by passing the money between shell corporations that their CFO created.
The main difference of course being that these are actual companies as opposed to just entities intently designed to inflate the apparent financials. While it seems like that difference means this situation is perfectly fine as compared with the fraudulent case of Enron, the net effect is still the same; these companies are posting crazy quarter over quarter revenue growth, sending their stock prices to crazy highs and P/E multiples, while the insiders are cashing out to the tunes of hundreds of millions of dollars.
I don't really see how exactly you're trying to make the argument that it may or may not be a bubble, it objectively meets the definition of a bubble in the traditional economic sense (when an asset's market price surges significantly above its intrinsic value, driven by speculative behavior rather than fundamental factors). These companies are massively overvalued on the speculative value of AI, despite AI having not yet shown much economic viability for actual profit (not just revenue).
Worse yet, it's not just one company with inflated numbers, it's pretty much the entire top end of the market. To compare it to the dot com bubble wouldn't be a stretch, it'd basically be apples to apples as far as I see it.
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.
reply