I think it's a bit nuanced, and maybe poorly explained by the original author, but to me, "left-pathers" are always "move fast and break things" to the point that whatever they build really only works as a throw-away prototype, and the effort to architect sensibly is minimal.

"We don't really need to use REST, we can just create some endpoints that have undocumented side-effects. We don't need to abstract vendor calls into a separate class, we can just implement that functionality directly in our endpoint code."

These sorts of decisions aren't actually materially faster, they're just lazier. And maybe that's "a sprinkle of QC"? But it's a lot of unforced errors that don't really save time to implement, and also create a lot of problems later on.

On the other end, with the "right-pathers", you can have people that really try to over-engineer at any opportunity. This is sort of typical of people who have worked in much larger teams. This can mean building out a k8s cluster when you're still a team of 2-3 people, splitting into 10+ microservices, deciding to use Kafka when a simple queue system would work, building out in-house load balancing for dubious reasons, etc.

The middle path is really something that resembles the "Best Simple System for Now" — when I've done this, I think about how I can solve a problem and not have to rebuild it entirely within 12-18 months.

I think it's less a middle path than a third option. I see the type of thinking the author is commenting on whenever there is a tight requirement on a feature. Especially when you know you have to add some custom magic to meet the requirement. People tend to psychologically buy into a fully custom solution early on. So they either hack in a custom solution using abnormal data paths or known bad solutions or they fundamentally rearchitect the system around it. The third path is sketching out the feature so that it's modular and can be replaced. That way you can start out with a standard solution which gets you 90% of the way there then replace it as development progresses.

Maybe it's different in other languages, but if I ever see hand-rolled serialization in a C# project I'm putting replacing it at the top of my to-do list. There is pretty much no reason to do that ever, serialization is a solved problem. It's flat out stupid to spend extra time hand-rolling a solution that most likely ends up buggy and requires even more work in the future etc. I also often see people waste hours or days writing custom serialization logic for a serialization library, when they could have just written a new class in the shape of the data and been done in 5 minutes.

I did work on such a project once. There was a CMS web app which needed to sync data from a third party api to rebuild some pages every night. To do this they had a client library that pulled the data twice daily and stored it in a db, then the CMS app pulled the data through the client library. The API used XML and significant parts of this library were a hand-rolled xml serializer. It worked so I didn't touch it, then it stopped working. Spent days trying to fix it but the more I studied it the more I realized it was entirely pointless. Spent about 1 day replacing the whole thing with a simple little function that just calls the api, deserializes the data using a library and builds the pages. Remove the pointless DB, remove the giant legacy quagmire integration library, this project probably took months to write and I replaced it in a day, making it orders of magnitude smaller and faster.

In the end my solution wasn't used because of office politics, apparently they'd paid a significant amount of money to use this pile of trash and replacing it that easily would make someone look bad or something. So I ended up fixing the pile of crap in the end, even though I had a replacement ready to go.