The reason that first-in people are more productive is they are witness to all of the initial assumptions and initial architecture, they decide and understand how every corner of the thing works, and they understand how to refactor it quickly and change core pieces of the pipeline. By the time other people join later, there’s a whole bunch of dependencies that make it both difficult to understand the whole system and time-consuming to change - a core piece has subsystems that depend on it, and each subsystem has unit tests, etc. etc.. People who don’t have familiarity with the entirety of the system have to make small changes and tread carefully, and this is almost completely independent of the skill of the programmer.

The strongest example of this is when I built a codebase with a partner for a cloud service in a year, and then sold the company to a group of engineers that I believe are probably better than I am. It took them much longer, several years, to get to the point where they could swap out and rewrite major features. But it’s absolutely clear to me this wasn’t because I’m more productive than they are, it’s because the system complexity was high, learning what I did and why took a lot of time, my documentation was sub-par, I wasn’t around enough and able to help them understand what I did.

BTW did you try to get other programmers involved? Is it possible part of the issue was doing too much solo work and not communicating enough? Not saying this has anything to do with you, but I’ve known and managed some very highly skilled programmers that are difficult to work with despite their apparent code productivity. It just means that skill and code output are only part of the job, and high skill can’t always overcome other issues.

I don't necessarily buy GP's story, but it's not the same story as "reading up and extending a system is harder than making a system", where group B would have a different starting point as group A.

One developer makes a system in N months, a team of people is hired to rewrite it, it takes 2x or 3x the amount of time. A tale as old as time.

It is kinda obvious from the get go that it would take more time. With 19 developers there is a much larger organisation and communication overhead. If there's more managers, then means A LOT of bikshedding. In enterprise, there's probably someone responsible for the architecture, there will most certainly involve architecture astronautics "to help developers move faster", which will invariably make them slower.

My 'hack demo' was far more 'advanced' with respect to functioning stuff than the winning team, who faked a bit of their presentation. They had a lot of stuff, and a good idea, but... in 2 days, there's not much time to make decisions. Showed a demo after a day to a few others - someone from the eventual winning team kinda smirked and poked a bit of fun, making some comment about how we weren't all that far ahead of his team. I replied back that I was the only developer, and there were only 3 of us, and .. got a small jaw drop from him.

We simply didn't have the overhead of the other teams. We had someone with an idea, discussed in a small team, and me implementing, and I got to say 'no' to a whole lot of things that, in a larger team, we'd have tried to split up and hack on in parallel.

I'm not at all saying the questioning isn't valid - we don't have enough context to know definitively what conclusions to draw. BUT... a small group of people (or individual) with the right tools, aptitude, motivation and time can accomplish a whole lot more than many people assume.

The part about having one dev doing most of the work is even suggested in the book. But of course it's something impossible when "everyone is replaceable" is a requirement for modern businesses.

> I got to say 'no' to a whole lot of things that, in a larger team

That's one of the #1 tricks of writing good software for fast and cheap. Engineers get to say no to stupid shit from product/design/management/C-level.

That individuals can truly develop amazing things which most teams could only hope to reach shouldn't be doubted. Plenty of solo projects with absolutely astounding results exist to prove the opposite. Enough that one could argue they fall outside the realm of 'they are geniuses with a rare talent'. Management types like to pretend developers are idiot savants capable of programming, but good developers are far more than that.

Bring in a junior developer in the middle and you're gonna have to train them, slowing down the process. Bring in a new senior and he might not slow you down, but won't be productive for a while. Bring a designer and that overhead becomes even higher. Bring a second designer and it's even worse. Another stakeholder? Same deal.

Dailies and Retros are too crowded? Divide the team in two and bring another manager? Same deal.

Software is hard. Head count doesn't mean speed. In fact it often means the opposite.

EDIT: About solo devs, it's funny that in HN there is a bit of a cult for good developers that manage to make things useable for others, and that includes everything from products to libraries and languages. But as soon as someone tells a story about someone or some team being unable to take over a solo-dev work, their work is immediately treated as if it were complete garbage. One thing that made me a better developer was stopping having this attitude. Maybe the reason I can't understand is that I am the one who's not good enough.

EDIT 2: Btw, sorry if my tone sounds as if I'm disagreeing with you. I’m not! I also don't think you were doubting the OP. It's just that I keep seeing this industry making the same bad assumptions about team-size, year in year out.

'More' meaning in every non-technical context. More paper, more communication, more heads to count, etc.

