The managers don't care either. They are job hopping too.

I won't be surprised if companies with large amounts of vibe coded systems end up blowing up.

> I’ve been a software developer all my life [...] In my experience, [...] no one stays at a company for longer than a couple of years

I feel for the author. Turns out that there are companies where people stay longer. I started my career in startups, where it was exactly like the author describes (usually inexperienced managers asking inexperienced developers to quickly produce bad code, hiding behind the notion that "our biggest problem right now is to raise money").

Then I moved to a "corporate", which I feared because of everything people say about processes and such. Turns out I am given the trust and resources to be a craftsman, and the company cares about my writing maintainable code. Both healthier and more rewarding than being pressured into doing a bad job.

> As far as professional software development goes, change is clearly the most profitable career path: you deliver results rapidly and you leave before it needs to be maintained, which makes sense, because your salary will grow faster if you keep switching jobs.

I understand how it may feel like that, but I think it is wrong. You have to sell your experience (which I count in years of work) and not your number of jobs. If anything, having stayed longer somewhere is something to sell: "I have seen a project evolve over years, I know what is maintainable and what is not".

> This is where the interests of a corporate software developer and “craftsman” software developer diverge.

The author has seemingly no experience in corporate ("in my experience, no one stays longer than a couple of years"), but believes they know what "corporate software developers" are like?

My experience in corporate is that I see more craftsmen than in startups. Startups are full of juniors or bootstrappers who write prototypes (usually not very maintainable) and then move on to the next startup.

> Even at the most generous of companies you’ll be hard-pressed to find a manager that will let you spend several quarters rewriting vibe-coded spaghetti messes without having any immediate profit impact to show for it.

Yes, I agree with that. The trick is to find a company that try hard not depending on vibe-coded spaghetti messes that need to be refactored. If you end up in a project like this, the goal is to leave.

> Does the “let it fail” approach actually work? I have no idea.

It most definitely does not. In my startup years (more than a decade), I have seen many very bad decisions being made "because we're a startup and have to move fast". I have plenty of examples where I said "this is not the right way, it will bite us down the line" but the genius founders and managers (from their 0 years experience but with a PhD that made them geniuses) new better.

Every single time, I thought "one day, I will have my 'I told you so' moment". And I did have that moment, except that the geniuses blamed me for their decisions. They are geniuses after all, they couldn't have been wrong back then. I have seen millions being lost in development because of fundamentally bad ideas (it's easy to measure when the startup has to rewrite the engine from scratch and spends 2 years doing it).

My stance here is that if the management is such that the project will fail, then there is nothing that you can do other than find a new job. Those people don't fail, they just convince VCs to inject more money into their ideas until it becomes profitable (but you don't want to work in that mess of a codebase) or it bankrupts. You don't want to work for those people.

I can understand the frustration, however, part of the skills you have acquired should be taught and shared within teams you work with. Such a skill is meaningful, but the ability to pass on that skill to Juniors is more important than the skill itself.

I am not quite a fan of the “professional software development” elitism in some posts like this because it points to me vs you or highly skilled vs unwilling to learn, which I have found to be not true.

Also to say “attention to detail” while also having grammatical and spelling mistakes in a blog post is kind of poignant.

I have been working at startups for 20+ years and would say the "hack it out/craftsman" dichotomy is the wrong mindset. I would say the more interesting idea of working at a startup is that you can use your experience and nearness to the business objectives to know when you should hack something together vs. "craft it".

But to me, crafting the software is less about making a test suite, robust observability, etc. and more about architecting the code with the right "hard" and "soft" elements.

A DB structure in flux may start out as a JSON field so we can tweak it without hassle. Something that may need to support heavy volume may have more modular and minimal components up front that can be swapped out for more performant ones down the road.

Now if you are at a micro-managed startup where you have no time or latitude to affect any of those decisions, then you are going to have a bad time no matter what. But work at a startup introduces a more flexible concept of "craft" that can be as equally (or more) satisfying than following "best practices" in a consistent way.