Well that makes more sense, but it is still a lot of churn.

Sure, I mean it risks a lot of churn, but it hasn’t happened, in practice.

My team will debate the merits of a change until the cows come home, but they know that if they actually decide to make the change, I’ll expect them to put in all the necessary work to do it right. Ironically, that tends to curb their appetite for perfectionism.

Thankfully we’re all pretty much of like-mind. Nothing changes from project to project in the naming realm.

Yeah. Same here. That’s really why I get away with technically allowing a change during any retro. My teams appetite for refinements settled down after our first four sprints as a team.

Things might get interesting again, when we make our next hire; but I consider that part of the onboarding process. It should be worth the trouble just in case the new hire brings brings smart new practices we might have been ignoring. And whether anything changes or not, it creates a time and place for the new hire to argue their differences with the team.

We discuss naming conventions whenever we start a new project, and then it’s locked in.

That’s very practical, and really accomplishes the same net effect as my team’s policy, with less theoretical risk of thrashing.

A possible difference is that sometimes my team will insist on a refactor of some old code to update to the latest standards, at the start of a new project updating an old product.

As long as the code test coverage is acceptable to me, I’ll green light that effort as part of sprint zero.

We have tens of thousands of files in the project I’m in charge of, so we’d never consider such an extensive refactor.

Oh yeah. I would probably use my manager veto in that case. At some point it’s just too much work to verify the change.

We do have one big repo that we’re breaking up over time, and I insist that such changes be limited to the current actively developed component. It’s a unique case, because the vision for the repo is to get smaller as parts of it are decoupled (and released as open source). So we don’t deeply care if different modules have mildly different code standards, since they’re destined for separate public repos, in the long run.

I did do away with BEM when I started, because I despise that clusterfuck of a convention for more reasons than I care to explain here, but I waited until a new project to do it, and everyone agreed with me.

That’s some holy and righteous work you accomplished. All future developers on that effort owe you a debt!

You might as well not have a naming convention then, since the project is going to be full of different conventions.

Oh, I skipped this. Lol. Obviously not. As a team, they can implement whatever convention change they want, every two weeks.

As manager, I expect them to update all active projects, in their entirety, to the new convention, each time.

And as I mentioned in my other comment, if their test coverage isn’t at a level that makes me confident in that kind of global change (70% tends to be plenty), then I reserve the right to table it - until they bring the test coverage up (on all impacted projects).

You allow naming schemes to change every two weeks? That’s just insane!

Yes. Everything is open for discussion every two weeks, during our retrospective meeting.

Of course, that doesn’t mean things will actually change that fast.

But let me push back a bit, too - a global find and replace on our entire source code would take maybe a couple hours. A substantial naming convention refactor would take maybe a couple of days.

The reason we don’t do anything that aggressive is we don’t trust ourselves to make the change correctly - not because it’s actually a difficult change to make. Where our test coverage is where it should be, it’s a perfectly safe change.

If my team tells me (in agreement with each other) that a change like that is necessary, my job is to go make time for them to get it done.

On the scale of requests my team has given me, a couple days to rename some variables is no big deal.

There’s absolutely stuff I won’t allow, as team manager, but flip flopping on variable naming is owned by the team, and I would allow it, within reason.

A couple fair-game manager reasons I might shut down a variable naming convention change are:

• The test coverage on that part of the code doesn’t inspire enough confidence to make any unnecessary changes. Improve the test coverage, and we will revisit.
• (Hypothetically) We made two similar changes in recent memory, and as manager, this is affecting our team reputation. Let’s make a plan to make this change in a way that does not impact our team reputation.

Anything short of those two scenarios, and - should my team present it to me in agreement - I go make the time for them to make the change.

A shorter version is: I’ll discuss and do my best to support whatever my team wants to change - every two weeks. It’s a small price to pay for some peace for 9 out of every 10 business days! (And honestly, it’s a big part of my success formula.)

Oof. This is a pet peeve of mine.

As manager, I shut this conversation down via direct messages to each team member involved.

I remind them that they agreed during retro to live with the current set of decisions for exactly two weeks until next retro.

I don’t dictate much, but I do dictate that Slack isn’t an acceptable place for this kind of discussion, on my team.

The only related thing, that belongs in slack, on my team, is a link to the current accepted team standard - which will be open for review and changes again during next retro.

Alternately, if there’s no standard for this yet then my team knows they’re encouraged to wing it until we discuss at next retro.

And yeah, I’ve had to open an issue to revisit a variable name after retro, lol.

My team are an opinionated bunch, and they’re often perfectionists.

If you’re thinking about it in terms of quantity you’re already doing it wrong.

You’re ignoring that simple principles make great guidelines for not overthinking things.

And you’re doing so in the context of an article about the dangers of overthinking things.

You’ve over thought an article about the dangers of overthinking, while alienating potential collaborators with a condescending tone.

You’re coming across like one of the rookies who need this warning.

