Yeah that’s mostly what I’m referring to.

Backups are pretty easy, but service availability and failovers across cloud providers is stupid difficult. Not really from a compute standpoint but mostly from a data consistency/transactional standpoint.

However, if you are using vendor specific services like AWS connect then you have to build and maintain multiple deep integrations into those services which effectively doubles your engineering efforts.

This is how I’ve always used hardware. Y’all out here buying up new parts each year they release?!?

It’s like iPhone crowd energy, but for PC parts I suppose.

Good news, they have these, and you even get paid to do it!

Not nearly enough mind you.

Cool 👍

Multi-cloud is a significant amount of effort to pull off.

Being on one cloud provider across multiple regions is often plenty of redundancy.

Being available across multiple cloud providers is really REALLY difficult

Honestly surprised C# isn’t on here? It’s still one of the “big 5” languages, and .Net touts it’s incredible performance on the regular.

The number of new devs who complain about having to write a unit test is too damn high

• Or writing integration tests
• Or passing CI
• Or following repo conventions
• Or following standards
• Or adhering to domain guardrails
• Or in adding monitoring
• Or in not logging everything as info
• Or in actually documenting features
• Or in receiving critical PR review
• Or in addition input validation
• Or in not trusting the client

…etc

Honestly most devs… Kinda suck at their job. This is becoming more evident to me every year

I work remote (Going on 9 years now) and I miss a sense of community. Do I want to stop working remotely? Hell no, screw that. But two things can be true the same time, I can enjoy and encourage them at work, dnd I can also miss a sense of community.

I think it’s okay to hold this opinion because it’s individual to everyone.

This just comes across as propaganda

Being dismissive and pulling the rhetoric that this is propaganda is toxic as fuck.

Hospital near me has password requirements for their electronic medical records system as:

• 6 characters, no more, no less
• 2 characters must be a number
• 4 characters must be a letter
• case insensitive
• never changed

And for new hires and what not, they tell them to use {hospital abbreviation}{2 digit year}. Like casu24

No freaking wonder

Why would it be on each dev to setup?

Your repo can, and should, include workspace settings for major editors that provide a uniform experience for anyone onboarded to the platform.

I agree that precommit hooks are good for uniformity. But slow pre commit hooks are frustrating, they are also often turned off. Your CI will always be the last gatekeeper for linting/formatting rules regardless.

Making precommit hooks slower means more devs disable them, which is the opposite of what you want. Save them for simple, read, checks and validations that can run in < 1s for even huge changesets.

Is that even legal?

I mean if you own a real estate, it doesn’t cost more just because the plot of land becomes popular. You can sell it for more, sure.

I don’t get how your registrar can suddenly boot you out from under a domain just because someone else is interested in it that has money.

Shouldn’t that person or company have to offer you money to buy that domain?

Or on save even. Slow pre commit hooks suckkkk

That’s not a linting problem that’s a formatting problem.

That project should have automatic formatting on save setup.

Linters are not necessarily formatters they’re solving two different problems and are becoming increasingly separated in their toolset.

Yeah, and electron already has a secureStorage API that handles the OS interop for you. Which signal isn’t using, and a PR already exists to enable…

IMHO it’s unnecessary at this juncture, and further fragments already vastly under engaged communities (.Net & C#)

Posts about .Net & friends fit into the .Net community. It’s not so busy that a new community needs to break off to direct traffic & posts to.

This is actually a common failing point/pain point for low traffic or “growing phase” communities & platforms. Fragmentation reduces engagement, and below a certain threshold it just straight dies. Avoiding unnecessary fragmentation until such time as it serves a purpose helps communities grow faster.

To highlight this: the number of mods you are suggesting this community should have to handle TZ coverage is more than the average number of comments on posts in the .Net community today…

I go full chaos and look up where I last used it when I need a snippet…

The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.

If it’s a greenfield project, in order to move fast you don’t want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it’s downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.

Ofc mature codebases don’t often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.

/ramble

There is no context here though?

If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).

I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.

The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.

The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .

Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.

Just a few hundred?

That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔

We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.

Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.

Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.

(No, loc is not a unit of performance measurement, but it can correlate)

Someone who shares their experiences gained from writing real world software, with introspection into the dynamics & struggles involved?

Your age (or mostly career progression, which is correlated) may actually be a reason you have no interest in this.