As an autodidact who dropped out of college to go work in a recording studio and thence fell happily sideways into IT, I would offer that it is entirely possible to build a great IT career sans degree, but you're going to have to accept that most of the Corporate World won't hire you.

This is not a bad thing.

You probably don't want to work in corporate IT anyway. It often sucks, and that right hard. Why else would everyone bitch so mightily and with such frequency? Who wants to work for a bunch of shifty-eyed suits? Yeech, no thanks.

SMB consulting will be wide open to you, so long as you have skills. Small development shops won't care a whit about your creds, so long as you've got a sweet portfolio of work and a hunger to excel. Security firms are interested in your l33tness and whether they can trust you not to rob the joint. All of them will require you to simultaneously bust your ass and enjoy it, which is good.

Point being: if you've a modicum of talent and drive, you can do fine without the degree. Don't misunderstand: a degree is a fine thing and not to be discarded lightly, but you can have a great career with zero formal training so long as you really, really, really give a damn and will work very very hard.

mod parent +1 essential. It is awfully easy to set up a painfully insecure documentation system, and rather more difficult to do correctly.

PRIME DIRECTIVE: Regarding some of the above posts, If you are having to strategically "leave gaps" or otherwise write bad documentation for the purposes of monkey wrenching your replacement or making yourself indispensable, you suck to the 10th power. I have dealt with this sort of fuckery more times than I can count over the years, and every time I clearly see the signs of a small mind at work. Don't be that guy.

I've have to do this routine a gazillion times in my role as an small/midsize biz consultant. Here's the formula as I see it:

Find the keys to the kingdom, and document these. Don't worry about getting to the nitty-gritty yet: just find the info that will let you find everything else. Be extra careful to track down any crypto-related stuff (keys, passphrases) that can't be replaced or cracked. The further the old IT person recedes into the past, the harder this crap is to track down. Identify the scariest bits of the network as quickly as you can after you get hired and trumpet to the hills about how fragile, dangerous, and not your fault they are :-) Document all of this in plain-old-textfiles or something stupid simple, with bonus points if you keep it in version control.

Set up some bug-tracking/ticketing software and use that to track all of your day-to-day documentation and troubleshooting. Redmine is my personal favorite, but RT and Trac are also good choices. They have simple, built-in wikis that are perfectly sufficient for this purpose. Use the time-tracking and project management features in the software: when the boss asks you where all of your time is going, you run a report and show him. Track every minute of your day: this time is excellent leverage for you when dealing with management.

Examine the backups of the system (or implement them, worse) from ground zero. Use the backup audit as the trail of breadcrumbs that your documentation follows.

Beg, borrow, or steal a chunk of hardware that you can stick Xen/HyperV/VmWare/AcmeHypervisor on and start test restoring various systems/apps/environments. Document the hell out of the test restore process. That's the most precious documentation that you can possibly have.

Don't document things that document themselves. You're much better off paying $299 for a copy of LanSweeper or the like to reach out across your networks and document all of the mundane details in real-time so that you can focus on making shit work right. I've seen a million cases where the IT guy spent a month making a beautiful set of Visio network maps that became useless a month after they were created. That's a waste of your otherwise precious time.

Now, start making recommendations about how to fix the fragile/scary/dangerous systems. Use your ticketing/project management app to track your recommendations and leave a paper trail of your process. There will be a fair amount of CYA involved here - you're going to recommend that the boss spend a bunch of money on $x, so you had better document the reasons for it with care.

Whenever you make a recommendation that the company buy product $x to resolve problem $y, document it very very clearly in your system, and if the bosses nix your recommendation, document that in writing too. Yes, more CYA, but as the IT guy you're often the staked goat when something goes wrong. You need to be able to PROVE that you had recommended a sane course of action.

Last: Try not to stress. IT is fun if you do it right.

- avoid blacklisting input where ever possible. Accept known good, reject everything else.

- Encoding is going to be a problem. Be extra careful about how you handle encoding and decoding. An attacker will encode malicious input to get it past filters. Never assume that because you have obfuscated data with, say, base64 encoding, that an attacker won't be smart enough to decode it.

- Assume that an attacker will be able to breach your defenses, so make it difficult for him to do damage once he has compromised the system. if you have a particular function that accesses 'crown jewel' data, spend extra time making that function extra awesome. Minimize the privileges of the SQL accounts you issue queries with. That is easier said than done, of course. Layer your defenses, harass, annoy, and otherwise dispirit the enemy in a hundred small ways and make him move on to a softer target.

