Hacker Newsnew | past | comments | ask | show | jobs | submit | inerte's commentslogin

I am not familiar with Chinese politics or motivation, but I wonder if it's for the same arguments we have in the US, "save the world" vs. "the strong can do whatever they want". I am not sure China does for the sake of sustainability and environment. Yes I know the end result might be the same but are the reasons the same?

I keep hearing this argument (that China does not care about climate change or the environment so it must be doing it for other reasons) but I just don't understand it. Why would you think they don't care about these things?

The Chinese leadership understands several things very clearly:

- The country has experienced multiple catastrophic natural disasters in the past.

- Such disasters often lead to regime change (losing the mandate of heaven via natural disasters leading to social unrest)

- The leadership is comprised of smart people (and a lot of engineers) and they don't play dumb political games like denying the reality of climate change.

- Climate change will bring far worse problems in future, which threatens the country's economic growth and therefore their hold on power.

So they have massive incentive to care about the reality of climate change and do everything they can to mitigate it and protect their environment.


That's speculation, and probably good speculation.

On the concrete side we do know that they also care deeply about local pollution. They made massive efforts to clean the air for the Beijing Olympics, amongst other many other moves to reduce local air pollution.


I'm in Beijing right now. I was also here 20+years ago. The difference is astonishing. Back then the air was filthy, it was hard to breathe, you never saw the sun. Today it is blue sky most days, EVs everywhere, electric scooters, busses, even garbage trucks. The roads are quiet. The air is clean. The high speed rail system is astonishingly good. This really feels in some ways like living in the future. The West is years behind.

Of course there are still a lot of obvious problems to be addressed, but the rate of progress is the really impressive thing.


I don't understand why you think I am making this argument you're referring to, when I SPECIFICALLY said "I don't understand the Chinese motivation" AND I presented the US side, which I am familiar with.

My whole post was an ask for more information on the Chinese side (each of my 3 phrases were asking this!), which you have provided thank you very much, but I could do without the "you're dumb" when I ask a question.


Maybe China wants to "save the world", in at least as much as they literally run into problems with smog and pollution locally and would like to reduce that pollution for practical reasons, as well as some prestige, especially now that the US is having a hissy fit on the global stage.

But none of that matters, China would pursue massive solar power infrastructure regardless, because they want energy independence. Stupid amounts of solar power means they will no longer be importing lots of oil and fuel, and that means they would be less vulnerable to the US blockading them in some sort of conflict, which is one of their primary geopolitical concerns.

They would do this even if solar power was dramatically less effective or was significantly more expensive, because solar power is the first kind of power generation that it is economical to way overbuild, and have serious redundancy and surplus and excess, because there's no consumables that scale your running costs like if you tried to build massive amounts of coal power plants.

China would like to have that kind of scale for power because they can use it to subsidize things like datacenters running less efficient Chinese made computer components. The fact that power doesn't have to run a profit in China helps this.

The US should be taking fucking notes, about how nationalized infrastructure can be a force multiplier economically, and how infrastructure that doesn't have to be profitable can be even more powerful.

Slaving ourselves to the enrichment of well connected capital owners is harming our country, and preventing a literal energy revolution. We have the option to, for the first time in human history, actually have energy resources that are too cheap to meter.


China also invests in solar/alternative energy because they still import a lot of coal from many other countries (some of which are aligned with the US) and that is something that could be leveraged in case of conflict.

Therefore reaching self sufficiency in terms of power generation will make this threat less relevant and an enemy will no be able to use it to make them back off.


Looks like last week was coding week, current one is marketing week.

The latest advice is to call an Uber instead of an ambulance.

Less whites, more of everybody else


I use "The project is 90% ready, now we only have to do the other half"


92% is half actually - RuneScape Players


From https://waymo.com/blog/2025/10/your-doordash-order-delivered...

"When Waymo arrives, open the trunk with your DoorDash app and grab your items."


It also implies that the restaurant has to walk out to the car and place it in the car too. They aint gonna like that. Although to be fair most restaurants already hate the drivers that physically come into their restaurants and don't obey the rules.


Sweet. Now I can turn unsuspecting Waymo cars into drug delivery vehicles. It's the perfect cover.


And leave a massive digital trail with it. Genius!


Use stolen CC on App, pick up somewhere seedy far away from where you live. OP is right, this will be abused. What is keeping people from dumping weird things into the truck after picking up their $15 cheeseburger?


Probably cameras that get installed the minute these start to happen.


> The games are hosted by very sophisticated companies, that have better mathematicians, and make money.

Oh, it's worse than that. In sports betting at least, if the gambler consistently makes money, the companies will ban or limit their gains. It's a scam.


I have an engineer on my team that's always asking "what if this or that happens in the future?" to which I've started to reply "what if it does NOT?"

