sorry, my question is not that much of a legal side, there's plenty of info around - it's rather about identifying jobs which are open to this. Most HRs and hiring managers just ignore the applications which openly state - "I'm not on US soil".

ah right - personal network helps a lot here. if you're applying through the job board you're starting at a disadvantage.

it's absolutely stunning

Last time I frequented Boston Amtrak it would delay about 28% of travel.

I worked for Cognizant for a couple of years on multiple engagements, and I'm not Indian. I saw different things, and obviously there was some dynamic around ethnicity, from 'I'll only hire Indians because they work harder' to Indian boss abusing another Indian programmer while excluding me. I was somewhat advanced level, though, maybe that played a role, so for me personally it was an overall OK time. Overall it's good that this conversation eventually happening, I think, it's in everybody's interest.

that's what they actually do, yes. It's been a joke first, not anymore

The problem is that publishers, being the middleman, take over authors the same way the supermarket network takes over the food producers. Publishers own the shelf and a price label, and being less numerous and more organized, they can effectively own the audience's attention. They can help, they can also shut author down. They're not ultimately interested in maximizing availability, because they profit directly from the gap. That's why they need restrictions and ways around them.

Same. Out of 15 shops I worked for this was absolutely different (2017-2018) and the only place I've seen pair programming and TDD done right. Once we managed to deploy first version of a trading product with no bugs at all.

When I tried to explain other people afterwards how to do this, they just shrugged, as if I told a fairy tale. I had a chance to demo it maybe a couple more times while migrating other systems, and very successfully (and with very low mental and emotional effort) - itemizing the tests cases first, building fakes, frequent commits, trunk-based development, small stories, incremental improvements.

But it's never been perceived as a designed success, they are typically so prejudiced that they saw it as a fluctuation in the monkey circus of software development they got used to.

Now I'm at the stage we need a support group for ex-alumnis.

it's kind of strange to me that ad-hoc debugging is considered such a valuable skill. I thought it's mostly a juniors' perspective. I typically set up extended loggers and logger methods, write everything to the some formatted file, and have a diffable, persistent, provable, multithread-friendly and versioned bug demonstration, which scales well to bugs of any complexity.

(I once found some 10 bugs in a pretty old and tested bond calculation engine while migrating it to the cloud, which nobody could initially believe.)

IntelliJ does, of course. Per project, per window, with background images etc

not a good advice at all. it's hard to interpret right and will probably change in 5 years anyway when the author reaches another stage.

my advice would be much simpler: 1. Most of the time you'll be manipulating test. Learn options how to manipulate text professionally. That includes vim, bash, sed, awk, perl, and regexes in general, including lookbehinds etc. It's worth it. It takes a few years to learn but even the basic options give you the culture and approach how to do things faster. Most coders have trouble swapping two columns in a text file or finding unprintable character.

2. Learn hotkeys seriously. They're more consistent and uniform than UI, learn how change them, which tools are better designed for them, and organize some memorization scheme. It pays off a lot and gets into body memory, freeing up mental space.

3. Learn how to version your own code instead of creating multiple files and folders. Read git manual at least once. Learn how patches work, what is interactive rebase, and how to go back and forth, combining different changes from different branches. That gives you freedom to experiment with code on a larger scale.

4. Learn how to quickly test any framework/code. There will be countless situations where you have some piece of crap not producing the needed result, and you should be able to quickly prove it. For this p.1 is invaluable. I have my own json,xml,rest,kafka and text log parser and diff, and a few cloud, database and search clients which I tweak when switching jobs. It's all mostly written in standard unix tools, and can be literally retyped if needed (I worked on high security envs often). It's also isolates me from poor (non-)standard tooling different in every enterprise to which I only fallback when I already know the answer and need to prove it to a peer.

The rest is subjective and optional. You can love or hate your job, you can love tabs or spaces, weak or strong typing, but the above will definitely makes it faster. What to do with the rest of that time is your decision.