There seem to be two main schools of thought about what "good software" is. They're not antagonistic, you can have both, but few engineers seem to want to. The first idea of "good software" is the software engineering approach. The focus is on writing clean code that's simple, understandable, fast, and correct. This is the most common one. The second is that "good software" is the "application design" approach, with the aim to deliver a final product that solves the user's problem well. The focus is on things like UX, design, correctness (again) and timeliness (eg getting features out the door so people can actually use them).
To truly master software development you need to understand both, and practice both. Writing the most perfect code in the world is ace if your customer can wait. Building the most beautifully straightforward app is great if it also works properly.
You can't be a productive, useful developer if you ignore one or the other school of thought.
Oh this is billiantly stated. It is fairly rare to have both these traits, and I've even seen in large orgs where ostensibly talented engineers have neither.
To be more specific, some engineers/teams are completely driven by artificial internal metrics (like ticket counts, point estimations, etc) without a concern for technical debt, or the success of the product. Instead they operate sort of like the Chinese Room thought experiment, where they translate literal requirements from upstream, but don't actually think about what that means to a user. Instead they just plug it into known concepts in the system, and wait for the bug reports to come in, then churn through those. Over time complexity builds without hope of refactoring because there is no one to advocate for simplifying the approach as it requires both internal and product compromises. Eventually a tipping point is reached where no competent engineer will touch the system and the question becomes how long business inertia will allow the paychecks to keep clearing.
To truly master software development you need to understand both, and practice both. Writing the most perfect code in the world is ace if your customer can wait. Building the most beautifully straightforward app is great if it also works properly.
You can't be a productive, useful developer if you ignore one or the other school of thought.