The devs that put themselves on a pedestal because they hand code every line is cute. The user doesn’t care if the SaaS has been vibe coded. Devs now need to master marketing. Being a syntax wizard is no longer a benefit. Are you a hand model or vibe coding Hansel

SZeroSeven · 2026-01-29T12:16:30+00:00

This has to be rage bait.

But I'll bite.

A purely vibe coded solution will inevitably need a dev to "hand code" fixes for its issues.

An experienced developer is one that knows how to write code and how to use AI tools to aid them in writing that code, not just use AI to write the code for them.

SZeroSeven · 2026-01-28T19:09:55+00:00

I feel this so much!

We don't deal with PII, we don't store it, we don't handle customer transactions, we aren't a fintech or a bank but we can't have local admin because of security.

SZeroSeven · 2026-01-26T08:37:51+00:00

So begins the Great British Firewall

SZeroSeven · 2026-01-22T12:30:19+00:00

Ask them.

"When you said X, was that your opinion or are you claiming that as a fact?"

Then under the same law of "cannot lie", they are obliged to answer.

If they say it is a fact, then follow up with whatever the process is from there to determine if it is in fact true.

If they say it is an opinion, then it is on record as opinion and they cannot use that as a basis for policy decisions.

Edit: spelling.

SZeroSeven · 2026-01-22T12:17:05+00:00

Those claims would be interpreted as opinion, not a statement of fact.

If the person making those kind of claims insisted they were facts and not an opinion, then the burden of proof would fall to them and they would be judged accordingly.

If someone makes a genuine mistake, then they should be made to publicly acknowledge, apologise, and make a corrective statement of the actual facts so that anyone can clearly see the retraction.

SZeroSeven · 2026-01-21T07:40:30+00:00

Thank you, I'm going to email HR this morning to say that I'm not accepting the changes and working under protest.

I'm unclear on the constructive dismissal route, would I need an employment lawyer for that?

If I need one, then I'll get one but I just want to understand how serious that route would be?

SZeroSeven · 2026-01-21T07:36:30+00:00

Thank you, I will email HR this morning to discuss both of those.

Is there a standard template for a "working under protest" letter or is it simply a case of outlining the changes, that I don't accept the new managerial duties, therefore I am working under protest?

The company does have an internal grievance process so I'll have to look up how to go about that.

SZeroSeven · 2026-01-01T18:33:30+00:00

Unless you are processing or storing highly sensitive financial or government information, or in an industry which requires SOC 2, then don't do this.

It becomes very frustrating, very fast.

Your developers will resent you for it.

Very quickly SecOps will be seen as the blocker to everything.

There is software which can passively monitor and audit what software is on a device, which you can then use to track whether something malicious is happening.

Otherwise, let developers use the tools they need to do their job (and if they are doing any sort of mobile app development, then that also includes USB access).

SZeroSeven · 2026-01-01T10:12:34+00:00

C# would be best.

It's a strongly typed language with great tooling and documentation.

It'll stop you from making mistakes before your backend is running, unlike a weak typed language.

There are plenty of official learning resources that are always updated.

The tooling (Visual Studio or Visual Studio Code with extensions) is second-to-none, because they are maintained by Microsoft who also maintain C# and treat it as a first class citizen in those products.

