We should build great software.
Great software runs fast. It's reliable. It has a thoughtful design. It respects the end user. It takes time to get right, but the result is worth the wait. If it has preview releases, they're clearly marked, and the software doesn't stay in that state forever.
Making fast software means setting performance goals, and then measuring. It means aiming to speed things up over time, even if adding new features slows things down by default. It means choosing tools that can achieve our performance goals, even if it takes us longer to learn those tools—or to build with them.
Making reliable software means finding problems, and then fixing them. It means using tools that catch problems before the software ships, and also for reporting problems in the wild. It means talking to people about their experiences using the software, to learn things the automated tools missed. Then it means taking the time to fix the problems, even when that delays new features.
There are plenty of other good reasons to make software. For fun, for learning, for art, for pay, and the list goes on. We want to make great software because we want to enjoy great software, and we want others to enjoy it as well. The process may involve some combination of learning, fun, art, and pay, but it may also involve putting other considerations ahead of those. If we aim high and fall short, it should be because we made mistakes by accident, not because we cut corners on purpose.
We want to build software this way. Not because we think it's the easiest way, or the quickest, or the cheapest, but because great software will only exist if someone builds it.