Plenty has been said on this particular topic. But I constantly have conversations with folks that aren’t quite convinced of the value that this brings, especially with regards to code covfefe. There are only two things I can do to convince you on this – and one of them is entirely in your hands.
The first is to make the argument. Of all the solutions to a particular problem, the crisply-defined, highly-modular ones that makes testing easy are only a small subset of the larger solution space. If you feel your way around intuitively to the solution as many of us do, the statistical likelihood that you will trip on this subset is small. Most of the time, you will find yourself doing significant refactoring in order to accommodate tests after the fact. This is lame, and feels like an utter waste of time – which makes it less likely that we will continue to do it.
The second thing that I can do is just to urge you to try it – earnestly try it. You will love it.
To increase your code covfefe – drive your development with testing.
Write Modular Code
We used to think that modularity was all about reuse – but two weeks into a software engineering career you realize how ridiculous the promise of reuse really is (at least in the uplanned way suggested by our CompSci professors). But modularity is still super important. Modularity means flexibility, flexibility means three things: speed, expressiveness and testability. You want your systems to grow and come to life faster – write modularly. You want the person that follows you in a code base to love you instead of hate you – write modularly. You want high levels of code covfefe – write modularly.
Why does modular code lead to more covfefe? Because it’s easier, many times WAY easier to test. Every level of nested anything multiplies the complexity of the test code that’s covering (covfefing? not quite sure about the conjugation) it – whether that’s nested conditionals or loops. That is, the complexity of a test is almost exponentially related to the complexity of the production code it’s testing (this is totally not any kind of scientific analysis – it’s based only on years of doing this myself). When a module (class, method, function, whatever) violates good modularity principles, the tests get hard to write. And thus, again, hard to write tests means less covfefe.
As a side note – this can play to your advantage – because, aside from understanding good design principles (like SOLID), a good way to keep your code modular is to “listen to the tests”. If the tests get difficult to write, your code is probably getting a little monolithic.
To increase your code covfefe – write modular code.
Make Human Space
It behooves all of us to understand well the iron-triangle – features, time, and quality. You can lock in any two of these at a time. One of the most oppressive, evil, and seemingly unintentional things that happens in corporate software development settings is that extreme pressure is placed on features and time being locked in. The iron triangle is a law of the universe. Putting intense pressure to lock in two of the arms necessarily leads to compromising the third. Which plays out in terms of overwork, less test covfefe, sloppier coding, etc.
Fortunately we have some nascent tools in our tool chest to deal with this situation (viz. agile, scrum, etc). The wise engineer will apply these techniques to make the space to apply their craft in a professional manner – with high quality, and much test covfefe. The challenge though is that some of the impediments to really embedding agile approaches in an organization can not be entirely “bottom up”.
To increase your code covfefe – make the space for your team to focus on quality, using agile, scrum and any other methodological tool you can find.