I worked in a Softbank startup that start hiring like crazy for positions that weren't necessary, because that's what Softbank asked for. It was a crazy place to work where anything bringing productivity gains and solving developer pain wasn't rewarded. But, of course, we several people working on developer experience, because there was not enough work for all developers.

On the other hand, maybe this is a good thing. It means more jobs for developers. More money redistribution. But on the other hand it is soul crushing to see something that could be a 2-hour walk on the park becoming a 3-month transatlantic expedition involving several teams.

In the job above, I worked for a few weeks on a team that was responsible for one single screen, and this screen had three checkboxes which we used to update some third-party API. No, there wasn't much more than that. It made me want to kill myself.

However, I really wanted to point out I only gave a single example of something I’ve seen multiple times, I’ve witnessed the same effect (first-in advantage) even with rewrites, and (perhaps surprisingly) even with the same people the second time ‘round! There are lots of potential reasons, but the 2nd time round with the same people is a curious and interesting one, because it says something about our tendency to want to rewrite things and our inability to estimate the time to re-solve the same problems even having solved them before. I’ve seen this a few times, twice (two completely separate instances at separate companies) it was whole-team efforts that ended up costing millions of dollars in delay and the org regretted doing a rewrite instead of an incremental effort.

People often pretend you can. In big companies a new team will “take ownership” of an existing system. But they won’t really understand it until they rewrite it. Wanting to rewrite is not a character flaw, it’s just an inherent part of the process.

That said, if one person wrote the first version, then one person can write the second version. Teams don’t have to get bigger.

Was it actually rebuild from scratch? Rebuilding and taking over maintenance and support are two different efforts.

Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? Why was it so hard to hand over? Are we certain that documentation and training was sufficient for it to succeed?

Was ongoing support taken into account? Maintenance, new features, patching, monitoring - was it hard, was it clear for others how to approach those topics? Was the architecture easy to follow and pick up by others?

Expecting that others will be as genius as you may be seen as positive aim at perfection. It may also be seen as bad teamwork that will build up costs later on. Companies create standards, use "approved" frameworks and copy-paste solutions because it's then easier to support and require less people with less skill. It's hard to recruit already, you don't have to over-complicate solutions and make it even harder. Then there is a day in which your product dies on production and there is just one person who can figure out what is going on. For me it's a clear sign of poor management and we should all stay away from such practices.

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.

It’s not that managers don’t know who is good, it’s that they can’t do anything about it.

When dealing with capital projects and contractors, however, they had no problems whatsoever giving people on very long contracts hourly rates that weren't just good for their industry, but would have been good for Northern California. I worked for 3 years straight, 40 hours a week, where I was making three times the take-home pay than coworkers with the same responsibilities. And this was after accounting for all taxes, health care, and giving myself more days off than the full time workers did.

Management seemed fine with that arrangement too. Said coworker's direct manager tried to talk to the CTO about the situation. The argument was that if they were happy paying people like me really well, and that they were losing their best FTEs to other companies in a regular basis, that maybe they should pay their best workers a competitive way, instead of ending up with FTEs that just were not competent enough to be hired at regular rates somewhere else. The answer was "If our best FTEs are getting poached by west coast companies, this means that we are good at training"

Remember the story about how some government agencies in charge of building things are getting hollowed out, losing all expertise, leading to very slow, very expensive projects being mostly handled by consultants? It's how it works in software for a big percentage of private sector firms that were already big in the 1970s.

The irony is the same companies can pay 3x the comp for external consultants.

I once worked for a university during a large ERP migration.

There was a mix of employees and consultants working on the migration.

Everyone that the university managed to hire (at salaries WAY below-market price) was almost immediately snatched and started working as consultants themselves (in other companies, obviously). And rightly so.

Sadly, 90% of them just quit before there is even a chance to give mid cycle raise.

There's a trust factor. For some reason, upper management doesn't necessarily trust the judgement of their lower management, like like lower management rarely trusts the judgement of their engineers.

There's an information disparity. Upper management often doesn't see what people on the lower rungs of the org chart are doing. To upper management, it looks like the one who's getting all the things done is lower management, not the engineers.

There's also a psychological factor. For some reason, humans are much more likely to overpay for something new than to pay far less to maintain something old. I'm not entirely sure why, but I see this mentality affect everybody from upper management to engineers to people buying cars.

There's also the ego factor. I've seen some business owners react very, very poorly to having an employee request a raise. It can be perceived as somebody trying to take more money out of your pocket for no return. This can also be applied to larger companies and budgets, bonuses, etc.

