artwr
But also true that we have some strong local accents, and that people no matter their level should feel encouraged to at least try to speak French. It's the best way to learn.
I think there is a couple of interesting things. First, it's still somewhat orthogonal to the High context versus Low context cultures (see the Culture Map), as in you can have people with more ask versus guess culture in either communication contexts from my observations (at least among some low to mid context cultures, I don't have a lot of experience with very high context cultures).
Another way to think about it is that it's a lot more local than the broader culture of a country, down to the family level, and you can see this in the US as many commenters have reported where they grew up in various different places in the ask vs guess spectrum.
Finally, the US work environment is generally very "Ask"-leaning, in particular in Silicon Valley and it can take a significant amount of time to recognize where you have been raised on this spectrum versus what is required of you to be effective at work.
It's been quite illuminating for people in multicultural teams...
So for those large companies, the sunken cost is larger.
Also the most memorable ones are when people were dismissive but ultimately wrong about the viability of the business (like the "dropbox" comment).
To be fair, I doubt Maestro will take off like Airflow did.
Airflow filled a void of an easier orchestrator for Big Data with a prettier UI than the competitors of the time (Oozie, Luigi), implementing some UX patterns which had been tested at scale at Facebook with data swarm.
The field is quite a bit more crowded now.
I have similar questions about the future of Delta Lake, but not really about the future of Iceberg, that's what the Apache Foundation is for after all. There are enough large enterprise players relying on this (Apple, Netflix, ...) to keep the project going for a while.
True, but it's hard to start something as big as OpenAI and not warrant a little scrutiny. At least, I think there is plenty of public interest here, in particular because of the chosen mission statement for the company.
> Ultimately, I ask myself, is my life better because Sam was born and did what he did? And the answer is 1,000 times "yes!" because the introduction of ChatGPT changed so much and enabled so much creation and learning for me personally.
Which is a very reasonable position, but is the fact that your life is better negate concerns that applications of ChatGPT may actually make other people's lives worse? And that the lack of transparency around conflicts of interest raises reasonable concerns about both judgement and the ability of the organization to deliver on its mission?
>> It’s an organization created by a national government. > Why? What about this requires the power of "government?"
Budget mostly. I don't think the power of government is strictly required. There are some private organizations which try to take care of the commons (Hiya, Mozilla!), but it's still by and far had to fund. Why not use public funding for this?
> Contributor agreements are about to get way more parsimonious and annoying.
Why? I don't think the project necessarily needs to be owned by the organization, right? In which case, nothing changes to the contribution model.
> Nation states use software and knowledge of zero days to commit espionage against each other. He can't be serious with this.
That's true, but it's not as if there was no tension there. Significant backdoors could have impacts on the economy of some nations which are therefore incentivized to keep things running smoothly. You can play offense and defense at the same time.
Probably obeying the letter of the European Data Act, but obviously not great if true.
That's pretty pricey.
[0] https://www.acm.org/code-of-ethics [1] https://www.ieee.org/about/corporate/governance/p7-8.html
Of course, I may have worked in all of the wrong places but all but one of the places I've worked for the past ten years had source control for data pipelines or the ability to setup via config/source control code as opposed to UIs.
> - Prod/Staging/Dev environments are not the norm
Fairly true, though in some cases, staging/dev has a bit more footprint/investment required than for backend or frontend development.
> DRY and component re-use is exceedingly difficult (how many times did you walk into a meeting where 3 people had 3 different definitions of the same metric?)
That's a hard one and I agree that's where a lot of opportunity is. There are several efforts to get at a more semantic layer / metric catalog where the people who care about the metrics can agree on the definition, but that's more of an organizational issue, not a data engineering issue.
Proper data modeling to ensure you can more easily reuse the metric as needed is also core here.
> - API Interfaces are rarely explicitly defined, and fickle when they are (the hot name for this nowadays is "data contracts")
That's another hard issue. The way I see it, it's still going to be a mix between nicely defined contracts and much looser logging that the DE still has to try to shape into something useful, sometimes even successfully.
> - unit/integration/acceptance testing is not as nearly as ubiquitous as it is in software
I take a slight issue with ubiquitous. The amount of software (from paid vendors no less) I have interacted with which does not have proper acceptance/integration testing is just plain sad.
Higher salaries will get disclosed more, because if I get an offer below my current salary, then I can disclose and at the very least get a match or refuse the offer. At a lower salary, there is a higher probability that the offer is higher, and my current salary does not matter.
I believe that people more rarely accept a downgrade in salary, so the probably of acceptance is also conditioned on the current salary. What this means is that the effect is biased and probably non-linear, but I wouldn't qualify it as non effect.