Invisible improvement

· by Peter · Read in about 2 min · (260 words) ·

This year alone I’ve written thousands lines of code for various libraries. And I’ve started to write libraries;) Each of my methods is unit tested. My classes are as well designed as it’s possible basing on my current knowledge. I can write new automation script for our servers in the matter of hours (sometimes minutes) comparing to days not so long ago. I’m able to test most of the things before they’ll get on the server, so I’ve almost eliminated vicious cycle of build-deploy-check-fix. I understand my systems better, so often I instantly know where the problem lays. And most importantly I can deploy the same code to test and production environments, so I avoid duplicated effort of testing.

The thing is, nobody appreciates that. And from what I can read online, I’m not alone with this feeling. Things I’ve listed above are essential for every software development and yet nobody seems to care. If it works, it works. If it doesn’t work then there’s hell. Improvements in software are rarely visible, failures are vivid.

But anyway it should be done. Because this is what professionals do. I’ve read a book of Uncle Bob, Clean Coder, recently. And it has opened my eyes. Being professional doesn’t mean doing only things which will be applauded. It’s about doing things which need to be done, even if they’re unpopular or unnoticeable. It’s dev’s job to help people to avoid shooting themselves in the foot. And there’s no excuse for doing things poorly. It’ll kick you in the back, sooner rather than later.