But if the handover was unsuccessful, it can call into question the skills of that developer. I mean, instead of being a "10x" developer, maybe they were actually a 1x developer that look a lot of shortcuts and wrote unmaintainable spaghetti code (or somewhere in between). Maybe they were someone who hoarded domain knowledge and refused to share it. In any case, the employer didn't realize the claimed value of that employee's work.

Which 90% of the time for anything but features and UI appearance is no value.

That allows the construction of micro-empires and dependence. Orgs either recognize that and provide resources, or they rely on shorter-term one man hero efficiencies, and pay the piper later.

They paid the piper later.

And who knows what "19" means. 19 offshores, so that's more like 6x the cost? And offshores are probably short term so they assume they'll hire one or two offshores long term which will ... maybe ... eventually get cheaper.

That's the beancounter logic. So they think long term they saved money.

It is a mutual responsibility. More often then not I've found that my manager, coworkers, etc. didn't ask any questions about my work during my notice period.

I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.

Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti code.

I think they’re saying it is not up to the developer to make sure it happening writ large/that there is a system in place. That’s pretty much why we have managers and processes in place that everyone follows beforehand (ideally). If a company doesn’t implement systems, it’s not really up to me to do it. Often I will because it makes my life easier and I’m not a rigid “not my department” personality, but I’m not going to feel personally responsible when they drop the ball and wanted to plow ahead without putting the systems in place upfront. Especially because this often happens despite folks bringing up the need in the first place.

I always strive to make my code simple and readable, but there's a saying that "one person organization is another hot mess".

I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.

After their last day, if they were fired, all bets are off.

Sorry but bets are also off once an employer gives them the middle finger, like in this case.

If someone is admittedly trying to pay you only the minimal amount possible, it is completely reasonable that you also work the minimal amount not to be fired or sued.

It goes both ways.

Surely I don't need to tell you why many people opt for a day-by-day basis instead. Play stupid games, win stupid prizes.

We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.

I once build a budgeting and estimating tool (for architecture). Super simple, just worked. The PHBs brought in consultants to "solve the problem". Two years later, my tool was being used on the downlow, like some kind of contraband, because the replacement never worked.

Another time, another place, I was brought in to rescue a project. Four devs spent about a year on an enterprisey monstrosity. It wouldn't even compile. Once I understood the task, I banged out a tool, using node.js & AWS for the first time, in two weeks. Then another 2 weeks to get into production. Clients were ecstatic.

I have many more examples.

FWIW, I'm a very average programmer; I just try to solve the problem in front of me. But I like to think I'm really good at requirements, analysis, customer communications, etc.

This goes so much farther than people think. So many people think that if they learn to write code, they'll be effective in this line of work. Writing effective code is one part of a balanced skillset necessary to do good work.

however other than that if OP isn't lying I can't see any way how a 1 vs 19 situation is anything but a failure for the company lol. maybe 1 vs 2 or 1 vs 3.

This is a good question. It could be either that management is incompetent or that the code was unmaintainable. But still, the fact that it took a team of people much longer to build does prove a point. For projects of this size, it's difficult to build them fast unless the code is maintainable, even if it's just a team of 1.

There can be some extreme cases of corner-cutting which can deliver fast short term results but even this has its limits. The complexity or security issues tend to catch up with you quite quickly.

They had many problems.