here's the problem: every day, i make pretty heavy use of machine learning and the other bits and pieces that collectively get referred to as artificial intelligence. as a consequence, i deal with a very large number of fools who are each convinced that their $ALGORITHM is an earth shattering new paradigm for $TASK and clearly is the best thing evar. so you start reading and you realize that in 99.999% of cases, you're staring at something that is some combination of:

a) based on a fundamentally broken assumptions (usually never even stated)
b) bad analogies that obfuscate the fact that wheels are being re-invented (usually poorly)
c) narrowly defined special case
d) broken (provably non-optimal optimization routines)

that rare 0.001% for me consists of things like the ransac family of meta-algorithms, mean-shift tracking, markov random fields, quadratic correlation filters, and support vector machines.

the latter. the former would require, amongst other things, access to the source code (as required by the original critterdings license) and a lot of noise coming from the biological disciplines re: computationally tractable, useful models for the various signaling pathways involved in hallucinogen use.

exactly, although i suspect that the right answer depends on the kind of person you are.

for me, very few things piss me off more quickly than getting a request to stay late to finish something for a deadline without even a hint of an offer of help from my management. this usually means i turn into the bad guy asking my team to work extra hours to deal with the most recent crisis caused by one of the other teams on our project (conveniently located elsewhere in the country and impossible to contact after 4pm eastern) screwing up.

Quick: who are Robert Tarjan, Edsgar Dijkstra, Robert Floyd and Stephen Warshall and why would you care about their work?

Which brings me to my point: if you don't know what you're looking for, all the references in the world are essentially useless to you.

If I ever meet a person with DeVry / ITT / etc. "credentials" who has done any of the following:

(a) designed fully decentralized, distributed, scalable, robust, real-time systems and successfully implemented and deployed said systems in the real world
(b) built a compiler from the tokenizer up and understands every step of how code gets turned into bits and how those bits get executed on modern hardware
(c) had an opportunity to use Tarjan's disjoint union / find algorithms and can explain where those data structures / algorithms are appropriate

I'd be interested in hiring him/her. The problem is that I have yet to meet such a person, because DeVry / ITT / etc. are degree mills whose sole purpose is to get as many people to cross the lowest possible bar that could pass accreditation -- i.e. turn a profit. As a consequence, the DeVry / ITT / etc. grads that I've had the "pleasure" of working with all have very narrow and shallow areas of competency and essentially zero ability to work outside those areas. The benefit of a four year degree is that in spite of all the fluff:

(a) you have a far better opportunity to actually cover the full breadth of theory
(b) there is enough time to mature enough intellectually to start to grok the zen nature of the theory
(c) you can't really choose between theory and practice; you have to demonstrate a degree of proficiency in both

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)