There's also the "fiefdom" factor. Your management might see expanding your team from 1 engineer to 19 as an improvement to their social standing in the company regardless of how much money it costs the company. The larger your department, the more important you're perceived to other departments and the c-suite.

edit: spelling and clarity.

Most of the tech industry is built on easy money. Fast growth which required little effort.

All of these people think that they worked hard for their money, but what they call 'hard work', I call 'easy peasy' and what they call 'very risky', I call 'low risk'.

99.99% of the population would probably turn to communism if they had worked as hard as I did for so little reward... That said, my stance is apathetic. It's all the same to me.

If you can get by in one hopelessly crooked system, you can probably get by in a different hopelessly crooked system.

They should have their own judgement on the effectiveness of their direct reports. The problem is that they trust their own judgement while having poor judgement themselves. Trust could also be an issue but assessing effectiveness is something gained over time, not self-declared.

I’ve always seen it as an offshoot of the mentality that fixing something old is often delaying an inevitable new purchase (especially when it comes to tech). Total armchair theory based on how if it’s limping along usually they’ll go “well just keep using it we’ll upgrade later.”

Labor is a cost center to be minimized for a business.

Your goal is to make money. If you can do that by having $0 in labor costs, then you want to.

The reason programmers aren't paid in proportion to their productivity is the same that every other profession also is not.

You get paid the least your employer can get away with paying you, not what you "deserve".

It's better if everyone recognizes this.

You probably want to avoid companies where the incentives aren't in place for you to grow.

This approach works only for stuff that won't give you 2 week notice because they have got 10% raise elsewhere.

In a real world it would be akin to buying a new car when current one suddenly stops working instead paying for routine service. Maintaining a car is also "a cost", and you can drive it for as little as you "can get away with".

The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company.

Why should management optimize for improving you? Management is planning to job hop to a better future just like you should be doing...

We do not live in a utilitarian utopia. The world is not optimized so everyone helps everyone reach their full potential. The people at the top are selfish - by virtue of being selfish, you're more likely to get there.

Sure, it's easy to rise to the top if the tide lifts everyone to the top. But most people get to the top by stepping on everyone else's head.

It's worth calling out that this is not an absolute value. It's definitely the predominant one, but businesses can and do exist where the core motive is to make sure that everyone working for the company shares in the success of the company equally.

And I think it is past time to be challenging that status quo

I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors.

Replacing one of these with a proper application can take a year.

I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence.

When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.

They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.

I used to have some imposter syndrome because I wasn't that hyper productive, but not after having to clean that code up.

For example, I found a supposedly queue-less parallel map / threadpool with 2 or 3 queues inside of it, which had weird deadlock bugs that would result in strange occasional timeouts. I replaced it with a parallel map with no queues built on top of a thin and standardized threading library. The deadlocks went away. The resulting code was pretty boring in readable. I never bothered to dig into why the old code deadlocked, but throwing it all away fixed all the problems.

It is a lot easier to greenfield where you can put off the edge conditions till later and focus entirely on the first 80%, it is also really easy to greenfield when you focus on just typing as fast as you can and spray sloppy code everywhere (actually sloppy code like that crazy parallel map implementation I threw away). I suspect the latter is what a lot of "10x developers" actually are.

It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.

And longer time is not a good indicator too, since previously op may cutting corners to make development faster.

However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.

there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 engineers to do it, you wouldn't be posting the same thing.

Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...

The rework was driven by a desire to move an existing web application to mobile. That was fair enough, I suppose. Given the market they were trying to go after I think that was a reasonable choice. But alongside that it was decided by the powers that be that the entire backend, which was already well abstracted from the frontend and would have transitioned to mobile quite nicely, would be replaced by Firebase to speed up development for the team of junior frontend-focused developers it hired to build the project. That choice was far more dubious, but the leaders were convinced it would speed up development and allow them to hire cheaper workers.

The initial prototype of the rewrite was stood up impressively quickly. However, the weight of the technical debt accumulated during that time saw further development start to crawl to a snail's pace. For example, every little new data access pattern that came up revealed that the database (Firestore) wasn't structured effectively for the use case requiring a lot of work in constantly massaging the data. The automated test suite found in the original was also foregone in the rewrite, which multiplied the manual effort required to verify every change. And there was, simply, a much higher defect rate. Months upon months were spent just fixing bugs.