I know, I know... wow. Not much insightful. But for some reason with this particular engineer this is the starting point to talk about actual requirements. This question in particular triggers the conversation of going back to product to figure out what they truly know they want right now, not in a maybe future. What are the actual hard, known requirements, instead of wishful thinking and "if everything goes well we will need this" type of mentality of ~hopeful~ optimistic PMs.


I find that these discussions happen in teams that lack experience.

It's common for junior engineers to want to over-engineer stuff: they want to pull this cool library, they want to try this nice pattern, and over all they want to make a good job and a complex architecture sounds like they put more effort into it than a two-liners. That's why junior engineers are not the team lead.

As the lead, many times it's difficult to prove why it's over-engineering. You can often only say "hmm what you suggest is pretty complicated, requires a lot of effort, and in this case I don't think it's worth it".

What makes your take more valuable than the junior engineer's take? Experience.

Now don't get me wrong: it does not mean AT ALL that juniors don't bring anything valuable. They often bring great ideas. But their lack of experience means that sometimes it's harder for them to understand why it's "too much". The lead should listen to them, understand what they say (and by that I mean that they should prove to the junior that they understand), and then refuse the idea.

If a junior feels like the lead is incompetent (i.e. does not understand their ideas and selects inferior solutions instead), then the team is in trouble. And in a way, it is the lead's responsibility.


The question “what if it happens” is important but useless without “how likely is that to happen” and “if it will happen how much time we need to cover for it”


Agreed. This is well studied in software engineering though, I think I've read papers from the 70s/80s addressing this about risk mitigation: what is the impact of the risk if it materializes vs how likely it is to materialize?

When people argue about the rigor of software engineering (i.e. "is it really engineering?") they often forget an important part: we are doomed to repeat mistakes or reinvent the wheel because nobody ever reads the existing research, nobody learns from the past, we're always blogging about the trendy latest thing withour asking ourselves "maybe someone in the 70s already explored this and drew valuable lessons?".


> we are doomed to repeat mistakes or reinvent the wheel because nobody ever reads the existing research, nobody learns from the past

We do. There’s dozens of us!

Here’s the thing though, the number of programmers in the world has been doubling every 5 years or so for the past few decades. If you have been doing this for 5 years, you have more experience than half the industry. It’s a young field and information only propagates so fast. You too have the power to help it spread.


I tend to approach it a similar way...

- If we do it <this way>, will <this requirement> be impossible to implement (without a huge rewrite cost) later? If so then, if <this requirement> is a realistic possibility, consider <this way> is probably a poor choice

- If we do it <this way>, will <this requirement> be harder to implement, but not terribly so? If so, then weigh the cost/probability of doing it and it not being needed vs not doing it and it being needed

- If we do it <this way>, will <this requirement> not be any more cost to add then if we did it now? If so, then don't do it now. Because you're risking unneeded time for no benefit

Admittedly, all three of those are the same "equation", just the three ranges of where the numbers stand. But it's nice to specifically ask the first and third questions... because they can cut short the analysis.


It's very insightful to realize that the space of things that will go wrong or will be important does not overlap very well with the contemporary zeitgeist of warnings coming from "best practices" and industry "thought leadership." It took me a while to get there. It's just so easy to point to some blog post that's become popular and use it to support your point when the person who wrote it knows nothing about your situation.


The engineer is wise to ask this.

Architectural decisions sometimes close doors and making future changes very difficult.

The only thing we know for certain is that change will happen.


Maybe have the app server contact a service that knows the user's location? You can probably somehow get the user's location on Google Maps, or Find My. Or... I don't know, Yelp check-ins with a particular hashtag?...


I used to work on a product where the app server and database were in the same rack - so similar low latency. But the product was successful, so our N+1 would generate thousands of queries and 1ms would become >500ms or more easily. Every other month we would look at New Relic and find some slow spot.

It was a Rails app, therefore easy to get into the N+1 but also somewhat easy to fix.


For our rails app we actually added tests asserting no N+1s in our controller tests. Think a test setup with 1 post vs 10 posts (via factorybot) and you could do an assertion that the DB query count was not different between the two. A useful technique for any Railsheads reading this!


That's a good trick. In Django world I like pytest-django's django_assert_max_num_queries fixture: https://pytest-django.readthedocs.io/en/latest/helpers.html#...

  def test_homepage_queries(django_assert_max_num_queries, client):
      with django_assert_max_num_queries(10):
          assert client.get("/").status_code == 200
Or django_assert_num_queries to assert an exact number.


Way back in the prehistoric era of Rails I just wrote a like 5 line monkey punch to ActiveRecord that would kill mongrel if queries per request went above a limit.

Probably some of the most valuable code I've ever written on a per LOC basis lol.

But anyhow, merging that into a new project was always a fun day. But on the other side of the cleanup the app stops falling down due to memory leaks.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: