one of the benefits of an ironkey --- when you're done washing it, it will will both smell good *and* continue to work.

not saying that it's necessarily worth the $350 odd for a 4gb stick tho...

it's not actually $370mil that gets spent on labor.

step 1: pull out overhead and profit. i'll be generous and estimate at 150% (this is probably *way* low). now you're down to 987 engineers for a year @ 150k per engineer per year
step 2: pull out irrelevant direct charges (project management, accounting, etc.). assuming this explains 10% of billing (again, quite generous), you're now left with 888 engineers.
etc.

it's pretty simple bud: if you think that databases or web development qualifies as a specialized comp. sci. area then you have either been mislead or are plain ignorant. more importantly, you should know that grad school is, generally, an extremely bad plan unless you're the peculiar kind of person that is really serious about your particular field. grad school will be _HELL_ if you don't love what you're doing. and to be honest, i don't think you love what you're doing.

i'd suggest you start exploring other options, because i'm afraid you've already lost this battle.

i'd wager that you suffer from some combination of:

1) confusing being a bastard with having a spine. user can't follow policy? kick them off the network. they want back on? get their boss to put it in writing and then sandbox the snot out of them.
2) being hamstrung by management (not backing you in disputes over policy, not giving you adequate resources)
3) being hamstrung by yourself (not proactively seeking out management's help when you need someone to back you on policy, give you resources; not hiring or otherwise outsourcing responsibility for desktop maintenance)
4) failure to manage expectations across the board (likely due to a failure to communicate)

if you suffer from #2, i'm afraid you're done at your current place of employment, same for #4. and while it is possible that #1 and #3, with time and the appropriate resources + backing from management, can be fixed, i wouldn't hold my breath.

throughout the course of an average day, i use:

1) a broad sampling from electrical engineering (specifically robust approaches to controls, detection + estimation, signal processing)
2) a broad sampling from software engineering
3) a broad sampling from computer engineering (specifically: what's going on at a hardware level as code executes, dma/rdma/misc. other for transfer to main memory, misc. busses)
4) a broad sampling from systems engineering (primarily approaches to testing, end-to-end performance analysis, root-cause analysis)
5) precisely enough mechanical engineering to explain why nobody should trust me with hardware

... let me tell you that going from a company of 30 to a company of 140,030 is still quite a shock, and the purchase went through nearly 18 months ago.

if you decide to go down this path, make sure that:
1) you have definite set dates for _EVERY_ part of the transition, _especially_ for 401(k)s, health insurance, etc. these dates must be part of the terms of the contract with seriously stiff penalties.
2) take a long, hard look at all your groups' bumps and warts. if you're like my group, you have several excellent tech leads and no project managers. make sure that your potential purchaser can either fix or drastically improve all of your failings.

there's a lot more, but for me the biggest items are those 2.

so you're in your 30's, depressed, and trying to figure out what you did with the last 10-15 years of your life?

(i'm not sure what it means that i'm 28 and going through the same thing...)

the obvious reason:
actually getting to take off fridays off is an iffy proposition, at least in my organization. i objected to it when it was implemented nearly 18 months ago as a sneaky, underhanded way to squeeze extra unpaid overtime out of employees and i feel even more strongly about that now than i did back then. i haven't had an off friday for the past 3 months and it seems increasingly unlikely that i'm going to get to take those fridays off until i get through a march delivery. obviously, your mileage will vary; however, unless your organization is serious about off fridays being sacred (mine, unfortunately, is not --- they expect you to be in the office on those fridays if there's even the slightest business need), expect to lose them quite frequently.

the non-obvious reasons:
1) trying to make up sick leave / personal absence gets to be really challenging. i find the incremental effort from 8 to 9 hours in a day not that bad, but 9 to 10 and beyond is really, really difficult (at least if my goal is to be actually productive as opposed to a warm body).

2) scheduling with clients / customers / team mates that are not on 9/80 gets to be more complicated, especially if you have multiple stakeholders whose off fridays are out of phase.

3) receiving shipments of parts / software / hardware / etc. on time can be difficult unless you have a dedicated receiving department working throughout the week.

4) depending on how you do time cards (assuming you do), correctly transcribing time can be a challenge. (you need two fridays per week)

i'm also in grad school and probably not much older than you are, but i *MUCH* prefer dead tree to electronic for most things (papers i want in pdf but that's about it). i find this particularly true for reference books --- mine end up with a collection of note cards used as bookmarks that are probably worth more to me than the books themselves. of course, i don't have to move my books very far (hooray for ample shelving at the office)

if it were up to me, i would teach a first course in computer science using only pencils (maybe pens for the foolhardy) and paper. i say that as someone who has t.a.'d a lot of programming classes.

the issue, at least as far as i've observed, is that until a student has a solid ability to start decomposing a problem using top-down and bottom-up approaches, trying to teach them any kinds of programming language or algorithms is pointless. it's like having a carburetor and no car.

i would suggest that c.s. instruction, especially at the early phases, should aim to make students spend a lot of time asking questions like: "what information do i need to solve this problem?", "what is the easiest useful thing i can do to help solve this problem?", "what's missing from my solution?", "is it easier to break this step down more or just do it right here?", "how can i join X and Y to do Z?", etc. once you get students asking those questions, picking up programming languages is a lot easier: they know what they want to do, all they need to focus on is how.

it's called systems biology.