VS [Code] Marketplace error: "An item with the same key has already been added."

 If you're very unlucky and when trying to upload a new extension to the VSCode marketplace, you may get this error: "An item with the same key has already been added."

If you use the website, you may see this (not particularly helpful) error message.

Of course, you really should be using an automated, repeatable process/script to manage your submissions, and if you do that, you'll still get the same result. (I only tried the website after all other attempts to work out what the duplicate key might be.)

Error: An item with the same key has already been added.

Error: Process completed with exit code 1.

Anyway, for me, it turned out that we had content types for both "json" and ".json" defined. (With and without the leading dot.)
Some systems don't mind this, while it turns out the marketplace does.

I hope this helps someone else find a solution to their problems faster than I did. (10 emails, back and forth with support over 11 days!)

Human questions to ask in code reviews

Automated (AI) powered code reviews are becoming increasingly popular and powerful. I use them myself to catch things I miss.

But there are questions I ask as a human reviewer that I've yet to see any AI-powered tooling help with.

 Questions like:

• Does this fix the cause or the symptoms?
• Are there related changes that should be addressed while we're in this part of the codebase?
• Is this just fixing a problem or actively making things better for the user? (They aren't always the same.)
• Do we have related docs or samples that need correcting/updating or adding to?

Is second-order enshittification a thing?

 
Enshittifcation, as a term popularized by Cory Doctrow, has for many become a catch-all term for things generally getting worse. I've found it useful (unsurprising if you know me) to think about it in two categories.
There's the popular definition of how very large, dominant platforms change [to get worse] over time as business/organizational priorities change.

I think there's a second-order version of this that follows as a response.

I'd sum it up like this:

"If [big company] doesn't have to focus on quality, we can cut corners there too."

What happens when "everyone" takes this approach is that things get continually worse. Not all at once and not always in the immediately obvious ways. More in the million paper cuts way.

From a software perspective, it's the increasing number of small bugs that no one seems to care about fixing. This teaches people to not bother reporting them. After all, "what's the point? They're not going to fix it even if I [you] do report it."

With fewer known or reported bugs, the company thinks everything is fine, or worse still, thinks skipping on quality is an approach that works.

And a self-reinforcing cycle continues.

I prefer to think of it another way.

Software exists to help people and to make their lives "better". This could be in one or in many ways.

When people are constantly being interrupted, frustrated, and disappointed by the software they use, it's very hard to argue that it is making them better, happier, or more productive.

This is part of the reason I think that QA, customer service, and fixing bugs are among the most important things that those in software development can focus on.

With AI making copying software easier, it's focusing on how it relates to people that can be the real differentiator. 

Yes, AI may mean you can vibe code a copy of something that exists, but does it include support for all the non-obvious edge cases? Do you even know all the features that exist in what's being copied? How (and?) will you handle any bug reports?

Yes, building software can be fun for you, but high-quality software that works reliably benefits many more people and, in a small way at least, makes the world a better place.

And this can also lead to mediocrity

A small company tries to compete with a large one. They try to do everything because that's what the large company (or their software) does. They try hard, but as they're stretching themselves so thin, everything suffers. "Never mind", they say, "at least we're trying our best." But, for what? Who benefits? The company's staff exhaust themselves producing a mediocre product, and it's no better than the alternatives.
Trying to compete with a large company and basing goals on the perceived [low] standards of another company doesn't produce a great product, happy customers, or happy staff.

_This was written many months before posting--to avoid anyone thinking I'm responding to a single person, company or incident_

It's probably not an MVP

It's common for people to refer to early versions of software as MVPs (Minimum Viable Products).

Only, that's not what an MVP is meant to be.

People say: 

"ship it early"
"try something out"
"get feedback"
"don't worry about polish"
and "you should be embarrassed about these versions"

But these aren't descriptions of an MVP; they're descriptions of a prototype, and the two are not the same.

A prototype is an early, experimental version intended for getting feedback.

You'll probably use multiple prototypes (or versions of them) until you find an MVP, or confirm that the prototype isn't going to make an MVP.

People tend to focus on the "Minimal" part of the MVP and forget about the rest. If it's not a "Viable Product", then it's not an MVP.

It's not an MVP if there aren't enough people willing to pay for and use it as it is for it to be a sustainable product/business.

Then, once you've proven you've done enough to make it a viable product, then you can add polish, more features, focus on performance or scalability, promote widely, etc.

It's not an MVP if:

• It's a free beta version
• It's only being tested internally
• It includes more features/functionality than are absolutely necessary
• You only demonstrate it privately
• Your only feedback is from influencers seeing a private preview
• People aren't paying for it (or you're not monetising it in other ways)

Of course, there will be some who read this (and probably don't get this far) who will claim that they use the term MVP to mean a prototype. If everyone using the term understands it the same way, then this may not be an issue. But if you start using terms beyond how they were originally defined or intended and you haven't verified that everyone you're communicating with understands this the same way, then there can be confusion, which can lead to wasted time/effort and broken assumptions.

Resetting the experimental instance of Visual Studio has changed in 2026 (v18)

Updated Jan 7th 2026 -- see below

If you build extensions for Visual Studio, you'll know that sometimes (frequently?--depending on what you're doing) it's necessary to completely reset the experimental instance to get it back to a known/good state.

With previous versions, it was possible to start typing in the main Windows menu and it would find the command to do this for you.

This was possible because the menu included entries for just this command:

(Note that I have multiple entries because I have multiple long-term support versions installed for testing.)

However, VS2026 does not include these menu entries. (Who knows why they were removed...?)

Instead, you can (must) trigger the resetting of the experimental instance from within Visual Studio from within the Feature Search. Simply start typing the command in the search box, and it'll find it for you.

Note. I couldn't find another way to access this functionality in VS2026. If you know of one, please share it.

UPDATE - Jan 7th 2026

I can no longer get the above to work, as the feature search no longer finds the option.
I asked Copilot and it said the only way to do it was via the command line.

Take this with a pinch of salt though, as the above includes incorrect information about the version number as VS2026 is version 18!