I believe its referring to unit testing. The more of your codebase that is covered by unit tests, the more code coverage you achieve. In a perfect world, you write unit tests that cover 100% of your codebase.
Regarding Number 4, I believe it’s more appropriate to learn more patterns and understand how technologies work. But then, I have issues (http://www.codeflux.org.uk/2013/08/why-i-dont-like-frameworks-and-xml.html) with third-party components which black-box something that should be very simple while adding heaps of overcomplexity to satisfy all plausible (and consequently many implausble) use cases. DI and IOC, for example, are incredibly simple. I have the implementation of such a pattern in fewer than 160 lines of code, and it throws meaningful exceptions. And that’s not because I write twiddly, complex code. It’s because of Points 11 and 12 which are missing from the list:
11. Write simple code (Don’t overcomplicate it.)
12. Reuse reusable code (If you find yourself doing the same thing twice, put the code into a separate assembly and share it between the projects – or solutions.)
Stephen Haunts { Freelance Trainer and Writer } 
Hi,
“increase code coverage by 1%”
What does this sentence mean?
I believe its referring to unit testing. The more of your codebase that is covered by unit tests, the more code coverage you achieve. In a perfect world, you write unit tests that cover 100% of your codebase.
Regarding Number 4, I believe it’s more appropriate to learn more patterns and understand how technologies work. But then, I have issues (http://www.codeflux.org.uk/2013/08/why-i-dont-like-frameworks-and-xml.html) with third-party components which black-box something that should be very simple while adding heaps of overcomplexity to satisfy all plausible (and consequently many implausble) use cases. DI and IOC, for example, are incredibly simple. I have the implementation of such a pattern in fewer than 160 lines of code, and it throws meaningful exceptions. And that’s not because I write twiddly, complex code. It’s because of Points 11 and 12 which are missing from the list:
11. Write simple code (Don’t overcomplicate it.)
12. Reuse reusable code (If you find yourself doing the same thing twice, put the code into a separate assembly and share it between the projects – or solutions.)