Do this one thing if you want your code quality to improve

More often than not, modern day Software Development is not about conceiving algorithms or thinking through complex systems scenarios on a daily basis. Unless you work in a novel systems team, odds are that you will be asked to use Frameworks, APIs and SDKs built by others. This implies trying different alternative iteratively before you finalize your solution. This becomes very true with Data Scientists as we spend a majority of our time writing plumbing code to wrangle data. Since it is hard to conceive beforehand the kind of data the model would require, rapid prototyping is essential to run many iterations before finally arriving at an appropriate structure of the data. This means experience may teach you to trade of fast prototyping to good coding standards. In the past, this often resulted in me writing less desirable code (knowing that I may have to throw all of it away and star over) and spending cycles on refactoring. Eventually, due to the reinforcement of cutting corners, I began to spiral down a path of iteratively worse code and once I reached the final model, I had to spend cycles working to bring my code to production quality. One of my co-workers who has more Software Engineering experience than I do, never seem to suffer the agony of spending cycles to improve code quality; it just took him one iteration all the time. So I probed him over lunch for his secret sauce and he said he would send me a code snippet that would make my code better. So after lunch, I peeked into my inbox and he sent me this:

if(you.require(GoodCode))
{
  you.write(UnitTest); //and as you write the code, test
}

It changes everything

Once I started writing unit tests, my code improved tremendously. I started thinking naturally in the lines of functionally independent modules as I had to write code chunks that were independently testable. In other words, I inadvertently modularized my code. As an example instead of writing a specific cache for my purpose, I wrote a generic templatized cache (that I reused in multiple iterations). Since I have unit tests, adding features to these modules means I could catch regressions easily. Now, I even have my own small suite of class libraries for data scrubbing that I reuse across projects. It is entirely possible that I was the only one to suffer and learn in this business of fast prototyping; if not, I just wanted to share this one tip that changed my perspective.