cubaia

Aside from your opinion about that president, this is an interesting take, since the trades are between countries and the markets within those countries -- not between presidents.

> I don't think he makes the greatest trade partner anyway

This seems to imply that the president of Brazil represents the entirety of an economic block, and as such a trade deal should suffer because of just one person?

He used Tesla to save SolarCity, he can still continue using SpaceX to save Tesla.

Well, forget about AI ethics.

I actually personally know someone who was retaliated at Google for raising a basic OSHA violation..

It's troubling that individuals developing AI applications at Google don't have a voice to raise ethical flags or whistleblow.

The value of a publisher these days is not about the cost of publishing anymore (for obvious reasons, like text editing technology and the Internet).

Today it's almost 100% about the prestige/brand recognition of the journals which they still control.

Journal prestige still matters because: (i) it's a way people can quickly determine the value of a paper (i.e. without reading it); and (ii) "where" you publish has direct impact on researchers careers, funding, etc.

The only way out is for the research community to start using other means of ranking papers and assessing the impact of research in a way that doesn't depend on which journal it got published.

Looks like that conference had two completely different audiences.

As a developer, I tend to look at things and wonder about the future: "what can I build with this?"

I'm getting the realization that the equivalent for journalists is something like: "what controversies can I write about this?"

The key here is to distinguish from the pedantic snobs from good developers.

The pedantic snob will usually hold some extreme position about topics such as (1) obscure language minutia; (2) endless "framework building"; (3) premature optimization; or (4) mindless design "best practices".

They will have high pride attached to whatever is it and they would add a flair of expertise to it, making you feel like you hired a genius. At the start, it looks like they are working on some super advanced wizardry, but you eventually find that they mostly waste time.

On the other hand, the good developers care more about delivering value.

The good developer will not waste time solving problems you don't have --thus slicing through your 90% problem like butter-- and at the same time will possess the sharp tools to solve the hard 10% problems your less than good developer is unable solve no matter the deadline.

For option 1, you hire a good developer. For option 2, you hire a snob.

If you hire your average cheap engineer, you get option 0: he/she will eventually do OK for 90% of the problems, but the last 10% (which is often critical) will be a mess.

I think templates get a bad reputation because in practice many uses of templates are not appropriate.

Too many clever people saw 3 repetitions of a pattern and decided to show case every template trick to create a "generic library" that is compile-time optimized, usually to solve a problem that doesn't exist.

Multiply that many times through the course of a project and you end up with code that seems to try to maximizes job security.

> I'll take the open source microservices model with a good dev team any day of the week.

Whether it's monolith or whatnot, what you really want is the "good dev team" part.

In other words, if you're a Tesla driver, you're safer driving the car yourself than driving it with autopilot.

"That Tesla Autopilot had been safely used in over 100 million miles [...] That contrasted against worldwide accident data, customers using Autopilot are statistically safer than those not using it at all."

That is such a weak statistical claim, that it border the disingenuous.

Previous discussion: https://news.ycombinator.com/item?id=12082893

With bogus claims of safety and repeatedly blaming drivers for accidents, Tesla would be wise to fire whoever is doing their PR.

It doesn't seem like this has anything to do about Linus raw talent, or the "curse of the gifted".

Quite the opposite, it seems it was an opinion evolved through experience.

https://lkml.org/lkml/2000/8/22/52

Linus point was apparently about avoiding crappy interfaces when one goes about having common code just because it looks like they do the same thingy. He seems mindful enough that sharing code is hard.

https://lkml.org/lkml/2000/8/23/47

On the contrary, a raw talented engineer would usually jump into the opportunity to refactor and share common code, without realizing when the challenge is above one's ability.

In this aspect, even a few decades of experience in software (fragmented in many separate projects) can be less valuable than a single 5 year stretch in the same code base.