Ygor

In theory yes, only if you book via third party. But, my example shows there is some automated system that can even tag you for this if you use Ryanair to book directly. E.g. VPNs.

OKRs are just a tool. They can work pretty well if you have competent people and apply them correctly. But, that can be said of any other project management system, goal management system, gamification system... Some are worse, some are better, but most have books written about them that heavily feature survivor bias and correlations/causation bias.

The OKR book assigns most of Google's success on OKRs. Assuming there is an alternate reality somewhere, where Google chose SMART goals in that critical point in time. In that timeline Google of today is one floor below Yahoo in some random Verzion corporate building.

I haven't seen a goal management system yet that I cannot destroy with bad management and misaligned incentives.

As someone who wears glasses, my argument was always that most people don't want to wear glasses all the time, even if they were adding no extra friction vs your regular sunglasses (weight, looks, cost).

But, I had the same argument for Apple watch - no one in my circle was wearing watches any more. However, that didn't prevent people to start wearing an Apple watch.

So, I can definitely see a future where people who don't wear glasses choose to wear smart glasses.

Not necessarily disagreeing with this approach - but an interesting other side to this that should be considered: what about candidates who look great on their public profiles - real achievements and credible expertise - because they focus more on their public profile than their main job?

Completely anecdotal and probably another extreme of the coin - but I'm curious if folks have some experience with this and how to spot this case.

Yes, Bobiverse and Murderbot are very close in spirit, and if you like one you are very likely to enjoy the other. Also both have great audio narration.

Most people didn't. Some small group of people spent tremendous amount of energy. I think both of you agree on that point.

Also - keeping the stuff running, and making sure nothing ever breaks, is a different problem when you just want to maintain the current state of the product and keep it stable, vs when you want to change it.

Many tech companies are optimising for having hundreds of new features and products developing on top of the current stack, and allowing quick iterations, taking bets on things that might or might not have the market for it.

You can fire all civil engineers in the country and bridges will not collapse immediately. But you won't get any new bridges built. Also - at some point you might learn which ones had structural issues hidden by maintenance.

I'm not arguing that the setup is legitimate. I'm pointing out that the above analogy is confusing different tax types. The sales tax is not in question here. I'm all for revisiting how profits are taxed based on where they are made, but sales taxes/VAT is already collected correctly for both iphone and netflix.

No, you pay VAT/sales tax for stuff made in China. The company pays taxes on profits where the company is registered. When you pay for Netflix in France, you pay VAT on the transaction too.

"Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?"

I think this is a great question to use as a thought exercise. We don't see the designs that fail, as they don't pass the review? Using the analogy of software engineering being the design stage (vs build/construction stage), this would be a closer comparison. How many skyscraper designs fail before they end up being "uptaken".

Also, just because buildings don't collapse and fail catastrophically, I assume there are many flaws in the design that get "worked around" during construction. Many flaws (bugs) do likely end up "in production", but they are more of a technical debt type of issue that will be a burden for building maintenance and/or future tenants.

What is the alternative? Assuming here there is such a thing as a correct engineering strategy, who should define it?

Or, maybe there should be no engineering strategy, at least not an explicit one written down?

In theory SQL is SQL, even more so if your App uses a layer of indirection like an ORM. If you don't use any Oracle specific features, procedures and similar, in theory you could just replace it.

But that is not what happens.

First problem is - majority of mature enterprise systems (which tend to use Oracle), are not designed in such a schoolbook way, so that's you first problem. Codebases are ugly and teams loose the knowledge to maintain some parts that are mature and work mostly ok - often the DB layer.

Another concern is regressions in the product that is hard to properly test for. Minor details that are exposed by even small changes in DB behaviour or performance, that won't get caught in testing, but will cause an impact when your next scheduled job happens to fall on the first friday of that one month where the customer has that very special report that is just slightly so different and runs only once every 7 years.

Another major pain point are operational concerns. When dealing with DB technologies, managing, deploying, operating your back end DB servers can be quite a different beast. In theory your teams should be able to handle it, as they are experienced engineers that know how to learn new tech quickly. In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job.

And finally, if it all "just works" at the moment, it is a hard sell to switch such a fundamental part of the system and properly validate the investment versus the risks.

And this is all if you're not a super user of Oracle specific pieces, surrounding tooling or consultants/expertise.

Not sure about EEA only, but Revolut might work for you and it has virtual cards.

Would be nice to have privacy.com more widely available.