There seems to be a fundamental misconception in this entire dialog between "Computer Science" (as define by the ACM/academic folks and their curriculums) and learning the skills needed to be useful as a Software Engineer in industry. These are very different things. The proponents should be clear exactly what it is they think all kids should be learning: do we want to train them to do research in Computer Science, or do we want them to get a more vocational education for the vast number of non-academic jobs?
I would not suggest sacrificing salary earning years for a temporary career change, which is what I see as the summary of the situation. To do anything for an entire career and be happy requires that your are extremely passionate and interested in the field. I am not sensing that sort of level of interest, and that the priorities here are to be winding up doing something other than engineering in the long term.
I can understand feeling bad about not being able to contribute a certain way in your current environment, but everyone is limited in the things they can contribute in some way. It is a bit of the maturing process to be able to settle for not being able to do everything (as much as many of us would like to).
If the desire to program is deeper than I am giving credit for here and you are willing to sink significant time into, I suggest viewing the language/programming environment as the tool, and the problem as the focus. If your goal is to set out to "learn ruby-on-rails", you'll not get much out of it. If you goal is to solve a particular problem, and you happen to choose ruby-on-rails as the way to realize the solution, that is the way to learn something the most important skills you need as a programmer (and what will be relevant when the technology trend-du-jour changes).
There's all the resources you need on-line at your fingertips to learn as much about programming as you want, so it is all a matter of how much you are willing to sacrifice your free time and energy to dive into it.
One last tip: If you focus on real problems that interest you and not academic exercises, you will learn the important skills faster.
I am surprised to see people even thinking this is a debatable issue. Discrete math and graph theory: hands down. Sure, if you are going to be doing signal processing and special-purpose projects, then differential equations can help, but what percentage of programmers actually wind up working in those areas?
Most ACM-based CS curriculum do a big disservice to 95% of the students, but those where Discrete Math and Graph Theory are requirements do les harm than most.
The most important part pointed out here: how can you look for "creativity" until you first define it?
The simplest thought could be creative for a given person given their experiences and the exact same thought for someone else would not be deemed creative due to a different set of experiences. How then can anyone judge the "creativeness" of a thought without having a complete knowledge of the entire past experiences of a person?
"Depends" is absolutely the right answer here, as it is for just about every software decision.
The log4j/log4perl/log4etc mechanism will serve the majority of needs, but not all of them. However, you should always start there unless you have a very good reason not to. You'll soon enough find out if you need something different.
I think trying to address just "pirates" is oversimplifying the issue. I can think of a number of separate motivations for why game copying exists, and this amounts to a number of different personality types.
1) the fear - you only have to shell out decent money once for a crappy game to want some form of guarantee or trial period.
2) the pragmatism - playing a video game is fun, but you can live without them and spend your money on something more practical. If it's free, you'll play, but if you have to pay, you won't. (Note that counting these people as "lost sales" is a fallacy.)
3) the challenge - the age-old root of of game copying is those that like a good challenge/puzzle, especially when adding the stroking of the ego when there's a group in a quasi-competition.
4) the greed - this is the professional pirate, who lacks any qualms about doing it, and knows there's some money to be made.
Not to mention that "safe" here is probably assuming you do not care about security issues originating from within your system. SSH forwarding/tunneling ability can result in inadvertently or deliberately introducing a whole set of new security issues to worry about: "All your port belong to us."
Nothing new to add, but did want to emphasize that if a text-only terminal is all you need, 'screen' is the way to go. It is one of the lesser known unix goodies, and a true "wonder tool": a tool you cannot live without once you use it.
The quick primer:
First time:
ssh mymachine
screen
<do some work>
CTRL-a-c <create another login session>
<do some more work in diff dir>
CTRL-a-1 <back to first login session>
CRTL-a-d <disconnect>
exit
Future times:
ssh mymachine
screen -r <resume screen>
CTRL-a-2 <back to second login session>
<do some work>
CTRL-a-d <disconnect>
exit
You can create many login sessions inside one screen instance or launch multiple instances of screen on the same box by giving them a name. See the man page for all the goodness.
Basic fact of life is that every type of job gets old when you do the same thing over and over. If the field you are in is something you tend to have interest in, you are fortunate, so then don't switch fields: find a job with better problems to apply your skills to.
In the tech field, a tip I would give is to not focus on the technology, but on solving interesting problems. That's the core of what is interesting in CS/IT and what draws us to it.
There's a handful of useful CS/IT ideas, and all the rest is the same stuff re-hashed, re-packaged and re-hyped (as you seem to have discovered). Find a job with problems to solve, not technology to learn. Learning new technologies is only useful when it lies on the path from problem to solution. Otherwise it is just technical masturbation.
Football is as random as basketball (or any other sport). You can win by 6 points as easily as lose by 6 points *if* the two teams are equally matched (on that given day). When teams are not equally matched, then randomness does not play much of a role, which is why good teams over the course of a season have good records and bad teams have bad records *in any sport*.
If you have management that doesn't really understand what programming and programming personalities are all about, you can get internally inconsistent, half-thought out ideas as well as much pressure to do it 'now' instead of 'right'. If your programming team is more junior and easily swayed by the management's idea of software development, then there are no checks and balances and you get rushed out, low-quality code, with a never-ending cycle of quick patches that is ugly, bug-prone and a nightmare to maintain. And that's assuming you have a quality team of junior programmers. Mix in average or below-average programmers and......I shudder.
AI might not be the difficult part
on
Trans-Atlantic Robots
·
· Score: 2, Insightful
I am not convinced the AI is the difficult part of this. Developing a seamless hardware solution is very difficult, assuming it need to be very robust. The salty sea air only makes this harder on the hardware, especially the electronics. However good you think you can make the AI/software part, you might want to look around for someone that can do an even better job on the hardware side. I think (good-hardware + average-software) > (average-hardware + good-software) in the domain of this contest.
Indeed they have. Guess I am a couple years too late to realize that slashdot ain't the place to be to find "news". Sad, but nothing lasts forever I guess.
I only reply to concur with this viewpoint based on my long experiences in tech, non-tech, government, small company, large company, academic, non-academic, etc. If you think your corner of the world is screwed up, an that sanity just requires leaving your corner....guess again.
Everyone hopes there is some sanity in the world, but few have the opportunity to find it. It's there, somewhere, but you usually have to work awfully long and hard to find it. So when you do, don't blow it by being either too young and stupid to appreciate it, or too old and jaded to magnify the minor faults.
If you *really* understand how each level of the hardware through OS through app architecture work, they you *too* should be confused about the dividing line. It is the moving of these lines and fuzziness between them which have defined the *real* advances in computer technology (as opposed to things line "AJAX" which people think to be some radical new technology advancement.)
Two rants in one posting...apologies if I exceeded the limits.
Sure, it serves as a very useful recruiting tool. They will find the people willing to spend time and effort on an arbitrary problem in the vague hopes of landing a job. So when you dangle a real paycheck in front of them, there is no end to what hoops you can make them jump through.
Personally, I think "brainy" people should be smarter than to want to play these sorts of games.
Slashdot Mirror
There seems to be a fundamental misconception in this entire dialog between "Computer Science" (as define by the ACM/academic folks and their curriculums) and learning the skills needed to be useful as a Software Engineer in industry. These are very different things. The proponents should be clear exactly what it is they think all kids should be learning: do we want to train them to do research in Computer Science, or do we want them to get a more vocational education for the vast number of non-academic jobs?
The only possible interpretation of any research whatever in the 'social sciences' is: some do, some don't. -- Ernest Rutherford
Being among the shadiest companies with aggressive policies on squeezing their customers for everything they can, this is a surprise?
I would not suggest sacrificing salary earning years for a temporary career change, which is what I see as the summary of the situation. To do anything for an entire career and be happy requires that your are extremely passionate and interested in the field. I am not sensing that sort of level of interest, and that the priorities here are to be winding up doing something other than engineering in the long term.
I can understand feeling bad about not being able to contribute a certain way in your current environment, but everyone is limited in the things they can contribute in some way. It is a bit of the maturing process to be able to settle for not being able to do everything (as much as many of us would like to).
If the desire to program is deeper than I am giving credit for here and you are willing to sink significant time into, I suggest viewing the language/programming environment as the tool, and the problem as the focus. If your goal is to set out to "learn ruby-on-rails", you'll not get much out of it. If you goal is to solve a particular problem, and you happen to choose ruby-on-rails as the way to realize the solution, that is the way to learn something the most important skills you need as a programmer (and what will be relevant when the technology trend-du-jour changes).
There's all the resources you need on-line at your fingertips to learn as much about programming as you want, so it is all a matter of how much you are willing to sacrifice your free time and energy to dive into it.
One last tip: If you focus on real problems that interest you and not academic exercises, you will learn the important skills faster.
I am surprised to see people even thinking this is a debatable issue. Discrete math and graph theory: hands down. Sure, if you are going to be doing signal processing and special-purpose projects, then differential equations can help, but what percentage of programmers actually wind up working in those areas?
Most ACM-based CS curriculum do a big disservice to 95% of the students, but those where Discrete Math and Graph Theory are requirements do les harm than most.
Choice of language begins with the problem being solved. not the OS you happen to be developing on.
Are you just looking to tinker in the GNU/Linux world, or do you have a specific problem?
Simple Web/DB dev? -> php/js
Heavier Web/Server dev? -> Java
OS-related dev? -> C/C++
Heavy string processing? -> perl (or python is speed does not matter)
System admin-type problems? -> bash/perl
The most important part pointed out here: how can you look for "creativity" until you first define it?
The simplest thought could be creative for a given person given their experiences and the exact same thought for someone else would not be deemed creative due to a different set of experiences. How then can anyone judge the "creativeness" of a thought without having a complete knowledge of the entire past experiences of a person?
"Depends" is absolutely the right answer here, as it is for just about every software decision.
The log4j/log4perl/log4etc mechanism will serve the majority of needs, but not all of them. However, you should always start there unless you have a very good reason not to. You'll soon enough find out if you need something different.
I think trying to address just "pirates" is oversimplifying the issue. I can think of a number of separate motivations for why game copying exists, and this amounts to a number of different personality types.
1) the fear - you only have to shell out decent money once for a crappy game to want some form of guarantee or trial period.
2) the pragmatism - playing a video game is fun, but you can live without them and spend your money on something more practical. If it's free, you'll play, but if you have to pay, you won't. (Note that counting these people as "lost sales" is a fallacy.)
3) the challenge - the age-old root of of game copying is those that like a good challenge/puzzle, especially when adding the stroking of the ego when there's a group in a quasi-competition.
4) the greed - this is the professional pirate, who lacks any qualms about doing it, and knows there's some money to be made.
Not to mention that "safe" here is probably assuming you do not care about security issues originating from within your system. SSH forwarding/tunneling ability can result in inadvertently or deliberately introducing a whole set of new security issues to worry about: "All your port belong to us."
Nothing new to add, but did want to emphasize that if a text-only terminal is all you need, 'screen' is the way to go. It is one of the lesser known unix goodies, and a true "wonder tool": a tool you cannot live without once you use it.
The quick primer:
First time:
ssh mymachine
screen
<do some work>
CTRL-a-c <create another login session>
<do some more work in diff dir>
CTRL-a-1 <back to first login session>
CRTL-a-d <disconnect>
exit
Future times:
ssh mymachine
screen -r <resume screen>
CTRL-a-2 <back to second login session>
<do some work>
CTRL-a-d <disconnect>
exit
You can create many login sessions inside one screen instance or launch multiple instances of screen on the same box by giving them a name. See the man page for all the goodness.
Basic fact of life is that every type of job gets old when you do the same thing over and over. If the field you are in is something you tend to have interest in, you are fortunate, so then don't switch fields: find a job with better problems to apply your skills to.
In the tech field, a tip I would give is to not focus on the technology, but on solving interesting problems. That's the core of what is interesting in CS/IT and what draws us to it.
There's a handful of useful CS/IT ideas, and all the rest is the same stuff re-hashed, re-packaged and re-hyped (as you seem to have discovered). Find a job with problems to solve, not technology to learn. Learning new technologies is only useful when it lies on the path from problem to solution. Otherwise it is just technical masturbation.
Football is as random as basketball (or any other sport). You can win by 6 points as easily as lose by 6 points *if* the two teams are equally matched (on that given day). When teams are not equally matched, then randomness does not play much of a role, which is why good teams over the course of a season have good records and bad teams have bad records *in any sport*.
If you have management that doesn't really understand what programming and programming personalities are all about, you can get internally inconsistent, half-thought out ideas as well as much pressure to do it 'now' instead of 'right'. If your programming team is more junior and easily swayed by the management's idea of software development, then there are no checks and balances and you get rushed out, low-quality code, with a never-ending cycle of quick patches that is ugly, bug-prone and a nightmare to maintain. And that's assuming you have a quality team of junior programmers. Mix in average or below-average programmers and......I shudder.
I am not convinced the AI is the difficult part of this. Developing a seamless hardware solution is very difficult, assuming it need to be very robust. The salty sea air only makes this harder on the hardware, especially the electronics. However good you think you can make the AI/software part, you might want to look around for someone that can do an even better job on the hardware side. I think (good-hardware + average-software) > (average-hardware + good-software) in the domain of this contest.
Indeed they have. Guess I am a couple years too late to realize that slashdot ain't the place to be to find "news". Sad, but nothing lasts forever I guess.
Big companies...bad.
Small companies....sometimes good.
I only reply to concur with this viewpoint based on my long experiences in tech, non-tech, government, small company, large company, academic, non-academic, etc. If you think your corner of the world is screwed up, an that sanity just requires leaving your corner....guess again.
Everyone hopes there is some sanity in the world, but few have the opportunity to find it. It's there, somewhere, but you usually have to work awfully long and hard to find it. So when you do, don't blow it by being either too young and stupid to appreciate it, or too old and jaded to magnify the minor faults.
If you *really* understand how each level of the hardware through OS through app architecture work, they you *too* should be confused about the dividing line. It is the moving of these lines and fuzziness between them which have defined the *real* advances in computer technology (as opposed to things line "AJAX" which people think to be some radical new technology advancement.)
Two rants in one posting...apologies if I exceeded the limits.
Sure, it serves as a very useful recruiting tool. They will find the people willing to spend time and effort on an arbitrary problem in the vague hopes of landing a job. So when you dangle a real paycheck in front of them, there is no end to what hoops you can make them jump through.
Personally, I think "brainy" people should be smarter than to want to play these sorts of games.
95 percent (by volume in reports) of of Gartner's reports are useless.