A piece of software is usually not very useful on its own. Useful software features start when multiple pieces of software communicate with each other, exchange their data, and collaborate on the task of presenting data and interfaces to users.
Programs have to be designed with that in mind. What messages do they accept? What events are monitored? What messages are emitted? How do we authenticate and authorize communications?
Another important aspect of great programs is the clarity of the code, not how many tests there are or the number on the test coverage report. It is the simple question of is this code readable to someone else? Or better, would I, the writer of code today, understand this code a few weeks from now?
“There are only two hard things in Computer Science: cache invalidation and naming things.”
— Phil Karlton
Code readability matters a lot more than you think. Unfortunately, there are no good metrics for code clarity. Memorizing good software patterns and practices might help but are often not enough. Good software engineers just develop an eye for code clarity with experience and intuition. The writing metaphor here is perfect: just knowing a big list of words will not help you write concise and clear content.