I have mentioned a time or two that I work in software. I write code. I am given projects or problems to solve, and I produce computer programs (or fix existing ones) that fulfill the request. Sounds easy enough, right?
Though I’ve been writing code since before I could actually read, my first job in software didn’t come until I was 20. I was not hired as a developer, but rather as a process analyst intern. Being an uncommon job title, it probably bears some explaining. I made charts and tracked statistics for a development organization–things like how many software defects were being generated per hours worked, so that the company could track whether its software quality was improving or deteriorating.
The reports began as documents that I produced manually, but once it became clear to me that the process was easy to reproduce as a set of programmatic steps, I instead wrote a program to gather the statistics and generate the reports on a weekly basis–no longer did I have to do it by hand!
Similarly, I also had a blog way back then, in the early 2000s, when they were still called “weblogs.” Robust content management systems like WordPress didn’t exist yet, so I wrote a perl script which scanned a directory of text files and produced an attractive (for the time, anyway) website for browsing and reading the posts. That meant all I had to do was create the file for the post, upload it to my server, and the program took care of the rest. That’s very primitive compared to what’s possible now, but it was more than adequate for my purposes.
Most recently, I spend a lot of time taking manual development processes and turning them into automated ones. If you aren’t familiar with how software development is done, in the broad strokes it’s not that hard to understand, so I will briefly explain:
1. An assignment comes to a developer who needs to complete it. It could be a new project, an enhancement to an existing one, or a fix for a defect/bug.
2. If the developer doesn't already have a copy of the source code and other files necessary, they will have to obtain it. This may be from a shared file location, or more properly, a version control system.
3. The developer proceeds to perform whatever work is needed. This will likely involve research and/or investigation of existing code, writing of new code, and/or rewriting of existing code.
4. Before turning it over to anyone else, the developer should test their changes. There are many ways to do this, but ideally, the code is structured in such a way that each section of it can be triggered independently with known inputs, then checked for expected outputs. If unexpected outputs occur, or the program crashes, there is obviously a problem.
5. Once the necessary changes have been created and tested by the developer, they will be turned over to someone else. In a formal environment, this would be a QA (quality assurance) tester, whose job it is to verify that the code indeed functions correctly. Once again, the developer needs a way to get their code to the tester or whoever else needs it.
6. Once code has passed testing, it can be slated for release. This may involve packaging the code in a certain way, dealing with upgrade situations, and so forth.
7. Through whatever means, the final package is delivered to its users, and the process begins again.
I have glossed over a lot of detail here, but you may have noticed there are a lot of steps involved, and plenty of opportunities for automation–or, as I like to call it, laziness!
Who wants to bother keeping track of code all the time? A version control system will do much of the work for you, including keeping track of what you’ve changed, and holding onto past versions in case you need to look at old code. It’s also useful for code sharing: you can tell QAs (or anyone who needs it) that you’ve saved your code to the appropriate place, and they can retrieve it on their own. Version control systems can also feed into software that performs automated testing and code packaging, so if you really wanted to, you could release to users with no more difficulty than pressing a button to store your code.
Personally, I love that kind of laziness. I like having tools set up such that a lot of manual busywork is eliminated, handled by computers doing what they do best: processing predictable events in simple, logical steps to achieve a specific goal, over and over. If you’re going to do it more than twice, you might as well teach the computer how to do it!
Nevertheless, I have met my share of programmers who don’t care for this philosophy. I find it baffling, since people who write code for a living should easily be able to see the benefits of automating away much of their busy work. It helps eliminate human error, for one. It saves time, for another–steps performed manually by a person can usually be done much faster by a computer. And well-written automation can also notify you if anything goes wrong, whereas it may be harder to notice if something fails when you’re performing manual steps.
Most programmers already know all this, but I remain surprised when I meet ones who don’t. Lately, I have been working with people who automate next to nothing. They pursue laziness, to be sure, but of a more dangerous kind. They perform everything manually, but do as little of it as possible, so they rarely know what code they’ve changed, or how what’s on their system differs from what end users might have. Many programs may be broken, unbeknownst to them, because they don’t bother with testing–after all, any testing they do would be manual, and they don’t want to bother. It’s a strange attitude and one I have difficulty understanding.
For my part, laziness through automation is a huge plus. I use it to manage backups of important files, monitoring of servers I maintain, moving code from my system to other places where it’s needed, transformation of my code into packages that others can use, and so forth. I have troubleshooting tools that help me investigate common issues I encounter. These all save me a lot of time and make me more productive, both personally and professionally. Sometimes I am amused because my coworkers are impressed with the amount of work I get done–in truth, it’s more because I am utilizing a lot of automation tools while they are doing things by hand. I have been trying to promote such tools as much as possible, and I make significant use of them outside of work, as well.
If there is much interest, I may make a future post with more detail on the automation tools and concepts I use. For now, though, I will say this: if you are doing a job (or any repetitive task) that relies heavily on a computer, whether it involves programming or not, be lazy! Consider automation! Why not let the computer do all (or at least most) of the work?
