Skip to content

What got me where I am today (the "3 things" blog meme)

Sure, OK... why not.

Paul Randal started this mess: He wrote a blog post about 3 events that brought him to the current point in his career, and invited the rest of the interwebs to do the same.  I decided I would and promptly forgot about it, then @zippy1981 did and I felt guilty, So here, with a decidedly carreer-and-IT slant because y'all just DO NOT WANT to know about my personal proclivities, are my three events:


Event The First: My first PC (Age 10 or 11ish)

Not the first computer I ever used, and not even something online (my BBS excursions were still coming courtesy of a C64 at this point - all of you shut the fuck up and get off my lawn).  This box was a PC-AT clone, Intel 80286 processor with a turbo button (that bumped the speed from 8MHz to a BLISTERING 12MHz!), a 40MB hard drive and a full whopping megabyte of RAM.  This PC came loaded with a few games (Castle Adventure and Joust), some basic data processing software that I don't remember the name of, and MS-DOS 4.01 ("That bloated ass memory hog").

Why is it significant? Well, it came with manuals. GOOD manuals, not the shit 4-color glossy picture of clouds and a "Use the online help if you get stuck" manuals we get today, but 4 actual, decent sized softcover books.  With a list of every command MS-DOS 4 had to offer, what they did and how to make them do what you want.
When my parents bought the computer the guy who sold it to them said that as long as I didn't get my grubby mits on said manuals I really couldn't do any damage.  They hid the manuals (not very well), I found them the first week but didn't pay much attention until something broke and I dragged them out to fix the problem.  My parents looked like they just watched me kill a kitten when they found me reading the manuals, but I solved the problem and learned an important lesson: Documentation (GOOD documentation) is worth more than any other component of the system.  With good documentation you can solve almost any problem; Without good documentation your chances are at best 50/50; With bad documentation you'll just make the problem worse – Probably even unfixable.


Event the Second: Get an after-school job! (Age 17-21ish)
By this time I was dual-booting FreeBSD (2.2.x era) alongside my Crappy Windows (95), I had traded in my BASIC and assembler for a real language (C), and I decided I wanted to get more into the guts of operating systems so I was taking AP Comp Sci to get my data structures and object oriented chops up. And like every other kid in Massapequa I was working after school at one of our local grocery stores (Leaky meat packages for the win!)
So one day bullshitting in AP Comp Sci my friend Joe mentions that he was interviewing for a web internship at a company he heard about at a job fair, and he mentioned they were looking for Unix interns & convinced me to go with him, and we were both brought in as interns at LeviFord Information Systems pretty much on the spot.

Why is it significant? Leviford is where I developed all the skills that I continue to use and refine today, specifically how to analyze and model complex systems and map out the datamodel in play within them.  In four years of what I would classify as a good-to-excellent college CS education this skill was never really taught to me, but I learned its value in one summer, and one of my mantras is still "Until you understand the problem and build a correct model you will never build a good solution".
This internship also let me see Unix in the corporate world (as opposed to the ISP deployments I was familiar with from misspending far too much of my youth on IRC), and gave me my first exposure to the mysterious world of Porcupines and Crickets as I became intimately involved with the company's software which attempted (with a high degree of success) to manage these beasts.


Event the Third: Invision and Invision's takeover by MindSHIFT (Age 25-26ish)
Fast Forwarding a bit, I continued to hone my craft at a local internet/managed services provider.  At Invision I got to play in even larger scale operations than at Leviford, and got to see how systems behaved under load, abuse, abusive load, and all sorts of other unpleasant situations.  This was also where I grew to truly appreciate and respect process (where it was forced on me before and I hated it, here there was almost none and I found out why it was so important). I also learned the value of monitoring (and the cost of getting it wrong), learned the messy details of network architecture and how it interacts with the servers I wrangle daily, and got to develop far better power and cooling chops than I ever wanted.

Why is it significant? Invision had lots of problems, but on the balance it was a great place to work (even if I knew I was underpaid and overworked).  That balance tipped when the company was sold, and after realizing that our new corporate masters weren't interested in bringing my salary up to what I could be earning if I left the company and went elsewhere, elsewhere I went.




No Trackbacks


Display comments as Linear | Threaded

No comments

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

Twitter, Pavatar, Gravatar author images supported.
Form options