Consider counting to three, before applying DRY. It works.

Is this website broken, or just empty? Did I miss the joke?

There are plenty of bad abstractions in the wild and novices applying DRY is a common source of them.

You’re both saying the same thing though. Novices aggressively apply DRY the moment a second bit of identical code appears, while experienced developers often wait for a third copy and then think about whether DRY fits.

That said, I think "don’t apply DRY too aggressively is the whole point of this discussion, and the person you’re replying to was kind of needlessly disagreeing.

Yeah. I knew better, but it just didn’t occur to me until I was confirming my backups later.

This is like interviewing the child of a programmer and hiring based off of that.

I could land a job that way, but I’m just that fucking good. Lol.

Pro tip: Copying a Postgres database while live transactions are interacting with it frequently results in a corrupt backup.

Thankfully I test my Luanti backups.

Edit: I should clarify - My dangerous backup method was a naive file copy. I’m sure there’s a different correct way to do a live backup. I just haven’t checked into it yet, since stopping my Luanti server for a backup is no big deal.

“Java/Cobol is dead like Latin”

I love that. I’m going to steal it.

Edit: And I acknowledge that when I say that about Java, I’m just trying to wind people up. Java is losing popularity fast, but is still a pretty common first language.

Cobol is dead.

And I think it’s about time to start telling people Java and Perl are dead, so they can marvel at how much Cobol and Java and Perl are still doing in production after death.

This is delicious. I hope they hurry up, and I hope they do it in a really large really public context.

I’ve had this conversation, but today’s generation of AI won’t:

“No, I can’t just do a one for one translation. Some of the core operating principles of the language are different, and the original intent needs to be well understood to make the appropriate translation choice. If I just translate it one to one, with no understanding of the business context. you’re going to suffer from years off debugging subtle but impactful bugs.”

Get on with it IBM. Let’s light this dumpster fire so we can all bask together in it’s glow (and smell).

There may be a day coming in the next 100-1000 years when a learning algorithm is a suitable replacement for an expert engineer, but that day has not arrived (and the early evidence of that impending arrival hasn’t arrived, either. I haven’t seen evidence of AGI experiments with even toddler reasoning levels, so far. Toddler level reasoning wil come before AGI with infrastructure deployment skills, which itself is probably coming before AGI with expert business logic diagnostic skills. This could all be 20 years or 1000 years away. But we will probably see LLMs running deeply insightful life changing management workshops sometime roughly next week, since a trained parrot could do that. If we have an AGI that can meaningfully reason with small numbers in the next 20 years, we will be making great progress and on track for the rest to arrive - someday. If not, then we’re probably waiting on a missing computational breakthrough.)

Right. At least 70%. I’ve heard it estimated as high as 97%.

And it’s losing popularity with new development, (and with new developers) while WordPress, Drupal and WikiMedia are everywhere.

Perfect recipe to be the next Cobol.

Hang in there. CORS is a huge pain in the ass on the best day.

That said, if the issue is CORS, there should be a pretty specific message in the browser debug menu. Note that, if I’ve read that page correctly, the error won’t be available to JavaScript runtime, as an intentional security “feature”.

deleted by creator

Yeah. There’s always at least one mission critical Prel script that no one can read.

My money is on PHP.

CORS is just an ask for browsers specifically to stop cross domain communication, it protects the users not you.

A minor point of clarification to this point.

CORS also provides substantial protection to the server admin against innocent users being manipulated into taking malicious actions.

So there is some value to the server admin as well.

Sure, any malicious actor can assault the back end directly, but often they have no ability to attack from a context of authenticated trust.

A CORS misconfiguration makes the system more vulnerable to attacks that manipulate legitimate users into taking malicious actions.

So a CORS misconfiguration can lead to malicious actions coming in through highly trusted contexts, which can sometimes be substantially more harmful that random unauthenticated attack spam.

I have never done this before and I’m wondering if it’s secure enough to host the backend on some server and allow a CORS header to let the Frontend generate requests?

As long as you can get it working without putting any wildcards (asterix *) in your CORS headers, you’re using CORS as intended, and should be fine.

The alternative would be to host Frontend and backend on a VPS and then route my domain that I bought on Cloudflare there, but then I’m thinking that in case my Frontend is insecure somehow the whole instance would be compromised, no?

Back in my day we almost always hosted the front end and the back end on the same host. Of course, we also did a lot of stupid shit back then.

It’s not a disaster to host them the same place, but it’s certainly not a best practice. It’s better to get the CORS headers working, if you can. But just hosting them the same place isn’t, by itself, a security issue. It enables a shit ton of other security mistakes to be cause a lot more harm. But it’s not, itself, a problem.

Edit: Bonus tip. You probably know this, but lots of newbies miss it. Every piece of code and config in your front end app is optional to me and to all bad actors. So take care you don’t put any important secrets or critical defensive decision logic there.