How to use Windows regularly without hating it (much)
A company that I interned with and worked for after graduation from university a year ago did most of their internal business management and data-entry tasks with custom software written almost entirely in VB with an Access backend, which communicated with a remote database server running MS SQL Server 2000. Like most people with a formal computer science background, I hated the prospect of having to do serious work in what popular prejudice had termed a "toy" language. But my gradual initiation into the power of VB is a topic for another node.
The immediate problem facing me was that I now had to get a platform up and running on which I could develop in Visual Studio 6. And I also would need to run MS Office 2000. Obviously, I could kiss any hopes of using Linux goodbye. Through trial, error, and days -- no, weeks -- of frustration, I turned a Compaq Presario laptop, factory fresh with Windows XP installed, into a workable and fairly stable development platform which I am still using to this day.
Here's how I did it, and what I learned in the process.
Lesson One: Know when to tweak and when to leave things the hell alone.
Geeks and hackers are consumed by the desire to know how things work. Generally, almost any old thing will do. The average user couldn't care less about how or why anything works. Somewhere in between lie companies which have to turn a profit to keep the doors open and the lights on, which necessitates that they sell their products to people who want them - people who reside on both sides of the spectrum. Of course, this is all (I hope)quite obvious.
What isn't so obvious is that this means design compromises are a fact of life. Hardware is all-too-often a nightmarish conglomerate of:
- poor standards with clever implementations,
- bad designs with good implementations,
- great designs with lousy implementations,
and especially,
- things which work great by themselves
but cause mysterious glitches when you connect them to other
things which also worked great by themselves.
Second, ultra-high end stuff is often based on proprietary standards and nearly experimental drivers, and has yet to endure the test of the consumer market because it's out of the average consumer's price range. This translates into higher uncertainty for the chance of having features that you generally won't need anyway.
The point is this: You want a stable platform, and unless you are a hardware genius with an electronic engineering degree, access to extensive tech specs, and encyclopedic knowledge from years of working as a repair technician, chances are good that the performance hit you will take for not having a custom-tweaked system with bleeding edge hardware will be more than compensated by the fact that you will spend less time swearing at mysterious hardware lock-ups, which means you'll have more time to swear at your code in the IDE instead, especially when you are later trying to communicate with poorly-documented DLLs and sorting out their esoteric, non-standardized calling conventions. Better yet, you will have access to technical support other than yourself, as well as resources which a company offers you, the valued customer - like a replacement machine.
The bottom line?
- Buy factory.
- Get the options you need, realizing you're being overcharged. Think of it as insurance if it helps.
- Mess only with hardware you understand very well.
- Don't overestimate your ability to to do the above.
Always remember that it is in almost every case in the company's self-interest to avoid tech support disasters, overtime for the staff, and angry customers no longer interested in the systems it markets. It's your right as a consumer to capitalize on that need. You have the right to be a geek, but you also have a duty to yourself to be intelligent about what you learn, how much you learn and how much time you spend learning it.
Dealing with Hardware - In Summary
From working as a computer repair tech at a mid-sized university, I can tell you that most hardware problems are not simple to fix, and from personal experience with hardware tweaking and building various boxes, I've experienced firsthand the frustration and expense which can result from a seemingly well-thought-out suite of hardware that just refuses to work together. And calling vendors directly as an individual is neither fun nor useful either. You, as a secondary purchaser from a distributor or authorized reseller, will generally be assigned the lowest priority they have, regardless of what the customer service people and advertisements tell you.
The key in all of this is to be honest with yourself about your capabilities. Even if you're brilliant, there are enough stupidities and complexities caused by outright human error, bureaucratic and political issues in project management, and design trade-offs to scramble your ample brain more than should be necessary, along with having to contend with an industry characterized by frantic development pace, incompatible proprietary standards, and frequent obsolescence of hardware, standards, or both.
Now, please, do yourself a favor and apply the same principle to software. Actually, if you don't understand Windows at all, don't follow the rest of this series of articles, which assumes you are someone with a decent amount of experience in using the Windows operating system and who knows something of how it actually works. In the coming parts of this series, we're going to actually start getting messy.