rudnevr

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

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.

you don't even seem to understand what dehumanizing means

* Media hype (and political discussion) is overblown from both sides. That's partially what keeps the left in the news because otherwise they don't have much to offer against capitalism unless maybe Hamas puts some show. And carefully calculated policies and solving problems is not rock-n-roll enough.

* The victims here are everyone who okupas can reach, the limit is not some imaginary moral boundary of the trespasser, but a sheer cost/reward balance. And it's not obvious where you should draw the line. Is a small shop worth it less than a relatively well off private citizen? How small a shop should be to be protected?

Arguably in the countries where the banks are protected the private citizens look even more protected, but I'm not going into that.

nope, there's no cartels of big landlords in Bcn, that's a leftist fantasy

Neither huge amount of somewhat legit cases of 'unused', nor media coverage doesn't make it right. I also wouldn't easily compare the murder count (which are hardly underreported) and occupation count (which most likely are, because legal way is way more expensive and lengthy).

I was actually kind:) Bad hygiene, unpaid debts, delinquency, women and child abuse, antisemitism can easily be added to the picture.

In the Mediterranean like in any resort area a lot of people live from housing, which requires not only owning, but also keeping it attractive, complying with local regulations, looks and the culture. It's nothing like rental company in NYC owning a garage full of rats, and charging a arm and a leg.

Middle class is a family from Zaragoza having a vacation house in Maresme or some extra property in Alicante which were sold for like 20-30K a few years ago, and then occupied, which took them a few months to evict.

The collaboration between scary deoccupying folks and okupas should be common, even if hard to prove, and it's mostly directed on people like this. Many people don't go to police and prefer to pay off just not to see their property ruined.

Thanks for the info. It's not that widespread, yes, but due to its gravity it's intoxicating and polarizing the public.

From what I observe, the amount of cases could have dropped down because many people choose to not buy or somehow shield their property (sometimes just filling windows with bricks, for example, which looks weird). So I'm not sure it's because the okupas/govt/police somehow changed the direction, it's just like the people get better at protecting themselves.

Btw, bying an apartment in Barcelona costs you 10% tax already, that probably discourages most speculation (and the prices have been stagnant for a couple of years).

I live in Spain and own property in Spain. There's clearly a gap between imaginary noble okupas addressing housing crisis via occupation of unused bank property and reality of weed smoking anarchists and their collaborating deoccupying mafia harassing mostly not-so-rich middle class, who can't afford the security measures the rich can. It's not a small problem, there's like 12K cases per year last time I checked. Everybody knows the problem exists, most people take extra, otherwise not necessary measures against it. The leftist govt adds to the problem somehow rationalizing it and trying to channel poor's frustration onto middle-class, while the actual abusers, who are well aware of the problem, stay safe.

Thinking through the inter-service interface is costlier and more transparent than calling the function in the same monolyth. That said, interfaces between services are inherently better than function calls.

Also, making mistake in microservice is more easily isolated, fixed and redeployed.

Other than that, microservices are business entities, rather than just tech entities. They can be scoped, evaluated and managed on business level. After all, you can ask another team rewrite the specific microservice. You can't do that with monolyth.

And the problem wouldn't be just buried in tech details and opinions.