I'm a big fan of async/await and I can appreciate what it achieves in terms of helping to prevent coding errors. I've rewritten an entire open source WebSocket

I'm a big fan of async/await and I can appreciate what it achieves in terms of helping to prevent coding errors. I've rewritten an entire open source WebSocket framework in async/await, so I know exactly what the benefits are. But in spite of that, in the grand scheme of things, I still think it doesn't really matter. The architecture of the project is much more important. I had been working on that project for 3 years but migrating it to async/await only took me about 2 months of casual after hours work. The reason it was so easy to migrate and that I didn't have to write the project again from scratch is precisely because the architecture was correct to begin with. When you think about code quality in terms of how much (or rather, how little) time it takes to maintain it to adapt to industry trends, architecture is by far the most important factor. Because even if everything changes from underneath you, a good architecture will survive the test of time. Any other metric to measure code quality is arbitrary and meaningless IMO. It's mind boggling that my previous comment received downvotes. I guess it reinforces the point that the author of the article is making. The average developer is incapable of understanding what is important. If people can't articulate what their goal is and they don't know what is important in order to achieve this goal, then there is zero chance that they will be able to make the right tradeoffs. Because there is no free lunch, every decision is a tradeoff. If, like for the vast majority of projects, there is a good chance that the requirements will change significantly in a year or two, then you need to know what really counts and architecture is one of those things that can stick if done correctly.