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