Not the person you asked but in my limited experience, tech is actually valued in the US. Sure, there is also a culture of MBAs and business types taking decisions, but they at least understand that tech is essential (regardless of the reason).
In Europe, tech is seen as "just IT" especially in non tech corporations. It's much less important than in the US.
It's a pretty minor thing but personally I think just the fact that I rarely see the distinction between "software engineering/development" and "IT" in Europe is pretty telling.
> Pull request merge queues are available in any public repository owned by an organization, or in private repositories owned by organizations using GitHub Enterprise Cloud.
It’s probably fine, but this sort of thing is why transactionAmount and transactionCurrency are better when separated. Consider the case when you’re doing some reporting from your DB based on currency; do you really want to have to deal with one string that contains both or just do a simple WHERE clause?
In our case those are indeed separate in the database, so that we can type the value as a numeric, which is very necessary for many operations. Those fields only get combined in the serialization.
You also included localized formatting (the '.' and ',' ) in your example that'll likely break on parsing without special handling. For interchange, you'll want to avoid using localized formats, e.g. stick to the "C" locale or something specific or agreed to between the involved parties.
Proper documentation,especially API definitions. If it's just a few examples in the readme and I have to guess what the AmazongMetadataCobtextTypeProxy is supposed to represent, I am out.
Is this relying on scheduled github actions? We are using those and they are not very accurate. We regularly see jobs completely skipped or run with a lot of delay.
And yes, schedule is terribly unreliable. 1h+ delays are routine, 3h+ delays have been observed, high frequency jobs are skipped all the time. You have to use an external trigger (that is to say, triggering the workflow_dispatch event through the API) for reliable scheduling.
+1 for doing this for onboarding / knowledge sharing or just brainstorming possible solutions to a problem.
But do it with a clear timebox (maybe 1-2h) and breaks in between. Having to do this longer (like a whole day, even with breaks etc) would drive me nuts as well. Sometimes I just need to stare at the code for a while or draw pretty boxes with arrows on a piece of paper (kind of hard to share in a remote setting).
