Other than just tinkering with Linux and FreeBSD on my own, how could an average stay at home person, such as myself gain enough knowledge to impress an employer?
I didn't notice anyone else mentioning it, but doing software QA under contract might be an option for you.
Errare humanum est and nobody errares more than software engineers and programmers because everyone works to the project rather than the clock and Mistakes Happen.
There are 2 basic types of QA (Quality Assurance): Black Box and White (or Clear, depending on who you're speaking with) Box.
Black Box involves putting yourself in the place of the ultimate user of the software, who may or may not be the actual purchaser. You sit there at the computer, with the current state of the incomplete software on a CD or DVD with a scratch copy of the incomplete user manual fresh off the laser printer. Your job is to see how hard it would be for new users of that software, if they had to accept it in its current state, to install and use it to do what they bought it for.
It could be documentation for a laser printer, where your only task is to install the driver software and then shove various documents into the print queue to see whether they come out looking like the master you put in.
It could be a new operating system (probably not, tho) and you have to see whether you can get it installed and bring it up so that it looks like it might some day work.
It could be an application or utility package, such as a graphics editor, or a desktop publishing editor, or a postscript charting editor, or any number of other things. They all have specific features, and your job is to exercise as many of them as the current incomplete software can offer you.
The best way to do BBQA is to exercise the software from the "center" (the features and settings that supposedly will be most used) to the "edges" (the features and settings that you probably won't see until you have to work around the clock to get the bugs out so that the finished product can ship). The development engineers generally don't spend much time out on the edges, but customers will sure as bananas give the company stick in the trade press when they find the unswatted bugs.
BBQAers don't have to look at the code, that's something White/Clear boxers do. BBQAers report the problems
users would encounter. Did the install not work? Did the system crash the moment you tried to draw a circle with the graphics editor, or did it draw the circle in the wrong place? Report what you did, and what happened next if it was unexpected. Go thru the whole incomplete user guide, over and over again making as many changes as you can (circles touching, overlapping, filling, ...) looking for missing pixels that aren't a monitor or video-card problem. Et cetera. And do it for every internal state-and-stage release. Again and again til the product ships. And then when it's undergoing maintenance
A lot of people who contract to do BBQA don't really care about doing a good job. I discovered that when I was doing contract QA after I got the push along with all my middle-manager-over-40 colleagues. Whether they're just lazy and willing to short-change their co-workers or what, I don't know.
I used to lecture the QA engineers and contractors that the fate of the company and their own jobs depended on doing it right. And to make the point more clearly, I spent most of my non-tech time and had my project leaders spend most of theirs doing BBQA after the Alpha point was passed. Young engineers think it's just donkey work (any donkey can do it) but that just shows their inexperience. Those who didn't get the memo stayed at the bottom of the pile til they wised up, or left.
So you can make good money if you can show that you are conscientious and have a feel for where the bugs are.
