rudnevr

IDK, I worked like in ~20 enterprises and I didn't really see what you describe.

"Navigating customer requirements" is mostly everyone speculating on customer needs and pushing the part they own, and whoever happens to get closer to the higher management's ear, wins. Then market decides if that's is a good thing or bad thing. If it's good, normally the person who pushed this doesn't even receive credit for it, because either the command chain too long or the stakeholder's memory too short and postfactum everyone pretends they authored good decisions and opposed bad ones.

It might be tiresome and exhausting, like all intense politics, but it's not hard in any technical sense. Most mediocre people can do it and do it.

For something to be hard and complex you need rules and professionals on all levels who understand and follow the rules and driven by meritocracy alone. That's simply never the case.

I'm trying to avoid a snarky comment like "oh of course it's a senior dev's fault again", so I'll tell a story.

When I started around 20 years ago, my junior dev experience was pretty harsh - I was taught, not always in a correct or respectful manner, to do this and not to do that. Overall though, it was absolutely useful and formative. Senior engineers are rarely abusers, they communicate real issues, better or worse, and it was on me to figure out why and how to work the right way. Also we were raised in a pretty receptive attitude to the "old" technology - from Tcl and Smalltalk to Ada, Perl, etc. It was admired classics rather than just old shit.

Surprisingly, this didn't translate too well to my experience when I found myself in a mentoring position. Starting from 2015 maybe the situation changed. Newer generation of devs felt much more entitled to social games, higher salaries and opinions rather than authentic engineering interest and therefore my experience.

No amount of structured communication would change that, even the cold pressure of production failures and very specific poor management feedback normally doesn't work. They're also more lenient to prod screw-ups, and often use "everyone can make a mistake" excuse for excusing even more mistakes. The thing is, most of them don't want to hear for any reason.

As many of my peers I learned humility and accepted that as is, only using my advantage in expertise when it comes directly to my responsibility territory, and to avoid a hassle imposed by my eager younger teammates, like I usually parse prod logs and settings with command line while the younger guys trying to push through loki/grafana query limitations.

I'm fine and safe, and my job is no less secure, I guess, because someone has to fix bugs etc. The companies less so, but as long as they don't care why would I.

It will be interesting to see this generation wiped off by the next one. I guess they shouldn't be in a very good shape, because the foundation they built upon (namely quickly changing libraries and language supersets like React/TypeScript/some JVM flavour/and I hope Kafka) will be replaced by the next tech fashion.

Taking this to the extreme, I think most lessons represent sunset or dead projects. There's no sweet illusions anymore. No assumptions. No ego. No account for infinite flexibility. No shine. No excitement of a new thing. No holy wars. No astronaut architects. Only you, the ruins and the truth.

did it ever occur to you that you might be living in a self-reinforcing feedback loop? how long ago have been in interviewee's shoes?

doesn't your precious stash deserve an external folder or remote branch, in any case? the local repo is always a risk, so many things can ruin it. also, you only need to clean up like once a year, it's by definition a rare operation. A ton of branches doesn't grow overnight.

What's wrong with just deleting the whole folder and clone repo and whatever branch you're interested in? In any case it's not an urgent thing. You don't have to do this mid-work, you can wait until you push most stuff and then rm && git clone.

The only case in which this wouldn't work is when you have a ton of necessary local branches you can't even push to remote, which is a risk and anti-pattern per se.

that's true, and nice comparison with tests.

I don't know, I've always thought that junior problem was mostly non-technical, kids issues: overconfidence, love for shortcuts, sense of entitlement, arrogance, lack of communication and respect of colleagues, including fellow juniors and seniors, aversion to holy wars, lack of compromise and team discipline, disrespect to existing solutions, laziness in following-up post-delivery, negligent edge case checking, being opinionated about tooling, languages and whatnot. Very little of this can be fixed with AI, and many things can be easily amplified. I mean, one junior with AI vs one senior with AI might yield comparable results, but seven juniors with AI vs seven seniors with AI should fail pretty fast.

