I think developers sometimes get too obsessed with code quality thinking that smarter code makes …

But the code quality is speed. And reach. You can not advance, unless you can read the code, you can understand the model, you can not scale beyond a certain point. The beauty of the architecture is the ability to build a spaceship compared to a train of kerosene tankers. Physically similar, but in capability radical different. I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation. This is literally the difference between rocket-science and exploding failed projects. Everyone can pile up explosives, not everyone can go to space today. Its a great interview topic to filter this kind of candidate out of companies.

It's the opposite, better-factored code makes me, a mediocre developer, capable of making progress instead of hitting a complexity wall. It's separate from striving for "beautiful" code, beauty within well-factored boundaries yields dimishing returns compared to just having the boundaries.

> I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer. Not much about "smartness", but code can by far outlast many "product" sold on top of it, so it can make sense to polish them more than the ready to throw gift paper. People will certainly buy nice gift paper wrapping cheap crap music toy of the day. But they will also value differently access to a beautiful handcrafted musical instrument. On the other hands, people who don’t even play any music won’t be able to assess any musical appliance.

>For example, if you’re building a proof of concept (POC), then it’s more important to prove the idea than it is to define the architecture. I have tried to do this for POCs (just hacking everything together), and I always get stuck very quickly. Then until I figure out some sort of architecture for what I'm supposed to be doing I can't proceed. It's like, once I have the first step (of several) of the a POC working, I literally cannot think of how to implement the second one until the first one is somewhat well organized

If your code is a low-stakes one-and-done and it works in the end, messy code is forgivable. Undertale looks like Yandere Simulator inside; nobody cares. But if your code is something that needs to be maintained over time and/or has constraints in terms of security, availability, etc., like virtually all code is, then yes: clearer, better factored, more readable code is a big part of the product because it's a massive favor both to yourself and your successors when changes have to be made and results in quicker changes, lowered costs for changes, and higher quality on metrics like security. Even if I'm writing a game—I'm auDHD, so if the initial code is garbage (and I've written a lot of garbage code) I'd be loath to touch it later. Better factored code is easier for me to revisit and improve upon with time. So I make it a point to continuously improve how I structure code from the jump …