This is the reason that I say that most people need to learn to code, even just a little bit. Regardless of what career path you choose, it's highly likely that you'll at least use a computer for some of it, and being able to write macros or simple programs to automate things can make you stand out from your peers.
I'll tentatively agree, with the reservation that I would like to see some studies on the effects of this before we go all out teaching everyone to code a little.
My concern is that while macros or simple programs would let people do things more productively or do things that would not be feasible manually, they also let them make bigger and more costly mistakes. We need to figure out how to get the former while minimizing the latter.
Code can also stop manual errors from creeping in.
This spring, I put together a graphic novel. When I was creating the list of source files to drop into InDesign's batch processor (a tedious task that involved full file system paths to a bunch of sequentially numbered files), I left one out. I managed to miss the forest for the trees when proofing, and didn't realize I'd made this mistake until I was sitting down to relax and enjoy reading the advance copy. With 399 more sitting on a loading dock waiting to be shipped to me.
I had to do a new print run; this cost me about $6000, which pretty much puts the Kickstarter for this volume in the red.
I also wrote a simple little script that I can point at a directory full of files, and get a CSV of everything in it to feed to InDesign. I will not be making this particular mistake again on a larger project. There will be other ones, I'm sure. And I'll try to find ways to automate stuff I can, and improve my proof reading process as well.
You are going to make mistakes. By hand, and in creating automated systems. This is a fact of life.
The thing I like about making automated mistakes is that when I fix that mistake it usually doesn't happen again.
I also wonder about the percent of mistakes made.
A long time back I made some scripts to bulk load new employees into our associate management software. Before that it took an admin loading them in one at a time. The admin could probably get one employee entered, give or take, per minute, given network latency. The script had delays and such to not slam the network, but ran in the background. My first version got a field wrong for 90 or so employees, but I just had to do some small modification and it went back and fixed them all.
Basically, I made 90 or so mistakes, but managed to make the mistake and fix it in a tenth the time it took to manually enter all of them, and then that mistake was never made again.
I guess a lot of it depends on how critical correctness is straight out of the gate (like in your case). For our purposes, it was fine.
Part of coding is (or at least should be) verifying results. Anytime I need to build solutions, I spend more time verifying (and fixing if needed) the results. Make changes? Verify again.
Agreed. Automated many reports or information gathering processes the same way. I don't get a medal, but end of year reviews are awesome. Even better is when you share the code or process with others so they can copy it for some of their work .