my impression was not that most people like their SUVs, they're just don't trust other people and don't follow the conventions. While on the micro level Americans follow the conventions much more seriously than Europeans (starting from tips and down to formal office rules) and love spending time discussing those conventions, on the higher level, with risk or high stakes involved, all the conventions go out of window, and the people fall back to guns, litigators, SUVs, suburban houses in the middle of nowhere, and other ways of self-isolation and atomization.

Soccer vs american football is another visible example.

i'm back too and i definitely do

having moved to us after 30 yrs of European experiences I would walk a lot in small and big East Cost cities. In the first year I was barely hit at least 3 times - once on the right turn with no lights (the driver only checked the left), once on the right turn red light (lack of my information so it's allowed in US), and once just when somebody went out of underground parking while talking to their phone. After that I learned never cross a road without making the eye contact with the upcoming driver.

Nevertheless, there had been a few episodes in the following years.

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".

it's absolutely stunning

Not at all.

The President of the ICJ has confirmed it did not find there was a plausible case of genocide by Israel.

https://x.com/UKLFI/status/1785305902276301019

I’m glad I have a chance to address that because the court test for deciding whether to impose measures uses the idea of plausibility, but the test is the plausibility of the rights that are asserted by the applicant, in this case, South Africa. So the Court decided that the Palestinians had a plausible right to be protected from genocide and that South Africa had the right to present that claim in the court. It then looked at the facts as well but it did not decide – and this is something where I’m correcting what’s often said in the media – it didn’t decide that the claim of genocide was plausible. It did emphasize in the order that there was a risk of irreparable harm to the Palestinian right to be protected from genocide. But the shorthand that often appears, which is that there is a plausible case of genocide isn’t what the court decided.

Even if we get Hamas numbers at face value, Israel has harmed about 60% of Gaza buildings and only got ~2% of fatalities (or whatever Hamas says currently), means that it is being done with extreme and unprecedented care.

The bullet's condition can provide a speed and direction, yes. It doesn't tell us about who, where and under which circumstances did this. And if you suggesting it's a common practice among the Israeli soldiers then you should have a lot of indirect and direct evidence. But there's none. There's not event a single video of a soldier actually shooting a kid from close distance. There's no conversations or written orders.

(And it's just an opinion section, it's not some conclusive investigation.)

no Hamas? Have you heard about a Hebron massacre 1929? https://en.wikipedia.org/wiki/List_of_killings_and_massacres...

And why should they be different - their prophet was the first pogrom champion and the whole history of Islam is a history of obsession with Jews.

https://medium.com/@Ksantini/the-list-of-crimes-committed-by...

you don't understand the principle of proportionality "jus in bello", which guides this. TLDR: It's not a scoring competition, it's about balance of means and goals.

Human shields are easy to see, if you're remotely literate in military law: if you don't see the non-combatants clearly marked, as you can observe happening in Ukraine, for example, it's a human shield and a war crime. If you see firing rockets from civilian area, it a human shield because the other side cannot respond and makes more mistakes. If you prevent evacuation of civil population, it's a human shield. Etc.

Talking statistics, 50 kids a day is such an obviously bogus number.

50 average dead every day in a year means we should have at least a single documented episode of mass killing of kids on that scale (which is already an extremely low bar).

One would expect outliers like twice that number, unless they are uniformly distributed, which of course they're not.

No such cases have ever been shown - neither accidental, nor deliberate.

Most of their "kids", obviously, are Hamas recruits in the age of 15 and up and has been killed in action in urban guerilla war. Which is still a war crime, but by the employing (Hamas) side.

Israel is doing extremely well.

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.

Smoking weed is neutral. Smoking weed anarchist is a demographic which tends to justify its modus vivendi pretending they have views. They aren't against private property. They're against other people's private property.

My solution to the lack of housing is to build more housing or having fewer people, it's that trivial and obvious.