[fdgsdfogijq]

This is common, and so is the 1-2 years experience dev churning out a ton of code. It gets work done and builds credibility, but then they make some glaring architectural mistake thats tough to rip out. PM can't see it, and eggs the dev on to keep delivering. Sometimes this is great, sometimes not. Depends on the company and the needs of the tech stack

[lowercased]

Further to the point above, the 20 year old in this story does not actually deliver anything. But his protestations about 'slow' and 'legacy' and 'best practices' are like a siren song to some other non-tech folks who keep saying "well, sure, we don't want to be slow - we want to scale - let's do what $person is suggesting". Except... nothing gets done. Months have gone by with no measurable progress, but lots of 'review sessions' identifying $newStackX as the gold standard.

If someone wants to challenge or push back on decisions I make (for example), you better be able to deliver something a) good or b) fast. IDEALLY both, but... if you give me POC code quickly with obvious issues BUT demonstrate some improvement - that's great. We can iterate, if it's quick. Give me some fully fleshed out measurable improvement that takes a bit longer, but has some tests, docs, etc. That's good too.

Sit around and just continually 'back seat dev' on stuff I ship, while literally being incapable of delivering working software of any size, or even supporting your own stuff that you think is 'awesome'... we won't be in agreement on anything.