OK, I have QA training in my background as well as programming skills, so apply appropriate amounts of salt: some of the most interesting blunders in design, and blunders in implementation, are exposed when a good technical writer tries to makes sense of what s/he sees, and fails. In the process of trying to teach others how it all works, all the warts, cracks, crocks, and kludges are exposed in all its glory. What doesn't make sense in a manual will most likely not make sense in the real world. Think of it as scaffolding for the mind. "According to the specification, when I do THIS then X is supposed to happen; instead Y happens." And so forth.

When I was in a large programming group in the 70s, I was the guy sitting at a Wang word processor, banging out design specs and cursing some of the square-heads that couldn't seem to design their way out of a paper bag. When my company decided they wanted to build their own replacement computer for one they had been buying for years, they turned to me to "reverse engineer" the computer -- including all the proprietary extensions and additions -- so the hardware group would have something to design to, and the SQA people to test the implementation against.

Actually, it's an old story in Engineering. When you try to explain something, you see holes that you were blind to for days, months, even years. It's an "Aha!" generator.

There is a benefit that no one has mentioned yet: HFT can cause the market for a stock to oscillate out of control very, very quickly, and that oscillation can disrupt the trading in the stock. The "circuit breakers" the NYSE put in to damp out-of-control oscillations are pretty much defeated by HFT. Further, HFT disassociates the value of the stock itself from the perceived value created by short-term movement in the market, and so affects the capitalization of a company trying to do business. HFT is also a way to quick ruin, if the algorithms used are not tuned carefully enough -- and particularly if two trading algorithms get into harmonic resonance: think Galloping Gertie, the Tacoma Narrows Bridge in 1940.

"I write excellent product specs" -- are these product specifications sufficiently detailed to have a consulting Software Quality Assurance person be able to test each feature of the product? Sufficiently detailed so the multiple people you hire can seamlessly do integration testing? What scaffolding do you provide for each of the developers? Do you have the same "source control" of your specifications as you do for the code generated from them? How do you handle "feature creep"?

"Bug tracking and source control" -- Do you have staff or contractors who confirm the bugs? And how do you handle regression testing during development and subsequent maintenance? How about code reviews? Who handles customer service queries?

"Empathy for developers" -- demanding bug-free code without the tools and processes to give the contract developers a fighting chance? How well do you anticipate corner cases in your products, so you can include them in your specification? What practices do you insist on to catch bugs early in the product development cycle?

"...hire someone full-time...know a lot of languages and be proficient in all of them...can't afford to pay someone $100k/year" -- Sounds like a version of the Universal Specification: "I want everything, now for, $1.98." As for pay, that one is easy: make him a partner, and he earns from the bottom line just like you do. You will probably have to take a bit of a pay cut to attract what is essentially a do-everything maintenance programmer, not exactly the career track that anyone with the type of experience you are looking for would choose. Have you looked at the pool of experienced programmers? There are quite a few who have been put out to pasture because they don't have the "zing" in their resume that most [In]Homan Resource people look for. Learning languages is a skill easily picked up. Learning how to un-muddle code written my others is an art, and people skilled in the art of decoding a mess are much harder to find, let alone identify.

Transition? One possibility is to find a contractor highly skilled in maintenance programms. If he works out, offer him a partnership.

As for the attitude that any piece of software can be completely bug-free: that's a holy grail. The ADA Programming Language was invented to try to provide an underpinning to achieving the holy grail -- when was the last time you heard about it seriously? Several research-based languages have been developed that purport to "prove" that they are correct...but watch what happens when an unanticipated corner case hits the code. Many of the advances in languages and compilers focus on finding easy and trivial problems quickly, so a programmer doesn't have to spend time finding and fixing them. (Scripting languages, particularly those that compile "on the fly" such as TCL and most shell scripts, point out the advantage of a proper compilable language; you lose some flexibility, but the overall programmer cost is far lower than tripping over mistakes one at a time, particularly if the programs run are measured in minutes and hours.)

Your business model will need to change. Count on it.

...that would take documentation of the plugboard wiring of the old 400 series "accounting machines" and produce source that would work exactly the same as the accounting machine, give 80-column card images for the data. It wouldn't emulate any cross-connects to other tab equipment (sorters, punches, interpreters) but it did a wonderful job of moving plug-board programming to the more modern computers (360, in particular). Anyone know where that software might be? As I recall, it was on a micro-spool of magnetic tape originally, purchased at user group meetings. Time to google...nothing so far...

One of the issues that always comes up when talking about H-1B is that employers say they can't satisfy their needs with the talent already available. So, how about adding the requirement that any H-1B applications require the company post a "Help Wanted" ad in a national database for three months before the application is approved. Let's see why companies don't like citizen talent. Let's see how citizens can fill those jobs.