- Use frameworks. Don't try to roll your own if someone else has already don't the tough stuff for you. Writing a good login management system is hard to do right. Stand on the shoulders of giants if you can. This makes updates easier to manage too.

- Do all of the other stuff that I didn't mention here :-)

IMHO, writing short notes by hand seems to act as a mnemonic device - it installs stuff in memory much better than typing.

I also find myself sketching 1st drafts of network diagrams/dataflows with a soft-leaded sketching pencil. Somehow this clarifies my thinking so that once I create a proper digital document the process goes much more easily.

You haven't understood what I said. Read it again, please.

Your reply is a mirror image of the sort of apologia we hear from Biblical literalists who endlessly claim that all the evidence is in, there is no doubt, the translations are perfect, of course there is a God and the Bible is a perfect transcription of his will.

I think we can agree that this sort of fundamentalist literalism is wrongheaded - it presupposes perfect knowledge where there is in fact none. So too it is with the mirror-image, fundamentalist Atheism.

I repeat, isn't "there is no hard scientific evidence for the existence of an all-powerful creator" a more appropriate statement?

>>>Look, there is NO GOD, there is just nature.

That's a very aggressive ontological argument. You're certain? Really? Totally, 100%, zero doubt?

Isn't "there is no hard scientific evidence for the existence of an all-powerful creator" a more appropriate statement?

Good scientists are always aware that there is a *possibility* that they haven't figured out everything. Absolute statements like "there is NO GOD" are the province of those who are deluded into thinking that they know everything.

Well, there's another prediction from David Brin's Earth down. http://earthbydavidbrin.pbworks.com/Predictions

The real trouble with extracting usable petroleum from oil shale is that given the processes now employed, you actually wind up putting more raw energy into the process than you get out. The current process requires huge inputs of natural gas--these processes were invented at a time when North American natural gas was cheap. If you intend for oil shale to be a replacement for crude oil, you have to have a way of getting it out of the ground that uses less energy than is embodied in the oil shale to begin with; otherwise you're ignoring the second law of thermodynamics. At this point we're better off just burning the natural gas on its own rather than waste it on cracking oil shale.

Secondly, you have to examine the environmental impact of oil shale production. The process that is currently employed leaves behind absolutely massive quantities of polluted water and slag that must be disposed of. You're talking several barrels of toxic waste water for every barrel of oil equivalent produced. Ugh.

Conservation is the only viable alternative that we have right now. If we Americans could just take the simple steps of driving fuel-efficient cars, insulating our houses properly, investing in public transportation, and converting our shipping systems from inefficient trucks back to a rail system, we could vastly increase the energy-efficiency of our economy with very little pain. At what price will my countrymen wake up and begin to take these simple steps? Only when prices have become unbearable, and not likely before.

HDTV is a tough subject, because the industry has done such a poor job on rolling out HDTV. Not just the manufacturers, but also the stations, cable companies and the damned FCC. But you would think you would know whether or not you have HDTV after seeing what 1080i looks like.

My Toshiba is 1080i ready.. but I'll be damned if I'm paying what they want right now for an HDTiVo for six channels.. two of which are sports I dont watch anyway.

Its a case of consumer stupidity, and salesman at Best Buy not knowing what they are selling, or misusing terms.

I like my TV at 740p when running 2/3 pulldown dvd's.. and I can only dream of how its going to look when HD becomes a reality, rather than a gouge.

But.. until the prices on HD boxes come down.. (I wasnt stupid enough to buy a TV with a built-in decoder.. especially when they havent even really settled on a format yet) I'm just gonna have to live with CNN in all its semi-fuzzy 57" glory.

(ANd I'm happy with that.. I bought the TV to watch movies.. and I'm looking into DVhs now.. also)

Maeryk

Exactly right. There are plenty of "engineers" doing professional engineering type work that aren't licensed and are happy to do so. They just don't delude themselves by calling themselves "engineers".

Frankly, I think the use of the term engineer by software designers is done specifically to gain some sort of instant credibility on the backs of a profession that is held to task far more than the software industry.

Why are programmers not willing to seperate the ones amongst themselves willing to accept responsibility for what they do, and those that would rather just go to work every day. Neither is better than the other.

I would think that some software designers would welcome the opportunity to distinguish themselves from the rest.