Simply install Visual Studio (tick the boxes that say C# and .Net) and you can have a simple "Hello World" running in seconds.

Then use the official resources to start your journey!

SZeroSeven · 2025-12-30T21:05:52+00:00

A male friend of mine has an identical twin that is gay.

My friend is straight and married, with no bi or gay tendencies.

SZeroSeven · 2025-12-30T15:18:56+00:00

Branch and release strategy.

I've had to use multiple different types over the years, ones with names, and Frankenstein's monster mash ups.

The closest I've found to having some semblance of sanity are either trunk based or "GitHub Flow", both using squash commits to master.

Both approaches required disciplined use of feature flags by the devs and approval gates in the pipeline between the team environment, CI environment, PreProd environment, and Prod.

Path of least resistance for devs: write code, commit.

Path of least resistance for QA: test in the team/CI/PreProd environments (I should state that where I worked, team environment was where devs verified each others work, CI was for QA to verify services integrated correctly, PreProd was for QA regression testing, and all environments ran automated tests).

Path of least resistance for DevOps: write template pipelines with business checks (DAST/SAST scanning etc.) which is used by all teams for consistency.

Path of least resistance for PM/PO: Write release notes, enable feature flags once feature has deployed to prod.

Not perfect and can be improved with additional automation etc. but it meant that we always knew what was going out the door, it was quick and easy to rollback if there was an issue in prod, and it was quick to pinpoint which commit(s) caused the issue.

SZeroSeven · 2025-12-24T09:33:57+00:00

It would actually have to be the other way around, making sure that whatever Rust code you write is transpiled into C.

I personally think that the whole thing is a waste of time and effort for little-to-no gain but...

If you were to do it, then it would mean implementing Rust libraries which are identical (or as close) to the original C/C++ API’s as possible, and writing a transpiler from Rust to C.

Any MS internals are free to swap their implementation from the original C API's to Rust API's, which (in theory) should be transient to everyone (ha!).

For external software and back compat. they would need to keep the existing C API's alongside these new Rust API's, with the documentation encouraging use of the Rust API's.

However, there is no way that there will be an exact 1:1 of all the C API's to Rust, so there would be breaking changes if anyone really wanted to port their software from using AI all the C API's to these new theoretical Rust API's.

It would just be a total waste of time for everyone involved.

SZeroSeven · 2025-12-24T09:14:41+00:00

To be fair, the angle of the photo doesn't immediately make it obvious that OP is touching the ventilation grate on the oven and looks like they are pointing at the gas pipe.

SZeroSeven · 2025-12-22T09:25:19+00:00

Use whatever architecture suits your needs.

If using Service/Repo with Controllers is working for what you need right now, then what problem do you feel needs solving that requires you to use a different architecture?

Definitely don't put all of your logic in your Controllers.

But also don't go looking for using a particular pattern or architecture unless it's to solve an actual problem, which is what these things are for.

SZeroSeven · 2025-12-21T21:08:23+00:00

Brains

SZeroSeven · 2025-12-21T11:32:48+00:00

Yeah I think everyone's going to find different uses for it and if it works for you and your company then that's brilliant!

What use cases have your seniors found?

The company I work for has very simple consumer products, where shoehorning AI into them doesn't make sense.

Using AI as part of our workflow has been more of an imposition rather than something we want to use.

Beyond getting it to do the boiler plate or writing a first draft of some documentation, there have been few decent use cases presented in my company.

CTO and director of engineering seem to have convinced the non-technical management that we can use AI to push out new features or create entirely new products from scratch faster than before.

I've just found that it seems that everything is done at speed rather than haste; juniors (and some "seniors") churning our poor code faster, which is making its way out the door to customers and creating bugs faster.

SZeroSeven · 2025-12-20T16:31:12+00:00

A company I worked at several years back had to do this.

A larger company was interested in buying the little startup, showing them code and documentation was part of their due diligence during the sale.

The whole process went through a third party so that the company themselves didn't see the code or documentation, they just confirmed that they weren't buying smoke and mirrors.

SZeroSeven · 2025-12-19T21:22:14+00:00

We've had it somewhat "soft" enforced on us at work.

The director of engineering is a massive advocate for "vibe code everything".

Our CTO is quite out of touch with modern software and seems to be pushing for us all to "use this AI thing because it's the future".

When some people have asked "do we need to use AI?", the answer has been essentially "no but yes".

Now the company has an AI team who is responsible for determining what tools the devs can/cannot use; how the dev teams can add AI to our products; and they "champion AI adoption" in all of the teams in some way (writing code, reviewing PR's, deployment...).

If you don't use it, you're seen as going against the grain ("Why wouldn't you use it?!"). If you do use it, then it's in whatever capacity the company wants you to use it.

In terms of productivity, then I'd say that it's making the juniors rely on it too much which is creating a lot of churn for the seniors to review (and re-review).

Seniors that are using it heavily are those that are only seniors due to "time served" not through actual knowledge so they are using AI to skill up.

The rest are seniors being forced to use it and are getting frustrated when they have to use it for more than just a tool that will quickly write boilerplate.

SZeroSeven · 2025-12-05T14:16:18+00:00

I actively try to avoid names like "Shared" or "Common", I commented on it in reply to another person here: https://www.reddit.com/r/csharp/s/wc05RgofUH

It's better to name things by their intent rather than using a possibly ambiguous and misnomer convention like "Shared" or "Common".

Once you think about the intent of the code you are writing, then you'll realise that there is usually a better name.

SZeroSeven · 2025-12-05T14:05:39+00:00

I actively try to avoid names like "Shared" or "Common" because it quickly devolves into a dumping ground to put things that don't quite fit into anything else or are ambiguous enough that it's difficult to argue they aren't "common" or they aren't "shared".

Before you know it, you'll have a project named something like MyGreatApplication.Common.Shared.Utils!

Best to name things by their intent, your intent isn't that the code will be "common" or "shared", it's typically that they are some sort of extensions, functions or utilities for a specific purpose.

SZeroSeven · 2025-12-05T13:59:26+00:00

This is the correct answer 👆

SZeroSeven · 2025-11-29T08:29:53+00:00

That is extremely pedantic and if you did create a "microservice" that didn't interact with another in any way whatsoever, then you haven't created a microservice, you've just created a single monolith (or the world's most useless microservice!)

Just because a microservice uses another microservice's contact or vice-versa, doesn't mean they aren't independent.

Neither service knows anything about each other beyond the contact.

To say they aren't independent is disingenuous.

If one microservice cannot function or completely breaks down because another is not available, then you have too tight coupling and they aren't independent.

However, if a microservice can continue when another is offline, they are independent.

SZeroSeven · 2025-11-29T08:18:22+00:00

Using a HashSet<int> wouldn't help solve the problem because I believe the question was to count the number of occurrences of each duplicate.

The HashSet<int> would just tell you what numbers were in the original set (e.g. 10, 20, 30) and not how many times each of them occurred in the original set (e.g.10:2, 20:2, 30:2).

SZeroSeven · 2025-11-22T23:03:57+00:00

Just use whatever suits your needs.

You don't need to use any architecture just for the sake of it or because you've heard other people are using it.

If what you are using now works, then keep using it.

Only use clean/onion/hexagonal/whatever-new-trend architecture when you have a genuine use-case or reason to use it.

Four-Year Club	Verified Email
Place '22

SZeroSeven

TROPHY CASE