If your school anticipated the problem, you can find the solution. First, see if your dorm has a segregated study area. At the school I went to, that study area was in the basement, down the hall from the laundry room -- the idea was that you should start some clothes washing, study, dry, study, fold, and be done. The room was soundproofed...but the lack of echo and noise unnerved some people, but I loved it. Also, there was a lounge in my dorm where -- most of the time -- you could find peace and quiet. Other people suggested the library as a place to study. The solutions don't have to cost money.

Regarding bridges/roads and tolls: One of the rationales for keeping tolls on roads and bridges is to collect money to maintain the roads/bridges once they are paid off. I've seen this reasoning used in three states, and in all cases the tolls were increased "because the cost of maintaining the roads keeps going up." In Cook County IL, the real reason the tolls were kept on is because sub-standard work had to be torn up and re-done -- multiple times. The reason the work was sub-standard is left as an exercise to the reader.

I've never lived in a state where the tolls were retired and the booths torn down.

Dig a little deeper, and you find out that the governments appreciate how tolls free up general revenue for other spending.

If you have ever been involved with regulated radio, the regulation " Carriers must approve of the use of each and every one of these boosters" makes perfect sense.

The introduction of a repeater into a cell system means that the engineering of the cell boundaries can be affected. Now, for boosters that are used in building that shield the RF, there is little engineering that needs to be done -- you are essentially extending the antenna outside the shield. (And you can get repeater antennas without boosters that do the same job, and I suspect they are *not* covered by this regulation.)

When you have an active repeater, that means the cell signals from the provider can be relayed as well as the signals from your cell phone. With microcell design, this can play hob with the clearances, so that a phone will see two cell site courtesy of your repeater.

I'm not an expert on cell systems, but I remember some of the arguments used to keep people from using cell phones from airplanes.

This reverse Polish language was not a "mainstream" language, but for astronomers, it was perfect for telescope automation. FORTH was also used in other robotic things. I was really surprised that FORTH wasn't included on anyone's list. In fact, how many of you have ever heard of FORTH, let alone did any programming in it?

They've gone into plaid. http://www.youtube.com/watch?v=mk7VWcuVOf0

I found that when I bought a bunch of 3-foot power cords, the power part of the cable tangle became much less of an issue. Using a long power strip (like the ones used in the sides of racks) also helps the snarl. For the rest, judicious use of velcro cable ties helps. Espeically when you have a chewing cat, like I do!

You forgot the burned-out light bulb

What a concept. Distance hair-trimming. How does that work again? You have to remove your scalp, FedEx it to the out-of-state barber, and then fit it back on the return leg?

My brother is a process chemical engineer. Numerous times I've heard him say "if you want to increase capacity of a process, you take the unit you have, duplicate it, and pipe it in parallel." In the early days, I remember servers with four NICs running in parallel to increase bandwidth, while each server was glowing slightly red from the load. If one needs the capacity, it's available today. In one enterprise network, I saw servers with multiple NICs, each NIC connected to a separate EtherSwitch. In other words, there were four separate networks. Routers would bring leaf systems (PCs) into the quad-net backbone. I never learned how server-to-server traffic was handled, but I was told that all four backbone sections were used. So you don't NEED terabit Ethernet NOW, there are other solutions that aren't quite as elegant, but work.

Way back when, while attending the University of Illinois (major: Computing Engineering), I wanted to take a junior-level CS course as a freshman. (CS306, to be exact, taught by Gillies.) In order to take the course, I had to satisfy the prerequisites. So I took the exams for the FORTRAN and ASSEMBLER courses. My advisor encouraged me to blow through the two lower courses: "I don't want you getting bored." Both exams were a piece of cake because I had been programming in both languages, plus PL/I, for two years in high school. (Funny story: for the ASSEMBLER course, the final exam was prepared by the professor, and the teaching assistants took the test with the students, to help set the curve. I missed one question, the TAs missed the same question plus one additional question, so I ended up setting the curve. The other members of the class were not amused.)

I was accepted into the CS306 class, and ended up teaching the first two weeks, because I was the only person in the classroom -- the teaching assistants included -- who knew PL/I cold, and PL/I was the languages used for the machine simulator. I also helped debug the simulator. I also was a "group of one" (the standard was to have three-people teams for the term project) because the professor thought that anyone who was on my team would not benefit. So I ran solo. And freely consulted to the other teams, with the professor's blessing and strict limitations on the kind of help I could provide.

(Calculus proved to be my downfall. Long story. Even the Dean of Engineering became involved, but the damage had been done. After working for a corporation for two years, I used the corporate tuition reimbursement program and went to junior college -- and aced all four calculus courses, all the way through Differential Equations. I just needed the right preparation.)