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.