If you're getting offers of 30-40% higher and taking them, as an employer I don't think I'd blame you for hopping.
The problem is going to be this: You're costing your employers money every time you do this. Lots and lots of money. It costs money to go through the hiring process, the process of orienting you (during which time you are less productive and still getting paid), the process of processing you (HR setting up payroll, insurance, etc), and worst of all -- the opportunity cost of hiring someone who leaves in a couple of months (ie, loss of productivity due to your orientation time + hiring time of the next guy + orientation time of the next guy).
Unless you are extraordinarily compelling, I'd be inclined to pass on you as an employer unless I was sure there was something I could do to keep you should you get a better offer -- and I'd have to be willing to do it, too.
Mostly, when you make a habit of hopping, what you need to consider before you hop is: 1. If the new job turns sour, am I willing to put up with any shit they give me, no matter how bad it is. 2. Is the company going to be in a position to release me in the near future (ie, due to layoffs or because I'm a fuck up)
The reason you need to consider these is because with each hop you make in a short amount of time, the danger of the aforementioned hiring manager passing on you due to your hopping increases. You do NOT want to be without a job when you cross the line and become a radioactive hire due to job hopping.
Those were important skills in the beginning of the written word though. Why do we still teach CS and engineering majors tons of higher math? It's a vestigial remnant of what computers and engineering used to be about. Today we have computers to do the math for us. That's a pretty silly statement. Computers can crunch the numbers for you, but they need you to set the problem up for them. And you usually can't set up the problem without having done the math yourself at some point.
And engineers don't learn higher math. Or for the most part, higher level physics either. When you get into the higher level stuff in either of those fields, they pretty much sit you down and say, "Sorry to do this to you, but you know all that stuff we spent the last two years teaching you? We've got to scrap it all in order to proceed. It just won't cut it for what we need to do going forward." On the math side, this is where they shit-can the Reimann integral and build you up to the Lebesgue integral. On the physics side, this is where they shit-can Newtonian physics and build you up to the modern stuff.
And the stuff that they start teaching you at that point... well, computers don't do it very well. It often involves proofs. Computers are bad at proofs. It often involves measures of uncertainty. Computers are bad with measures of uncertainty.
I'm actually not sure how you would create a laser-based reader that didn't digitally sample the signal received from the laser, but I'm not an EE, so what do I know... Instead of feeding the sensor into an A/D-DSP-D/A setup, just feed it directly to an analog system that performs the same function as the digital setup.
If you really wanted to, you could do it with analog components, it's just probably not worth the trouble. If all you really what is high fidelity, just use a DSP system that quantizes with more bits; instead of quantizing at 16 bits like a CD, quantize at 64 or 128.
Use enough bits in the processing of the signal, and no human will be able to tell the difference. (see "quantization noise" for details)
See, the military is already prepared for that answer. If you refuse a direct order in the field -- and make no mistake, when they come for you, it won't be in an office meeting -- you get shot on the spot. What is the likelihood of a significant portion of the military defecting after watching their friend get his head blown off by their commander, with the gun is now pointed directly at them? That is murder under the UCMJ.
Punishments that do not require a court martial are generally limited to short term confinement (30 days or less), "restriction to limits" (60 days -- I think this means essentially means allowed to go only to certain places), loss of pay, punishment duty ("Clean those latrines, Private!") or rank adjustment. Reduced rations are also a possibility, but are generally limited to very short terms -- 3 days or so. See subchapter III for more information.
All other punishments not prescribed under subchapter III require a court martial.
One of the most important skills to have in any profession is how to look at the task before you is to how break down the task into smaller logical issues.
The next most important thing is to look at those smaller logical issues and be able to say, "These are the things I need to know in order to work on those smaller tasks."
And finally, when you say, "These are the things I need to know", being able to honestly evaluate whether you actually know how to do them and being able to start to learn how to do them is the final step.
For example, I really don't know how I would go about writing an emulator. So, let's take that for the example. What are the things I would expect an emulator to be able to do?
Load a game.
Execute the game code.
Accept input
Display game video output
Play game sound output
Intercept video game "save" and "load" attempts and map them to some reasonable analog on the emulating system.
So, what do I need to know in order to do these things?
Load a game: I need to figure out how to generate a ROM from a device -- cartrige, cd, DVD, etc. Then I need to be able to load that into storage of some kind (memory, hdd, etc) on my emulating device.
Execute the game code: Okay, so what kind of hardware and software did the original game code run on? Was it x86? Z80? MOS 6502? How do I go about mapping the binary instruction code for the original CPU platform to my current CPU platform?
Accept input: How do I take input from my keyboard/mouse/controller and map it to the input routines of the game code?
Display video game output: How do I display the kind of graphics that the original ROM would display on the emulator host? How would I map the graphics calls of the ROM to equivalent graphics calls on the emulator host?
Play audio output: How do I play the sound on the emulator system, and how do I map the ROM calls to the host system's audio output?
Intercepting "load"/"save": How does the original system handle save games? How can I transparently intercept ROM calls to those saved games and map them to something that makes sense to the host system?
And there's probably plenty more that I'm missing. But being able to just start like that is a huge deal, and being able to realize, "Gee, I really don't know how that would work. But maybe if I look at this resource here, I may begin to learn how to..."
I've finally come to the conclusion that I will never see any form of technical challenge despite the continued promise of such.
If they're promising you things and not delivering them, you need to take them to task for it... unless you are satisfied with the fact that they will continue to promise things and not deliver.
It's really that simple.
How do you justify what would typically be considered a step back?
You justify it by saying, "This is what I want. And I'm willing to pay the associated costs with making it happen."
That means losing out on some salary and possibly some perks. Is it worth it to you? Then very simply, find another job -- in the company or out -- that makes it happen.
If you're not willing to pay the costs, then dammit, don't do it.
As far as *how* to make it happen, either find someone willing to make it happen, start your own company where you can make it happen......
Or go back, get your PhD, and sign on at a research institution. You'll get plenty of technical challenges... once you're able to get a grant or a contract of some kind.
Not that I'm advocating creating shit, but the "good enough" solution that cost a million dollars and generates five million in cost savings or revenue may be better than the "perfect" solution that cost four million dollars and generates seven million in cost savings or revenue.
Fixed. There are factors other than money, and there are factors which cannot be accounted for in terms of money.:)
Mathematicians are in the business of (among other things) taking mathematical equations that are currently unsolvable and finding ways of solving them.
At one point, taking the square root of the number "-1" was a totally unsolvable problem. It didn't make any sense, because a negative number times a negative number yielded a positive number. So to handle this, they made up a number i, defined it as the square root of -1, and found that hey, this number was consistent and worked with all already extant mathematical rules. Suddenly, you can make sense of equations involving that number.
As far as imaginary numbers being useful is concerned, well, as people mentioned, they're critical in electrical engineering. One of the most impotant numbers is exp^(ix) which is equal to "cos(x)+i*sin(x)". Fourier proved a long time ago that any periodic signal can be expressed as a sum of sines and cosines. Which means that any signal can be expressed as a sum of exp^(ix)... which is exactly what the Fourier transform does. It takes an input signal and transforms it into a sum of sines and cosines.
The Fourier transform is absolutely critical in electrical engineering. It is a transform that takes a time domain representation of a signal and converts it to a frequency domain representation. It makes hard problems easy, and totally intractable problems tractable.
If you take the output of one system ( f(x) ) and tie it into the input of another (g (x) ), the resultant output in the time domain is given by an annoying process known as convolution (integrate f(x)*g(x+t) dt from negative infinity to infinity). In the frequency domain, you just multiply the two functions, a process which is much easier.
Also, modelling the signal in the frequency domain allows you do look at what the components are of a signal by their frequency (obviously). You can see how much power is in any given frequency, for example. This is pretty useful when looking at RF signals, for example -- you can see what signals exist on what RF frequencies, what needs to be filtered out, etc.
Also, in the frequency domain, there are characteristics you can look for that will imply stability or instability in a system that you can identify at a glance; in the time domain, the only way to find out these characteristics is to do some rather annoying proofs. For example, in the time domain, if I want to prove that a system is BIBO stable (ie, bounded input always yields bounded output), I have to actually *prove* that the system will never go higher than a certain point. In the frequency domain, I can simply look at the the poles -- what values of frequency will cause the denominator of the frequency domain representation to go to zero -- and apply a couple of rules that tell me whether the system is stable based upon where the poles are.
Imaginary numbers are absolutely critical to electrical engineering. You can't do anything beyond the most trivial of things without them.
Well, I was thinking symbolic multiplication, not constant multiplication. I always suspected that the FFT could be good for constant number multiplication, but I figured that the big-Omega of symbolic would be along the lines of n^2.
Which is why I was suprised when you mentioned the FFT being n log n -- but that doesn't seem to help me.:(
I agree that vector calculus should probably be dropped. It's just doing integrals multiple times, and so is really just an extension of the basic calculus series. If you need vector calculus, it is trivial to learn provided you know the stuff that typically proceeds it.
Dropping calculus altogether is boneheaded; too many results of other higher maths that are used in the CS field rely on calculus. (Yes, I know that's not what you suggested -- but the OP did.)
As far as dismissing the DCT is concerned, there's no reason to study it in depth once you've studied the DFT. The DCT *is* the DFT, except that it only applies to even functions. The only thing you need to know about the DCT is that it can be more efficient to do than the DFT, but it only applies to even functions. Same goes for the DST, except it only applies to odd functions. Other than that, there's nothing special you need to know beyond the DFT.
I would just like to stress that -- as linguae notes -- Computer and Software Engineering are understood to be two very widely different fields.
* Software Engineering is an attempt to turn software development in a proper engineering discipline. This is important, obviously, because the lack of discipline in software projects that often results in failure can be addressed by applying rigorous engineering methodology. * Computer Engineering is an attempt to take electrical engineering and merge it more with the software side of things. This is important because at the higher end of modern electrical engineering, we're using more and more software to get things done. Stuff like VHDL and DSPs are taking over, so EE's need to know how software works. And your typical CS-rooted programmer usually doesn't have the correct mathematical background to do the programming him/herself.
(Note that I am not saying that CS people aren't good enough at math -- I'm saying that they usually don't have the correct background. Yeah, we EE people use boolean algebras, but we also use various transforms and differential equations, which usually either get no treatment or very brief and shallow treatment in CS programs.)
And the reason I ask about what domain specific version you took is because well, if you took the MechE test, then you did take the domain for your degree;)
AeroE is just a highly focused MechE degree -- at least, it is as taught at most places.
(In my case, I took my FE in the EE domain, but *technically* my degree is in Computer Engineering. Which is to say, my degree is just a focused EE degree that gives up some analog focus in favor of some digital focus)
It's called the "FE" (Fundamentals of Engineering) exam. It's hard to cheat on.
1. They give you a reference book which has all the equations that are on the exam. Obviously, equation-based cheat-sheets are useless. (Keep in mind that this book has >100 pages) 2. The breadth of the test is so large that any cheat-sheet you would use wouldn't cover 5% of the material, or would be completely obvious to the proctors. (Remember, the official equation book is >100 pages) 2. They require you to use calculators from an approved list -- and the first requirement is that the calculator not be able to store equations or programs. 3. They check ID to verify you are who you say you are, have assigned seating, and check the ID versus the assigned seating versus the exam ID while you're taking the exam.
I'm sure they do other stuff too.
Pass rate on the test is apparently about 50% for first timers, about 55-60% for second timers (iirc). Making sure your engineer has taken the FE exam with the domain specific test and passed it is a good way to make sure your guy knows *something.*
If you want what should be a legal method of dealing with this, make a sound cancellation device.
To make one, you basically need a microphone, a bandpass filter in the frequencies he's emitting, an op amp that is set up to shift the input 180 degrees (negative unity gain), and a speaker. If you're the kind of person who knows a little about electronics, it shouldn't even be too hard or expensive.
If you station a few of these around his house, you might be able to cancel out the vast majority of the noise. The key will be to try to put these as close to directly between the listener and the noise maker as possible.
>> 8. You can do things that you missed out on in your undergraduate school. It's a second chance.
> If you need a second chance. But if grad students are folks who needed a second chance to get it right, what does that say about their abilities?
There are plenty of reasons why you might have "missed out" on something in your undergraduate program. For example, maybe you're just a smart cookie, and your field of interest is deep enough within the field that by the time you have laid the foundations to learn about the subject, you've coincidentally earned your undergraduate degree. (example: any reasonably deep treatment of modelling signals as stochastic processes has a pre-requisite tree over with multiple branches over 8 semesters deep). Or maybe you wanted to take some classes, but you were in one of those ABET accredited engineering programs that are wound up so tight with requirements that there are almost no electives.
Ineptitude is a possible reason, but it is by no means implied.
Actually, I think it's referencing an earlier version of the game (than the NES). The arcade version of Bionic Commando, which preceded the NES version, had much better graphics.
Simple application of the notions of supply and demand suggest that the demand for CS jobs is slightly outpaced by the supply, as of 2004. No amount of spin from the various megacorps can deny this.
True "shortages" should result in humoungous real gains in compensation, similar to what we saw in the late 1990's. Now, it *may* be the case that the corps forsee future shortages based upon the traditional growth of the industry versus the current reduction in people entering the field; that much could be true. But as of right now, it appears as if supply is slightly outpacing demand.
It's impossible to provide prioritized traffic without degrading best effort traffic. If you have a certain amount of bandwidth between two points, and you have priority traffic, then by definition some of that bandwidth is going to be preferentially allocated to the priority traffic -- meaning that there's less for best-effort and thusly degredation for best effort.
The only time when there would be no degredation is when there is enough bandwidth for everyone -- at which point, the priority system is worthless because there's no need to prioritize.
Slashdot Mirror
If you're getting offers of 30-40% higher and taking them, as an employer I don't think I'd blame you for hopping.
The problem is going to be this: You're costing your employers money every time you do this. Lots and lots of money. It costs money to go through the hiring process, the process of orienting you (during which time you are less productive and still getting paid), the process of processing you (HR setting up payroll, insurance, etc), and worst of all -- the opportunity cost of hiring someone who leaves in a couple of months (ie, loss of productivity due to your orientation time + hiring time of the next guy + orientation time of the next guy).
Unless you are extraordinarily compelling, I'd be inclined to pass on you as an employer unless I was sure there was something I could do to keep you should you get a better offer -- and I'd have to be willing to do it, too.
Mostly, when you make a habit of hopping, what you need to consider before you hop is:
1. If the new job turns sour, am I willing to put up with any shit they give me, no matter how bad it is.
2. Is the company going to be in a position to release me in the near future (ie, due to layoffs or because I'm a fuck up)
The reason you need to consider these is because with each hop you make in a short amount of time, the danger of the aforementioned hiring manager passing on you due to your hopping increases. You do NOT want to be without a job when you cross the line and become a radioactive hire due to job hopping.
And engineers don't learn higher math. Or for the most part, higher level physics either. When you get into the higher level stuff in either of those fields, they pretty much sit you down and say, "Sorry to do this to you, but you know all that stuff we spent the last two years teaching you? We've got to scrap it all in order to proceed. It just won't cut it for what we need to do going forward." On the math side, this is where they shit-can the Reimann integral and build you up to the Lebesgue integral. On the physics side, this is where they shit-can Newtonian physics and build you up to the modern stuff.
And the stuff that they start teaching you at that point... well, computers don't do it very well. It often involves proofs. Computers are bad at proofs. It often involves measures of uncertainty. Computers are bad with measures of uncertainty.
If you really wanted to, you could do it with analog components, it's just probably not worth the trouble. If all you really what is high fidelity, just use a DSP system that quantizes with more bits; instead of quantizing at 16 bits like a CD, quantize at 64 or 128.
Use enough bits in the processing of the signal, and no human will be able to tell the difference. (see "quantization noise" for details)
Punishments that do not require a court martial are generally limited to short term confinement (30 days or less), "restriction to limits" (60 days -- I think this means essentially means allowed to go only to certain places), loss of pay, punishment duty ("Clean those latrines, Private!") or rank adjustment. Reduced rations are also a possibility, but are generally limited to very short terms -- 3 days or so. See subchapter III for more information.
All other punishments not prescribed under subchapter III require a court martial.
The next most important thing is to look at those smaller logical issues and be able to say, "These are the things I need to know in order to work on those smaller tasks."
And finally, when you say, "These are the things I need to know", being able to honestly evaluate whether you actually know how to do them and being able to start to learn how to do them is the final step.
For example, I really don't know how I would go about writing an emulator. So, let's take that for the example. What are the things I would expect an emulator to be able to do?
So, what do I need to know in order to do these things?
Load a game: I need to figure out how to generate a ROM from a device -- cartrige, cd, DVD, etc. Then I need to be able to load that into storage of some kind (memory, hdd, etc) on my emulating device.
Execute the game code: Okay, so what kind of hardware and software did the original game code run on? Was it x86? Z80? MOS 6502? How do I go about mapping the binary instruction code for the original CPU platform to my current CPU platform?
Accept input: How do I take input from my keyboard/mouse/controller and map it to the input routines of the game code?
Display video game output: How do I display the kind of graphics that the original ROM would display on the emulator host? How would I map the graphics calls of the ROM to equivalent graphics calls on the emulator host?
Play audio output: How do I play the sound on the emulator system, and how do I map the ROM calls to the host system's audio output?
Intercepting "load"/"save": How does the original system handle save games? How can I transparently intercept ROM calls to those saved games and map them to something that makes sense to the host system?
And there's probably plenty more that I'm missing. But being able to just start like that is a huge deal, and being able to realize, "Gee, I really don't know how that would work. But maybe if I look at this resource here, I may begin to learn how to..."
If they're promising you things and not delivering them, you need to take them to task for it... unless you are satisfied with the fact that they will continue to promise things and not deliver.
It's really that simple.
You justify it by saying, "This is what I want. And I'm willing to pay the associated costs with making it happen."
That means losing out on some salary and possibly some perks. Is it worth it to you? Then very simply, find another job -- in the company or out -- that makes it happen.
If you're not willing to pay the costs, then dammit, don't do it.
As far as *how* to make it happen, either find someone willing to make it happen, start your own company where you can make it happen...
Or go back, get your PhD, and sign on at a research institution. You'll get plenty of technical challenges
Fixed. There are factors other than money, and there are factors which cannot be accounted for in terms of money.
Just sayin'.
Mathematicians are in the business of (among other things) taking mathematical equations that are currently unsolvable and finding ways of solving them.
At one point, taking the square root of the number "-1" was a totally unsolvable problem. It didn't make any sense, because a negative number times a negative number yielded a positive number. So to handle this, they made up a number i, defined it as the square root of -1, and found that hey, this number was consistent and worked with all already extant mathematical rules. Suddenly, you can make sense of equations involving that number.
As far as imaginary numbers being useful is concerned, well, as people mentioned, they're critical in electrical engineering. One of the most impotant numbers is exp^(ix) which is equal to "cos(x)+i*sin(x)". Fourier proved a long time ago that any periodic signal can be expressed as a sum of sines and cosines. Which means that any signal can be expressed as a sum of exp^(ix)... which is exactly what the Fourier transform does. It takes an input signal and transforms it into a sum of sines and cosines.
The Fourier transform is absolutely critical in electrical engineering. It is a transform that takes a time domain representation of a signal and converts it to a frequency domain representation. It makes hard problems easy, and totally intractable problems tractable.
If you take the output of one system ( f(x) ) and tie it into the input of another (g (x) ), the resultant output in the time domain is given by an annoying process known as convolution (integrate f(x)*g(x+t) dt from negative infinity to infinity). In the frequency domain, you just multiply the two functions, a process which is much easier.
Also, modelling the signal in the frequency domain allows you do look at what the components are of a signal by their frequency (obviously). You can see how much power is in any given frequency, for example. This is pretty useful when looking at RF signals, for example -- you can see what signals exist on what RF frequencies, what needs to be filtered out, etc.
Also, in the frequency domain, there are characteristics you can look for that will imply stability or instability in a system that you can identify at a glance; in the time domain, the only way to find out these characteristics is to do some rather annoying proofs. For example, in the time domain, if I want to prove that a system is BIBO stable (ie, bounded input always yields bounded output), I have to actually *prove* that the system will never go higher than a certain point. In the frequency domain, I can simply look at the the poles -- what values of frequency will cause the denominator of the frequency domain representation to go to zero -- and apply a couple of rules that tell me whether the system is stable based upon where the poles are.
Imaginary numbers are absolutely critical to electrical engineering. You can't do anything beyond the most trivial of things without them.
Well, I was thinking symbolic multiplication, not constant multiplication. I always suspected that the FFT could be good for constant number multiplication, but I figured that the big-Omega of symbolic would be along the lines of n^2.
:(
Which is why I was suprised when you mentioned the FFT being n log n -- but that doesn't seem to help me.
Or are you just talking about using the FFT to multiply large numbers (which is not nearly so interesting...)
Oh, heh. You already said: FFT.
I suspected that the FFT might manage it; is that actually correct?
Are you saying that there's an algorithm that lets you do algebraic multiplication (FOIL style) in O(n log n) time?
ie, (x1 + x2)(x3 + x4) = x1x3+x1x4+x2x3+x2x4
I've been looking for just such an algorithm. What is it?
Of course, you can't *really* understand statistics and probability without calculus.
So, no, you don't want to replace calculus. You want statistics on top of it.
I agree that vector calculus should probably be dropped. It's just doing integrals multiple times, and so is really just an extension of the basic calculus series. If you need vector calculus, it is trivial to learn provided you know the stuff that typically proceeds it.
Dropping calculus altogether is boneheaded; too many results of other higher maths that are used in the CS field rely on calculus. (Yes, I know that's not what you suggested -- but the OP did.)
As far as dismissing the DCT is concerned, there's no reason to study it in depth once you've studied the DFT. The DCT *is* the DFT, except that it only applies to even functions. The only thing you need to know about the DCT is that it can be more efficient to do than the DFT, but it only applies to even functions. Same goes for the DST, except it only applies to odd functions. Other than that, there's nothing special you need to know beyond the DFT.
I would just like to stress that -- as linguae notes -- Computer and Software Engineering are understood to be two very widely different fields.
* Software Engineering is an attempt to turn software development in a proper engineering discipline. This is important, obviously, because the lack of discipline in software projects that often results in failure can be addressed by applying rigorous engineering methodology.
* Computer Engineering is an attempt to take electrical engineering and merge it more with the software side of things. This is important because at the higher end of modern electrical engineering, we're using more and more software to get things done. Stuff like VHDL and DSPs are taking over, so EE's need to know how software works. And your typical CS-rooted programmer usually doesn't have the correct mathematical background to do the programming him/herself.
(Note that I am not saying that CS people aren't good enough at math -- I'm saying that they usually don't have the correct background. Yeah, we EE people use boolean algebras, but we also use various transforms and differential equations, which usually either get no treatment or very brief and shallow treatment in CS programs.)
Women like 'em because they're apparently romantic.
;)
Guys like 'em because apparently women think they're romantic
Don't you mean:
;)
To immigrate to canada you must speak "french", eat poutine and KD, and watch HNIC. It snows all year long and sorry we're full!
And the reason I ask about what domain specific version you took is because well, if you took the MechE test, then you did take the domain for your degree ;)
AeroE is just a highly focused MechE degree -- at least, it is as taught at most places.
(In my case, I took my FE in the EE domain, but *technically* my degree is in Computer Engineering. Which is to say, my degree is just a focused EE degree that gives up some analog focus in favor of some digital focus)
Well, I'm not saying it's a test that identifies world beaters. Just saying that you have to know *something*.
If you can do calculus reasonably well, you can probably pass that test.
Which domain did you take it in?
It's called the "FE" (Fundamentals of Engineering) exam. It's hard to cheat on.
1. They give you a reference book which has all the equations that are on the exam. Obviously, equation-based cheat-sheets are useless. (Keep in mind that this book has >100 pages)
2. The breadth of the test is so large that any cheat-sheet you would use wouldn't cover 5% of the material, or would be completely obvious to the proctors. (Remember, the official equation book is >100 pages)
2. They require you to use calculators from an approved list -- and the first requirement is that the calculator not be able to store equations or programs.
3. They check ID to verify you are who you say you are, have assigned seating, and check the ID versus the assigned seating versus the exam ID while you're taking the exam.
I'm sure they do other stuff too.
Pass rate on the test is apparently about 50% for first timers, about 55-60% for second timers (iirc). Making sure your engineer has taken the FE exam with the domain specific test and passed it is a good way to make sure your guy knows *something.*
If you want what should be a legal method of dealing with this, make a sound cancellation device.
To make one, you basically need a microphone, a bandpass filter in the frequencies he's emitting, an op amp that is set up to shift the input 180 degrees (negative unity gain), and a speaker. If you're the kind of person who knows a little about electronics, it shouldn't even be too hard or expensive.
If you station a few of these around his house, you might be able to cancel out the vast majority of the noise. The key will be to try to put these as close to directly between the listener and the noise maker as possible.
>> 8. You can do things that you missed out on in your undergraduate school. It's a second chance.
> If you need a second chance. But if grad students are folks who needed a second chance to get it right, what does that say about their abilities?
There are plenty of reasons why you might have "missed out" on something in your undergraduate program. For example, maybe you're just a smart cookie, and your field of interest is deep enough within the field that by the time you have laid the foundations to learn about the subject, you've coincidentally earned your undergraduate degree. (example: any reasonably deep treatment of modelling signals as stochastic processes has a pre-requisite tree over with multiple branches over 8 semesters deep). Or maybe you wanted to take some classes, but you were in one of those ABET accredited engineering programs that are wound up so tight with requirements that there are almost no electives.
Ineptitude is a possible reason, but it is by no means implied.
Actually, I think it's referencing an earlier version of the game (than the NES). The arcade version of Bionic Commando, which preceded the NES version, had much better graphics.
Linked article states that CS jobs went up 2.3% for the period Jan 2004-Dec 2004. Keep in mind that the inflation rate for the same period was 2.75% (http://inflationdata.com/Inflation/Inflation_Rate /InflationCalculator.asp), resulting in a net decrease in effective wages.
Simple application of the notions of supply and demand suggest that the demand for CS jobs is slightly outpaced by the supply, as of 2004. No amount of spin from the various megacorps can deny this.
True "shortages" should result in humoungous real gains in compensation, similar to what we saw in the late 1990's. Now, it *may* be the case that the corps forsee future shortages based upon the traditional growth of the industry versus the current reduction in people entering the field; that much could be true. But as of right now, it appears as if supply is slightly outpacing demand.
It's impossible to provide prioritized traffic without degrading best effort traffic. If you have a certain amount of bandwidth between two points, and you have priority traffic, then by definition some of that bandwidth is going to be preferentially allocated to the priority traffic -- meaning that there's less for best-effort and thusly degredation for best effort.
The only time when there would be no degredation is when there is enough bandwidth for everyone -- at which point, the priority system is worthless because there's no need to prioritize.