Thursday, August 1, 2013

Learn to Program: 99 Ways Workshop #27

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 #27: Learn to program, some lines can help so much - Stephan Kämper

I've already suggested that understanding programming, even if it's just to make shell scripts for your chosen OS, go a very long way in helping to understand how systems work. They can also help make programming concepts more understandable and relate-able at a high level. At some point, though, to really understand how computer systems work, it is helpful to learn a bit about actual programming with a programming language, or a variety of them. 

Software testers do not have to commit to being expert programmers, or making programming the core part of what they do. Let's face it, there are many testers who can do some programming and have, for various reasons, decided that it really wasn't what they wanted to do as their primary focus. I'm one of those people. I just reached a point where I decided I was much more interested in seeing how a system performed in its user facing state than I was in making the components that made a system possible. I am also one of those people who has primarily used scripting and programming to do repetitive work for myself, but hasn't really written much in the way of larger programs beyond school projects. To date, the largest piece of code I've ever written manages registration details for a local music festival. I wrote it almost ten years ago. I still maintain it for the festival organizers today. It's in Perl if anyone cares ;).

Having said that, I have spent time over the past 30 years learning how to program in various languages at an elementary to intermediate level. I still remember a fair bit of GWBASIC, QBASIC, Pascal, C, C++, Tcl/Tk, Perl, Java, SQL, Ruby, plus a dash of Python and JavaScript, too. Having been exposed to writing programs in all of those languages has given me some understanding about how many computer languages work, and the commonalities between them.  

Workshop #27: Learn the basics of TWO programming languages (one procedural language and one object oriented language)

I need to give the credit to this suggestion to James Pulley, since he was the one to suggest it to me. The rationale here is that there are two major mindsets and approaches to programming. Personal preference and need may indicate which language an individual uses (as well as where we work and what the developers use), but James makes the case that a tester could learn a lot by just focusing on C and C++. That would provide the minimum requirements, and also show how procedural and object oriented ideas work within related languages (C++ is an object oriented super-set of C). 

It's possible that you may want to pick different languages to use, and that's cool, too. The point is to make some basic programs that will allow you to learn the major language elements, perform common operations, and create libraries, functions and structures (procedural) as well as classes, objects and methods (object oriented). Try to write the same programs in both spaces. If you wrote one procedural program in C, consider what it would take to write an analogous program using object-oriented approaches in C++ (or any combination of procedural / object-oriented languages).

There are a variety of books and online tutorials that will help out with this. Do a search for the language of your choice. Since I've geared my example to using C and C++, for those who want to use that as your basis, Cprogramming has a pretty nice tutorial based approach for C and C++ in one place.

Also, I am very much a fan of the Zed Shaw "Learn Code the Hard Way" philosophy. Zed has a tutorial called "Learn C the Hard Way", which really should be called "Learn C the way most people learned how to program back before the web made ubiquitous copy and paste so easy", but that's not nearly as catchy a title.


Bottom Line:

Each language has its own quirks. Each language will do things that will make sense in some contexts and make no sense in others. Learning the two paradigms can help the aspiring programmer read and understand other languages as well. The beauty of most programming languages is the fact that they all use many of the same concepts, and most of them use them in very similar ways. Looping, branching, true or false decisions, opening, writing to and closing files, accessing directories, creating structures to represent larger data concepts, and making libraries where procedures and objects can be stored to be used in other programs are all fundamental aspects of today's languages.  


The examples for C and C++ are shown simply because we can install one environment and cover both approaches (as I said earlier, C++ is a super-set of C; we can write 100% ANSI C programs in a C++ compiler and it should work just fine). Using different languages will require the overhead of two development environments, but that is also beneficial, since you will be able to see the differences in each and what they require to work on your system. 

No matter how you look at it, having a little programming knowledge can be a big help when it comes to talking with programmers. We may not be able to come up with all of the answers, but having this level of knowledge will definitely help us in getting to the right questions.

No comments: