The Software Testing Club recently put out an eBook called “99 Things You Can Do to Become a Better Tester“. Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the “99 Things” book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 
Suggestion #89: Learn a scripting language. Use it to automate repetitive tasks or processes. Manipulation of text or data files for example.
I’m going to do something I don’t normally do.. I’m going to punt. Well, not really. See, the thing is, I wanted to see if I could put together a workshop in a simple blog post that would discuss the nuts and bolts of scripting languages and why you should learn them. 
What I realized the several times I was trying to write this post was that this is, for real, not a topic that can be summed up in a simple 800-1000 word blog post. In fact, I could barely sum it up in a 50 post blog series on “Learn Ruby the Hard Way“. Shell programming, scripting languages of any kind, any flavor… just take work, persistence and a lot of continuous and steady practice.
Thus, it’s with that in mind that I am going to talk about what you can do, and share some sites and suggestions I have found to be helpful along the way (from someone who, admittedly, isn’t much of a programmer, but I do what I can with what I do know 😉 ).
Workshop #89: Download and install three different scripting languages, your choice. If you are using the bash shell or another variant, consider that one of the three. Find and address ten different challenges in your everyday work life that you can experiment with (data files, log files, web page downloads, etc.). The catch? Try to use each of the languages/approaches to solve the problem. 
This is what I refer to as the “Secret Ninja Cucumber Scrolls” method. Why? Because they were the first that I saw that made a point to take a topic (in this case Selenium and web automation using Cucumber and various tools) and made it so that each example was made to work in three different environments. There were advantages and disadvantages to each approach, but by the end of the process, each environment was able to accomplish the same task. What’s more, if the user in question worked through each of the examples, they had a better appreciation of just how they could engineer a solution in not just one way, but multiple ways. 
What makes three the magic number? I think because there’s enough natural variety out there with three options that it forces us to “think differently”. When it’s just one option, we do what we have to and if it works, great. With two options, we have to compare why it works better than another system. With three systems, we have to focus on what it is we are trying to solve, and see if we really understand what we are working towards, enough so that we can address it in what will likely be three unique ways. 
So with that in mind, realize the scripting languages I’m suggesting are not necessarily the “best” languages, but they are ones I would suggest for the fact that there’s lots of avenues out there to learn them and frameworks to put into place and experiment with (that, and they happen to be ones I have personal experience with. If others you were expecting to see here aren’t here, it’s because I either don’t know enough about them, or don’t use them enough to be able to talk about them with anything resembling half a brain)…
JavaScript: At this stage, just about every site that teaches programming has a section on JavaScript, and frankly, it’s the most ubiquitous language on the net, and will likely become even more so in the coming years. More than just JavaScript, there are frameworks that you can learn as well once you cover the basics. If jQuery, Angular, Ember, Backbone or Node are avenues of interest, then JavaScript needs to be a starting point.  
Ruby: Ruby is a stable language that has been around for two decades, has a rabid fan base, and is a platform of choice for many production web sites that use Ruby on Rails. It has a healthy ecosystem of tools and add-on “gems” that can be utilized to make many jobs a lot easier. 
Python: Another language that has been around for quite awhile ( I remember first hearing about it in the mid 90s), and has likewise become a popular choice for many testers due to support for Selenium and other testing frameworks. It also has a popular web site framework with Django, and the ability to build web apps and sites quickly and dynamically. 
bash: Wait, what?! You didn’t think I was going to mention a handful of scripting languages and not include my own personal favorite, do you? Yes, I know that bash is technically not a “scripting” language, but work with me here. I think there is a lot of benefit to learning and practicing with the bash shell (or csh, ksh, zsh or whatever flavor you personally want to play with). Not only do you get to work with programming structures that are similar to the ones other scripting languages use, you may find that you can answer in one line of command line code what it might take dozens of lines to write in another scripting language (again, this comes back to the idea of “forget the tool, start with the problem”). 
Javascript (and various associated frameworks): Codecademy, Code School for the basics, with NetTuts+ being a good source for going into greater depth or viewing screencasts on more advanced topics and additional frameworks.
Ruby (and Rails):  Code School has a Ruby and Rails path that, while not free, is pretty comprehensive. Codecademy also has a track that covers Ruby well (just Ruby), and I would definitely mention Zed Shaw’s “Learn Ruby the Hard Way” (you can look on TESTHEAD in the Practicum section and see my own adventure with this book and approach. I found it helpful, your mileage may vary 🙂 ). Also, as Chris McMahon wisely pointed out in the comments, Brian Marick has a great book called “Everyday Scripting with Ruby” with a strong focus on using Ruby for software testing.
Python (and Django): Codecademy has a language specific Python track  and NetTuts+ has a compilation of “The Best Way to Learn Python“. In it are several avenues that you can explore as you practice using the language. Also, though I cannot speak for it directly as I did the Ruby version, “Learn Python the Hard Way” from Zed Shaw is the blueprint for the Ruby book. I thought the Ruby book was very helpful, so therefore I’m extrapolating and guessing that, for those who want to use it to learn Python, it will also prove valuable to those willing to follow its approach and methodology.
bash: there’s lots of places to look for this information, and lots of tutorials that you can dive into (as well as dozens of books), but I personally like the Linux Shell Scripting Tutorial and Advanced bash Scripting Guide. Alternately, a very nice book that gives a lot of great examples and possible jump off points is the bash cookbook (which I reviewed here).
Bottom Line:
Scripting languages, regardless of what you want to refer to them as, are programming. Let me re-emphasize that… 
You WILL need to LEARN to have a TOLERANCE for SOME amount of PROGRAMMING!
There’s no way around it. This does not mean that you have to devote your life to programming, that you have to de-emphasize testing to program, or anything of the sort. You may, even after going through the variety of exercises for several months, decide that you just aren’t cut out to be a programmer. If by “programmer”, you mean a “production level writer of software programs that ship commercially”, then you may very well be right. I’m certainly not. Fortunately, “programmer” means a lot more than that, and encompasses more than just shipping commercial software. 
Scripting languages (and there are many more that I didn’t name here because of lack of my own interaction) have some advantages in that they can be executed and debugged more quickly than compiled languages can be, but the fundamental rules are still the same. Regardless of the language or methodology, some things are definitely going to need to be considered. You will make mistakes. There will be bugs. You will need to find them and fix them. You will need to practice. A lot. For a long time. That is, if your goal is to get good at using these languages. Sorry, no short cuts or simple solutions to offer here, just a lot of training for an extended period. On the bright side, you may find that you start to enjoy the journey ;).