I’m often surprised by how software developers make life difficult for ourselves by not taking a step back to identify what is keeping us from focusing on writing and testing production code. Problems almost always arise because we haven’t set up a proper test environment where we can test new functionality comfortably. The most extreme case is when the only way to test something is in the client’s production environment! Just mentioning it makes my skin crawl, though unfortunately I’ve experienced and witnessed it several times.
When I start a new project—even if all I want to do is try out an unfamiliar technology—I first set up an environment where I can work comfortably. Otherwise, we’ll add the hassle of an uncomfortable environment to the usual challenges of fixing errors and making progress with things we don’t yet know well. In other words, we’ll spend more time dealing with the environment than creating useful software.
For example, lately I’ve been doing some proof-of-concept work, implementing modules in Node.js that access a MongoDB server. The first thing I did was create a virtual machine running Ubuntu Server to host MongoDB. Once I learned how to clear all its collections and perform the basic administrative tasks needed for my tests, I could do everything else much more quickly and comfortably—and, above all, in just a few steps.
This may seem trivial, but if I didn’t do it this way and couldn’t perform these basic operations easily, making progress with my Node.js tests would be very difficult. I’d get fed up and give up sooner rather than later.
The principle I love applying here is that repetitive tasks should only require us to do the work once.
Exactly: I spend a little time at the beginning creating a work environment comfortable enough to let me focus on the tests or on whatever matters most in the work I’m about to do.
Not long ago, I finished a book I really enjoyed: The Compound Effect by Darren Hardy (the Spanish edition can be ordered here). It is about how small habits and small actions, maintained consistently over time, can make a huge difference.
Similarly, what would our work be like if every time I wanted to run test X, I had to spend five minutes clearing a database, starting services, and so on? How much time would we waste using an editor we don’t fully know? How much time would we lose if we had to test something by reading the result in a .txt document? To be productive while writing the production code we’re working on, we need to create simple and efficient environments. That will probably take some time the first time around, but we’ll more than recoup that small investment of effort and time later.
Once again, we see that even a skilled, experienced, and competent professional software developer won’t score a ten if they don’t build habits and working conditions that let them work comfortably and efficiently.