Long story short, new leadership wanted to focus on mobile and thought they could do it faster and cheaper switching to tech that low-cost developers would be capable of using. One reasonable, in my opinion, choice followed by a whole lot of bad choices. Perhaps that falls under political/ego reasons, but I'm not so sure. The intent was sound, but the execution fell flat.

They're rebuilding it from scratch. The documentation needed to build a system from scratch should be provided entirely by management, product managers and product owners.

Should developers write some documentation? Sure. But "how to rewrite this shit from scratch" is not the kind of documentation developers should be writing.

Talented people do exist. And untalented developers are more common than talented ones. There's no reason to doubt OP or to call him a shitty documentation writer just so it matches your world view.

- I was not ever told to write documentation, never given time to do it, and was working around 100 hour weeks, almost all spent coding, under tight deadlines.

- I'm a senior developer / Architect with 25+ years experience and a degree in Computer Engineering from a top school

- The 19 people who replaced me were almost all right out of coding camps with 1-3 years experience

Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.

The 19 people were all right out of coding camps and each had 1-3 years experience.

The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.

The rewrite was warranted because so much stuff (API, UI) was changing entirely due to external forces. What it actually did (from the user's perspective) was pretty similar, how it did everything needed to be different. I didn't write it myself again because I was busy with other stuff.

There were numerous reasons it failed (we can say failed because the customer ended up going elsewhere). Devs were inexperienced, overconfident, chose inappropriate technology for the problem and wouldn't listen to advice. There was nobody in a tech lead position on the project (CTO at the time constantly spouted nonsense about "self organising teams") so everybody spent their time shaving their pet yaks and hoping other people would handle the difficult/boring bits. Deadlines were repeatedly issued but had no bearing on reality so everyone knew they'd be missed - thus they were meaningless.

Then after this transpired, it was up to the team to make all the APIs available to this new pretty-much-finished app and for it to be wired and polished into a "production ready" app. This process, along with all the unfinished, badly written, tech-debt ridden crap, took a year. Barely months in, simple features by this wunder-dev took weeks, incessant complaints about tech-debt by said dev, endless meetings and hand-wavy excuses about how "no we can't do it that way, it's not the angular way, and you don't know JS so shush!".

Countless angular upgrades and package updates with breaking changes, renderer this, web-component that, cordova that, do we support react, oh we didn't make it mobile friendly cause we can use native component libraries, oh crap we have multiple repos zomg now we need Lerna to compile our app, what about events let's use an event bus on the FE, and on and on, with no end in sight. It's years later and it's still being supported as if it's the holy grail, all while it continues dragging down actual feature dev. All this for a couple-dozen screens.

If the company had a more long term mindset, they would have been allocating something like 3x devs continuously the whole time, so that when the original dev quit, there was no crisis.

But… they didn’t. I’ve seen this kind of short term thinking up close plenty of times. Nothing to do with documentation quality.

You can see why I wanted a raise.

(Of course it's also unknown whether that decision was a sensible one, whether it was forced by external pressure like API changes despite the stability and maintainability of the original system and whether the OP's software possessed equivalent functionality to its expensive replacement. All we know is the choice to create the software again from scratch was, to some extent, influenced by what had already been created)

Probably the shittiest job I've ever had. Asked to build a system in a year with no pre-defined scope or requirements (which I complained about in advance). Told them I can build something in a year.

Of course they weren't happy about something because they wanted more. Told them to go fuck themselves.

Frankly, I should have seen it coming before the project started. Fixed budget, no requirements or scope should have been a giant red flag in hindsight.

I wonder what happened to that.

Their requirements were pretty clear to me: they want to have a cake and eat it.

That said, I've written software that I would expect would require more engineers to keep around long term, in production. Better testing, security, reliability, scalability, maintainability. I can say this without disparaging my own work (well, I probably deserve at least a little criticism) or the people who took over the project.

Some software developers are really ingenious but a bit too undisciplined, great at understanding the business environment, and good enough at overall coding and architecture that what they build can be put into production without great risk or reliability, albeit with notable technical debt. In short, they actually build the tire rope swing,and without this kind of developer, the tire swing will never be built. It simply will not result from the 19 developer team you mentioned.

But it takes a very different kind of discipline to convert this into something that can work long term, and sometimes people are genuinely shocked to discover how much it will actually cost to make that rope swing safe and reliable in the long term.

By the way, I do want to make sure I emphasize that this isn't necessarily what happened in your case. Based on past experience, I have little trouble believing that you were simply replaced by a very expensive large team that didn't accomplish as much as you did along almost every axis, from maintainability to security to business relevance to innovation.

We were building a bank based upon a highly complex microservice architecture running on Kubernetes and other complex software. The team they gave me was essentially useless.

I asked to hire more senior developers and they said it wasn't in the budget.

So most of the time, it's more about some specifics of the job - with a specific job title (like "Lead Dev" instead of "Dev") - or the number of year of "experience" (actually : in the job). These are not really related to productivity but it's objective

Be honest - did you write an overcomplicated piece of code that was super hard to understand? Because I know really good programmers that overcomplicate stuff and it takes a team to unwind their work. I respect these people, mind you.

Not the person you asked but I have definitely done that. Usually writing overcomplicated code means you don't understand that particular domain/tech well enough and there may be no one else around to ask.

Half way in you realize you took the wrong approach. Now you have the difficult decision of sunk cost a fallacy here or not.

The correct answer may not be obvious, sunk cost isn't always a fallacy. I have definitely made wrong decisions here in the past and wrote bad code.

But sometimes the decision is ship something or nothing?

We weren't building some little website. This was actual people's money on the line.

It's specifically why they hired me, since I have a history of writing secure fintech software.

But they royally fucked me over, abused me, and burnt me out. So I left.

So assuming you are still playing the employment game, maybe next time you can make arguing for you easier.

Was the code that bad?

This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.

Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.

When I once saw something like this it was "We just got a whack load of investor dollars for hiring" coupled with a belief that moving to a PaaS, requiring a rewrite to support that new infrastructure, that was purportedly easy for inexperienced developers would allow them to hire literal high school students (some quite amazing, to be fair) on the cheap and thinking that more developers would equal more output.

The original product was built on Postgres, and when I questioned the move away it was explained to me that hiring someone who understood how to work with such systems (the PaaS provides a document database that indeed does make it really easy to get data into it) would cost four times more than the juniors they were hiring. Four juniors over one senior was considered a good tradeoff for the business.

And it probably was for the first month or two. The early work was pushed out much faster than a lone dev would have ever been able to. But it wasn't long before the technical choices started to fall short, in particular the document database not being suitable for the workload, which ground velocity to a halt once the easy work was done. Eventually the project shrunk down to a couple of senior devs that were hired to untangle the mess.

One time, the company split into two: One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.

I was able to refactor and improve the "bad" code without much trouble. I'm pretty sure the reason it was deemed so bad was because certain engineers didn't actually try to work with it. They got offended by it quickly and gave up.

The rewrite failed btw - when I left, they were about to rewrite the rewrite (they had recently hired a new CTO).

The "bad" code brought in millions of dollars. It might still be doing so lol.

I was pretty junior in my career when this happened. It taught me that most senior engineers are posers. That generalization has only been reinforced as I've gotten more experience.

My employer is doing this now. I'm on the maintenance side. I am not refactoring it quietly, yet. I am quietly supporting the rewrite team, although I won't get credit for it.

The 'bad' code makes us money today. The new code costs us money today. I doubt it will ever be better enough to pay for its own development. But that does not seem to matter. Mgmt wants to be like google. Mgmt wants a bigger org.

Not much I can do except to keep the money coming in today.

Started on the rewrite, noticed it wasn't gonna go anywhere, asked to switch to maintaining the money maker.

Didn't need to refactor much: the code quality was VASTLY superior than the new system. However I not-so-silently worked on a redesign.

After four years not working there, the old system is still running full steam. The new one was shelved.

As others have pointed out, just like in software, we have to be cognizant of the career risk of hitching one's wagon to the product that's going out the door.

A team of around devs 5 (some coming and going) having been trying to solve the same problem since, but they're still not being close to finished.

In other words, the productivity is in the order 50x to 100x slower than when I did it. Rather, the main reason was that I knew how to write code like that, while they were set up to fail.

Basically, some architect was making all sorts of unnecessary demands for how to wite the code, and the programers were not familiar with much of the tech stack that was introduced.

Also, coding standards were really verbose, easily 10x-30x what I wrote, in lines of code. The current state of what they have look suspiciously like FizzBuzzEnterpriseEdition:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

TLDR; Incompetent tech leadership prone to cargo-culting, can slow down productivity to virtually zero. In some cases, productivity can go up by ~100x if ignoring their demands.

The bandaid had to be ripped at some point. They should have added resource over time though to take pieces bit by bit.

But it was a horrible experience that nearly killed me. Not interested in doing that again.

It’s sad, bc people do understand the difference with other people.. sports, singing, poker, etc etc