Well, any time you're storing data in a central place, you have a greater consequence of failure. That's a downside of "cloud computing", or any web application that stores data in a database too.
The alternative approach is everyone to have a local version of their data, which will be lost by individuals all the time but not by everyone all at once.
Obviously, if you have a server that's a single point of failure for your company, and you botch a maintenance, something went very wrong. And not having a backup - it seems strange for a company that's been around the block a few times and has big resources behind it. You have to write this off as more of a specific failure and not a failure of the concept of storing data on a remote server.
I do have a good friend that works for Danger - I really don't envy the week he must be having.
Good! Cursive is a skill for writing fast, not for writing legibly. I haven't used it since leaving school.
Print is easier to read in the circumstances where you can't use a computer, and those situations are rapidly decreasing. The vast majority of interaction and professional work is typed these days.
This is the counterpoint to the recent article asking if typing should be taught in schools - yes, in elementary, in the slot that cursive used to live in.
Well, a good interview test isn't about trivia or things you could find in 30 seconds of google. It's things like: What does this code sample print to the screen? Write a regular expression to capture the phone numbers from a file with the following sample data. Write a SQL statement to select all the people from these two tables who have an outstanding balance (ie, can you do a join). That sort of thing.
Well, I mean, it's hard to really compare the before and after, because you don't follow the people you don't hire. It's all going to be anecdotal. That doesn't equate to blind, though.
But anecdotally, we expanded at WhitePages.com from about 8 programmers before we implemented the test, to a team of about 20, in the space of about a year. The quality of hires after that point was, IMO, very high, and more consistently good than before. (Only one was an abject failure, and that was for personal reasons that had little to do with his capabilities.)
And it's a mistake to distinguish between 'taking tests' and 'actually writing code' - what do you think is on these tests? (Hint, it's writing code.) Multiple choice is okay (and my current job has one of those), but actually writing real code is substantially better.
I've worked several places that had some sort of practical skills test for programmers.
I consider them a strong success.
There's a surprising number of people that can talk a really good game, but fall apart when asked the most basic actual questions. And, conversely, people who aren't extroverts or for whatever reason aren't stars in the verbal part of the interview, but clearly know their stuff when given a written test. It's a really good way to fairly judge technical skills across candidates, and weed out the fakers before you have to fire them later.
And as an employee, I like working with smart, competent people. I know how much, from experience, a bad hire wastes my time and ruins morale, so I'm happy to work for places that put out effort one way or another to not enter into this trap.
Anyone who'd refuse on principal, I'd worry is either a) faking it, or b) too arrogant to work well with others. A good candidate is happy to prove that they're a good candidate, and won't have to work with idiots.
A test isn't the _only_ way to do this. Any sort of nice, concrete technical grilling will do. But for a programmer, it _must_ involve actually writing code of a non-trivial nature. You can't believe resumes - even if people aren't lying, a Senior Programmer at one shop may only be barely competent at another, and not even realize that the bar is set differently.
Of course, the quality of a test can vary just like the quality of an interview question, but the goal is good for the company _and_ the employees, and in my experience it works better than most techniques.
Now, if your shop isn't terribly compelling based on product, and you're desperate to not turn people away... well, you probably should be looking for places that feel like they need a test to screen out unqualified candidates, so you can stop hating your job, and not worry about fixing this particular problem.:)
You're not going to come out of school with the expertise to be a professional software engineer in any case, whether you focus on one language or many. It's a hard job, and 90% of what makes it hard are factors of time longer than a quarter/semester, and factors of dealing with non-Computer Scientists and people with demands other than your professor.
It's okay, we (the hiring industry) know this, and a lot of us are willing to put in the investment to do the appropriate apprenticeships. CS Degrees are one way to select people who are more likely to succeed, but it's a discipline that's only learned through doing for the most part, and best done with people who are more senior teaching you. (I self-taught a lot after my CS degree, but I advanced more in the first year I had a real mentor than I did in the previous 6 I was doing it mostly myself. But people do vary, and if you're the exception, great.)
I'd recommend the variety approach, because people _do_ vary. Some people love the rigid structure of a Python, the massive infrastructure available to Java, the exposure of the bare metal of C, the total control of Assembly, the flexibility and rapid development of Perl, or whatever suits you. At this stage: Try a lot! Find a language you have fun with, and code more in that. You'll be a lot happier with your job if you don't find the language you use every day to be high in however you define bullshit. And if you don't fall in love with a particular approach, you've got a lot more starting nodes for your resume and can do a broader job search.
Employers have hired college students before, and we know that what you learn in your CS classes with respect to being a professional programmer is _really_ not that much, and hire more for people who we think will learn quickly, not be a pain in the ass, and actually have some amount of work discipline. Whether someone took one or three C# classes is not very interesting. (Personal side projects using the language of choice, those are more interesting.)
I tend to think that the goal is not to learn specific instances of skills in college (ie, a particular language), but learn principles. It's very much worth any science student's time to know a programming language. It's a reasonable thing to learn programming well enough to pick up any language - but really, this is one path of many, and is probably best called 'minor in computer science'. Yes, Fortran is not exactly cutting edge, but it's a fine example of one kind of language.
If you wanted to learn the language most commonly used in science labs, sad to say as a programmer type, probably spend some time with Visual Basic.
As an ecosystem, the best thing is probably variety. It's good that some percentage of new graduates know Fortran, so it doesn't become burdensome to hire people to work at places with legacy codesets, but it's also good that it's possible to hire someone working in a language that might be more suited to what you're doing. Or to a different type of brain. Diversity is good in a larger sense - someone who might be a mediocre Java programmer might be a star Perl programmer, and vice versa. The more diversity gives more individuals a chance at finding a niche they excel in. I think this aspect is overlooked massively when people talk about 'the right tool for the job'.
If you're a scientist that likes programming, though, a minor in CS so you can pick up whatever language comes your way is an approach with a lot of practical potential. (Or a double major, but CS is hard and most Science programs are hard, so I'm not sure it's worth it - even the people that hire programmers that like degrees would not find fault with a Physics degree and a CS minor.)
The same way anyone else gets respect. Actually get to know your coworkers, make sure that they know you understand their concerns and needs (and it helps if it's true), be someone who isn't just the weird guy in the server room that nobody ever talks to.
Don't consider getting to know your coworkers to be 'politics'. That's an anti-pattern.
It's not a cure-all, but if at least some people start thinking of you as a human with a name, and actually trust you, it helps a lot.
And also, return the favor. They're not just users violating policies and expecting miracles - they're stressed out people with demanding jobs that need support. If you don't respect them, it's _blindingly obvious_ and they will respond in kind.
Not everyone's personality is suited to this approach, but a little bit of empathy goes a long ways.
I went to Oregon State, a mid-level engineering school. After graduating, I moved to California and worked with recent graduates from some top schools, like UC Berkeley and Harvey Mudd and Cal Tech. (Well, Mudders certainly think very highly of their school.)
Comparing curriculum (and this was mid-90s), there was very little difference. The better schools have more interesting senior projects, but the actual education a motivated student gets is extremely similar.
Right out of school employment opportunities are a little better at the more prestigious schools, because companies target them more. They send recruiters to Stanford more than a typical state college. However, once five years has passed, very few people care, and there's wide swaths of the programming world that doesn't even care if you have a degree.
The real advantage of the more prestigious schools is networking. I don't really talk to any of my Oregon State buddies anymore. But my friends who went to, say, CalTech, seem to stay very close to their college circles. They trust each other as smart and capable, and that's a huge plus for getting interesting jobs for quite some time. Sometimes tech departments get clusters from a particular school, and it's no coincidence. I didn't value this at 17, and I should have.
Relatedly, the other big difference is quality of the other students. I was decidedly a top student at Oregon State. I'd probably have been somewhere in the middle at CalTech. I think I learned about the same, being a motivated and smart student, but there definitely exist a percentage at the lesser schools that just skate by, and waste your time in classes asking stupid questions. On the other hand, the top schools can be highly stressful. A very personal decision, if you'd rather be the top dog in a low stress environment, or be in the middle of an awesome but highly competitive environment. This choice re-presents itself throughout your career.
Note that none of the above applies to graduate school, where you're working directly with professors and learning a less generic expertise. For that, where you go matters a great deal.
This may also not be accurate outside of the West Coast. I'd easily believe we place less of a premium on prestige and pedigree than the rest of the country.
If you want to go to the liberal arts school, there won't be any problems for you, but I'd recommend the tech school because you'll make better, more useful friends. You're more likely to end up at an interesting startup with other super smart folks, more likely to make a big splash. But anyone can do these things - it just takes a little more luck and hard work post college.
Yeah, I hear some people are using this new Linux thing, but Windows 3.1 works just fine!
Seriously, there's a substantial gap between features between the two devices, including:
* Ability to record high definition on the TiVo (VCRs are very poor quality, which is easily noticeable, especially on modern televisions). Ability to record good quality of non-high def shows as well. The new boxes even record 5.1 sound. * Ease of repeated recording of favorite shows * Ability for device to know the difference between first run and rerun * Ease of delete without subsequent quality loss * Not taking up valuable space with stacks of videotapes * Ability to auto-record based on keywords (Particularly nice for sports fans), directors, actors, and such. * Auto-fill of space with shows you like. Seems small, but I _always_ have two or three Simpsons and Buffys sitting around, so I don't end up watching Home Improvement on a slow Sunday when I want to veg. * Ability to record two things at once. * Ability to watch something recorded while recording up to two live shows. * Ability to pause, rewind, and fast forward 'live' tv. Very nice if the phone rings, or if nature calls! * Ability to auto correct for schedule changes. No more losing track of a show when Fox moves it to Saturdays, or miss the last 10 minutes of Lost because it's a 70 minute episode! This is not a small feature. Tivo has an excellent track record at being on top of this kind of thing.
Now, there are downsides, mostly in the cost department, but if you consider television to be a hobby, I highly recommend tivo. (If you think TV is a waste of time, and are reading this thread, well, is trolling really a better use of time than tv? Honestly.) Other DVRs provide most of these features, and are better than a VCR, but Tivo still has the best featureset. Hopefully, they'll work out these cutting-edge-technology stumbles in a way that's good for current consumers. (But I've had the original HD box for almost a year and never had any problems.)
A career is going to take up the bulk of your time for the bulk of your life. You damn well better like what you do. If you do, if you really enjoy thinking about CS problems, then do it. You'll have energy and passion, which usually mix with experience to form competence, and that leads to money.
Everyone told me not to go into CS, that it was dead, when I graduated from High School in 1992. When I got my CS Degree in 1996, everyone was scrambling to get into this dot-com thing. Then, four years later, everyone was getting out again. Don't make career decisions based on fashions and trends like this.
If what you enjoy is actually just making money, and that's a perfectly fine thing to enjoy (if not really geeky), go into business. Minor in CS, and then become a project manager with an aspiration of management. Lots of room for business people, particularly ones who actually can understand the technology, and they get paid well too.
If you just want to be lazy, and do the minimal work to get the maximal money - forget about it. You'll be mediocre at whatever you do. If you're lucky, you can get a soul-crushing job, blend into the background, and collect a paycheck. Soul-crushing CS work pays better than average, but damn, you've made a serious mistake if you're going this route.
I'll reiterate the formula, even though it's obvious: Passion leads to Competence leads to Money. It's very hard to be competent at something you don't care about, and the odds of making money if you're not competent go way down. Some passions are harder to find regular work in than others, but if that's what you want, that's what you'll be best at, so go for it. There's almost nothing as awful as being bad at your job.
This is part of the reason why I weight college degrees so lightly when I interview people. It just doesn't mean much, when half the students only know how to google for answers. While that is a useful job skill (I google problems every week, if not every day), an employee that just does that, and isn't thinking independantly or really understanding the problems is a big problem.
Good companies to work for will generally treat this kind of attitude with a 'fired with cause'. There are a lot of bad companies out there to be an Initech slacker at, collect a paycheck, and do as little thinking as possible. I have no idea why anyone would want to end up there. So, it's kind of a self-correcting problem in that sense.
For those actually working for a college degree, it's more annoying. I have a CS degree, and I never cheated in college. (Really. Risking explusion is so not worth it.) Yes, it was obvious that some jerks were, and it leads to more experienced people like my present self finding very little corrolation between the degree and good hires, so it does devalue the diploma. But if you actually can contribute individual insights, are smart, and can get things done, you'll rise above these shortcutters very quickly. They'll work in the trenches at a job they hate, while you decide between Google or a hot startup for a career path. You'll win, in the end, 9 times out of 10. So don't worry about that other guy.
I don't really buy into the idea that languages are good for beginners or are expert only.
A programming language is good if it is easy for you to express powerful ideas in. Any language will cause you to become comfortable with it to the exclusion of others for most people; therefore, you're far better off sucking up the learning curve of a language you want to keep using, than learning Logo and Pascal and throwing them away. If a language forces you to use conceptual language that you can't get your head around, that is not the right language for you.
It's also a good idea to pick a language that's actually used if you want to have a career in it, or others will support your code later. If you don't know what language to learn, the cutting edge is probably not the place to start.
I recommend: perl, python, C, lisp. Maybe C# or Java, but my personal bias says that if you want to go that route, python is a better language. They're reasonable languages, though. If you know you have a particular need to write utility scripts for windows applications, particularly MS Office, you probably should consider VBScript, but once you've used something else, you'll never be able to go back.
If your goal is not to have a programming toolkit in your back pocket, but instead to understand programming languages, I'd recommend basic understanding of: Assembly (to really know what's going on behind the scenes), Lisp (to really see what a powerful abstract language can do), C (to have a low level control in a high level language), and perl (to have a useful blend of high level abstractions of things you don't want to worry about (memory allocation, strings) and still have a more natural syntax than pure lisp.) Once you can write a non trivial program in all four of those languages, you'll have a good understanding of what you value and don't in a language, and can make informed decisions.
(I've done all of those, and a few others, and found I like perl the best. Different problems and different people are suited towards different solutions.)
(However, with this many parenthesis in a post, you'd be right if you concluded that I also think lisp is nifty.)
I know this is probably a joke, but if I came across a cover letter or resume that had no capital letters and no apostrophe in I'm, I'd throw it straight into the trashcan, regardless of content. And so would most companies that aren't absolutely desperate for people. This is one of those places where attention to detail matters.
(It also gives you less authority and respect from others if you email like this. It's a surefire way to get people to not like you for seemingly no reason. Really, a lot of people care about text presentation.)
(However, I do concede that Slashdot is one place where it really doesn't matter.)
There are two reasons someone chooses a particular major most of the time:
1) They think they'll make a lot of money doing it.
2) They think they'd enjoy doing that the rest of their lives.
Seems like you're worried too much about group 1. Don't. Ignore them. You're better off if they major in business or Chemical Engineering or Sports Medicine or whatever else strikes their fancy. They're not really interested in the field. There are worse motivations, and many people are successful who are mostly looking for a payday, but that's not who you should focus your attention on.
For the second group, that are already interested, you need to convince them that they'll be able to make a living at it, and that this is more interesting to them than another field. I can't offer super specific advice, since I don't find IT interesting in the least (I'm a perl programmer) - but you probably want to give as much real world examples of what kinds of jobs people actually get in IT and problems they actually solve. The people who are drawn in, those are the ones you want to keep.
And really, above all else, treat the students with respect. This will be so strange and rare, you'll instantly be a step up on how most people seem to approach them.
There's almost never many good launch titles in these genres, particularly RPGs. It takes a lot longer to write an RPG than to port and upgrade the Madden code to a new platform.
Remember when the PS2 came out, and Summoner was the only RPG for months?
The original Playstation had just a few in the first six months, and it wasn't until Suikoden that a really good one came out. People used to complain that the PS just had action games and racing on it too.
Companies are a little more cognizant these days that launch titles get a lot of press, so they try to get some good developers together and hope that something like HALO happens amongst the Madden and Ridge Racer and other typical launch titles. But if you're a fan of more complicated games, generally, don't worry about launches.
It's better to wait six months and let other people get the first production line models, have them work out any bugs, and pick up your system without going through insane lengths to acquire one, when there's actually games you want to play. And you have a better idea what the competition is anyway. (This time, the PS3 and Nintendo Revolution.)
Of course, any time a slashdot article talks about a programming language, there's a concerted effort by the language's detractors to say things like, "Does any one still use Perl?" "C++, isn't that a dead language with C# and Java taking its place?" "Java's just marketing hype, and C# doubly so, nothing beats C." and so on forever.
But of course we do this. As programmers, winning the language evangelism wars is one of the few things that really matters. And by matters, I mean it affects how much money I make.
I'm a good Perl programmer. I'm a novice at several other languages. I could pick them up, but it'll take years before I'm as proficient in anything else as I am in Perl. The same is true for most programmers after they pass the five year mark or so.
So, if the VP of an up and coming company chooses Java, I'm very unlikely to work there. If they choose Perl, I might. And it increases demand for Perl programmers. It's nothing but good for me if there's more options available when the day comes for me to change employers. And so, I have a vested interest in people believing Perl is faster to develop in and easier to maintain than Java or C#.
And so, don't believe me. And don't believe anyone else either who is detracting. It's in their interest to see people start projects in their language of choice. There's very little impartiality here.
Instead, ask yourself: does this language do the job? Is the development time acceptable? Is the performance acceptable?
I think Perl is very hard to beat on development time, and very few people need the performance of C or assembly - but I've just told you that I have invested a lot of time in becoming an experienced Perl programmer, so I want you to believe Perl is the tool to use. I don't think I've attached myself to a bad language, and I think it'll really win a fair fight quite often, but the court of public opinion (especially Slashdot Comments) is just such a terrible place to form technical opinions.
Because no other online comic creators decided to host a convention that got 7000 attendees? Really, it doesn't take a lot to figure out why they're getting the press this week.
It was an outstanding event - far better run than any Anime Expo I've been to, and a lot more involved than any regular sci-fi con. There was a _lot_ going on - at least one tournament in console, PC, and tabletop each at any given time, concerts, an exhibition hall, freeplay and bring-your-own computer rooms, panels, and far too many people in far too small a space, and they managed to make it work.
Plus, the gender ratio was a lot better than expected. Girl Gamer Geeks aren't as rare as the typical slashdot poster jokes about.
Realizing this is responding to a troll (or at least a troll tone), there's a reason I'd be willing to pay $7.50 for a week of a late-beta.
I'm really on the fence about buying this game. I like MMORPGs, but I'm really happy with City of Heroes right now, so I'm not sure if it's worth my time.
Only way to really know is to play.
So, if I don't like it, I save the $45 it takes to buy the game and play for the first month. Sounds like good math to me, IF you're likely to buy the game but not sure if you'll stick with it.
I've actually found it to be the opposite effect, with MMORPGs. While collectible games are a definite money sink (which, like many, I've successfully sworn off of by now), MMORPGs are much more of a time sink.
It costs me between $10 and $15/month for a typical MMORPG. As someone with a Real Job, this isn't terribly much. And, if you're playing one seriously, you're putting 20-40 hours/week into it.
When you're doing that, I find that you spend a lot less time playing other games. And noticing that, at least for me, I stop buying other games entirely.
I have tons of jewel cases for games I've played for less than 10 hours. They looked fun, and some of them were, but I never got around to really getting involved in them. Maybe this is a personal flaw, but I don't think it's that rare.
When I'm in MMORPG time-sink mode, I don't get the itch for a new game, knowing my video game time is spoken for, and I don't buy them. So, instead of buying a new $50 game each month (not unusual), I'm spending $15 or less each month to play the game I've already got.
The same logic is why Netflix saves me (the actual me, not the hypothetical reader) real money - for some reason, I used to buy a lot of DVDs of things I liked, knowing I'm unlikely to watch them more than once or twice again ever. Now, I just drop them in my rental queue, and know I can re-rent them anytime I feel the urge to watch, say, Adventures in Babysitting again. It's a nice little movie, but doesn't need to be taking up my shelf-space.
Maybe this is more about breaking worse habits with better ones, but I find the process fascinating.
One, I think you're right, that the people who use gay slurs as insults are often not doing so in a homophobic manner. (I'd rather there was another term, since it's more akin to racism and anti-semitism than a phobia, but I'm not going to succeed in language shift in one Slashdot post.)
But, here's a direct, real world analogy. A few years back, a cousin of mine was playing some version of Madden, and finding it the case that whenever he scored, the AI would immediately make a huge play and re-tie it. In frustration, he exclaimed, "This game is so Jewish!"
Now, I don't think he's particularly anti-semetic. I doubt he knows any Jewish people - there aren't a lot in rural southern Oregon. He's using it to mean a combination of cheap, and cheating.
I don't see how you can't equate the offensiveness level of this to the offensiveness of using 'gay' or 'fag' in a derogatory manner.
Ultimately, say what you want to say, but it's your own damn fault if people conclude that you're a racist, a homophobe, an anti-semitist, or just an asshole based on what you say. There are plenty of offensive taunts a clever person can come up with, without bashing decent, innocent folk, and if someone can't be bothered to do that, that's someone that quickly goes on my ignore lists.
But if you want people to conclude that you're an asswipe, please, keep using 'gay' to mean 'bad'.
>I suppose it has to do with the old debate of losely or strict typed langauges. Perl is highly modular but I would hate to work in a team of 10 or more perl developers all writing in their own styles and methods. Shudder.
You know, having actually worked in teams of 10 or more perl programmers at two different companies - it's really not any more difficult than at C-shops or Python or whatever.
Really, most of the style debates I've had have been about indentation and whether to put function { characters on their own line or after the sub foo. And this is hardly a perl issue.
One good idea is that, when you hire new people, do a code review after their first major code is ready, and pay attention to style issues. And again, this is a good idea anywhere. (Regular code reviews are also a good idea anywhere, but good luck!)
I've seen a very few people who write code that nobody else can follow. Maybe 5% of professional perl coders? And these people are, indeed, a problem. But isn't this always going to be the case? Aren't there C-coders who write mysterious stuff that somehow works? Of course.
The idea that perl is hard to maintain, or that it's hard to run an enterprise-level software division with perl, is pure Myth. In practice, I've not once, in 6 years of professional perl work, seen the flexibility and more-than-one-way-to-do-it mentality cause an actual problem.
Slashdot Mirror
Well, any time you're storing data in a central place, you have a greater consequence of failure. That's a downside of "cloud computing", or any web application that stores data in a database too.
The alternative approach is everyone to have a local version of their data, which will be lost by individuals all the time but not by everyone all at once.
Obviously, if you have a server that's a single point of failure for your company, and you botch a maintenance, something went very wrong. And not having a backup - it seems strange for a company that's been around the block a few times and has big resources behind it. You have to write this off as more of a specific failure and not a failure of the concept of storing data on a remote server.
I do have a good friend that works for Danger - I really don't envy the week he must be having.
Good! Cursive is a skill for writing fast, not for writing legibly. I haven't used it since leaving school.
Print is easier to read in the circumstances where you can't use a computer, and those situations are rapidly decreasing. The vast majority of interaction and professional work is typed these days.
This is the counterpoint to the recent article asking if typing should be taught in schools - yes, in elementary, in the slot that cursive used to live in.
Well, a good interview test isn't about trivia or things you could find in 30 seconds of google. It's things like: What does this code sample print to the screen? Write a regular expression to capture the phone numbers from a file with the following sample data. Write a SQL statement to select all the people from these two tables who have an outstanding balance (ie, can you do a join). That sort of thing.
Well, I mean, it's hard to really compare the before and after, because you don't follow the people you don't hire. It's all going to be anecdotal. That doesn't equate to blind, though.
But anecdotally, we expanded at WhitePages.com from about 8 programmers before we implemented the test, to a team of about 20, in the space of about a year. The quality of hires after that point was, IMO, very high, and more consistently good than before. (Only one was an abject failure, and that was for personal reasons that had little to do with his capabilities.)
And it's a mistake to distinguish between 'taking tests' and 'actually writing code' - what do you think is on these tests? (Hint, it's writing code.) Multiple choice is okay (and my current job has one of those), but actually writing real code is substantially better.
I've worked several places that had some sort of practical skills test for programmers.
I consider them a strong success.
There's a surprising number of people that can talk a really good game, but fall apart when asked the most basic actual questions. And, conversely, people who aren't extroverts or for whatever reason aren't stars in the verbal part of the interview, but clearly know their stuff when given a written test. It's a really good way to fairly judge technical skills across candidates, and weed out the fakers before you have to fire them later.
And as an employee, I like working with smart, competent people. I know how much, from experience, a bad hire wastes my time and ruins morale, so I'm happy to work for places that put out effort one way or another to not enter into this trap.
Anyone who'd refuse on principal, I'd worry is either a) faking it, or b) too arrogant to work well with others. A good candidate is happy to prove that they're a good candidate, and won't have to work with idiots.
A test isn't the _only_ way to do this. Any sort of nice, concrete technical grilling will do. But for a programmer, it _must_ involve actually writing code of a non-trivial nature. You can't believe resumes - even if people aren't lying, a Senior Programmer at one shop may only be barely competent at another, and not even realize that the bar is set differently.
Of course, the quality of a test can vary just like the quality of an interview question, but the goal is good for the company _and_ the employees, and in my experience it works better than most techniques.
Now, if your shop isn't terribly compelling based on product, and you're desperate to not turn people away... well, you probably should be looking for places that feel like they need a test to screen out unqualified candidates, so you can stop hating your job, and not worry about fixing this particular problem. :)
You should clearly get them a ThinkGeek gift certificate. $20 gets most sysadmins a T-Shirt they really would like.
-- Kirby, ThinkGeek programmer
(Okay, see, I'm biased, but I'm _still_ right.)
You're not going to come out of school with the expertise to be a professional software engineer in any case, whether you focus on one language or many. It's a hard job, and 90% of what makes it hard are factors of time longer than a quarter/semester, and factors of dealing with non-Computer Scientists and people with demands other than your professor.
It's okay, we (the hiring industry) know this, and a lot of us are willing to put in the investment to do the appropriate apprenticeships. CS Degrees are one way to select people who are more likely to succeed, but it's a discipline that's only learned through doing for the most part, and best done with people who are more senior teaching you. (I self-taught a lot after my CS degree, but I advanced more in the first year I had a real mentor than I did in the previous 6 I was doing it mostly myself. But people do vary, and if you're the exception, great.)
I'd recommend the variety approach, because people _do_ vary. Some people love the rigid structure of a Python, the massive infrastructure available to Java, the exposure of the bare metal of C, the total control of Assembly, the flexibility and rapid development of Perl, or whatever suits you. At this stage: Try a lot! Find a language you have fun with, and code more in that. You'll be a lot happier with your job if you don't find the language you use every day to be high in however you define bullshit. And if you don't fall in love with a particular approach, you've got a lot more starting nodes for your resume and can do a broader job search.
Employers have hired college students before, and we know that what you learn in your CS classes with respect to being a professional programmer is _really_ not that much, and hire more for people who we think will learn quickly, not be a pain in the ass, and actually have some amount of work discipline. Whether someone took one or three C# classes is not very interesting. (Personal side projects using the language of choice, those are more interesting.)
Good luck!
I tend to think that the goal is not to learn specific instances of skills in college (ie, a particular language), but learn principles. It's very much worth any science student's time to know a programming language. It's a reasonable thing to learn programming well enough to pick up any language - but really, this is one path of many, and is probably best called 'minor in computer science'. Yes, Fortran is not exactly cutting edge, but it's a fine example of one kind of language.
If you wanted to learn the language most commonly used in science labs, sad to say as a programmer type, probably spend some time with Visual Basic.
As an ecosystem, the best thing is probably variety. It's good that some percentage of new graduates know Fortran, so it doesn't become burdensome to hire people to work at places with legacy codesets, but it's also good that it's possible to hire someone working in a language that might be more suited to what you're doing. Or to a different type of brain. Diversity is good in a larger sense - someone who might be a mediocre Java programmer might be a star Perl programmer, and vice versa. The more diversity gives more individuals a chance at finding a niche they excel in. I think this aspect is overlooked massively when people talk about 'the right tool for the job'.
If you're a scientist that likes programming, though, a minor in CS so you can pick up whatever language comes your way is an approach with a lot of practical potential. (Or a double major, but CS is hard and most Science programs are hard, so I'm not sure it's worth it - even the people that hire programmers that like degrees would not find fault with a Physics degree and a CS minor.)
The same way anyone else gets respect. Actually get to know your coworkers, make sure that they know you understand their concerns and needs (and it helps if it's true), be someone who isn't just the weird guy in the server room that nobody ever talks to.
Don't consider getting to know your coworkers to be 'politics'. That's an anti-pattern.
It's not a cure-all, but if at least some people start thinking of you as a human with a name, and actually trust you, it helps a lot.
And also, return the favor. They're not just users violating policies and expecting miracles - they're stressed out people with demanding jobs that need support. If you don't respect them, it's _blindingly obvious_ and they will respond in kind.
Not everyone's personality is suited to this approach, but a little bit of empathy goes a long ways.
I went to Oregon State, a mid-level engineering school. After graduating, I moved to California and worked with recent graduates from some top schools, like UC Berkeley and Harvey Mudd and Cal Tech. (Well, Mudders certainly think very highly of their school.)
Comparing curriculum (and this was mid-90s), there was very little difference. The better schools have more interesting senior projects, but the actual education a motivated student gets is extremely similar.
Right out of school employment opportunities are a little better at the more prestigious schools, because companies target them more. They send recruiters to Stanford more than a typical state college. However, once five years has passed, very few people care, and there's wide swaths of the programming world that doesn't even care if you have a degree.
The real advantage of the more prestigious schools is networking. I don't really talk to any of my Oregon State buddies anymore. But my friends who went to, say, CalTech, seem to stay very close to their college circles. They trust each other as smart and capable, and that's a huge plus for getting interesting jobs for quite some time. Sometimes tech departments get clusters from a particular school, and it's no coincidence. I didn't value this at 17, and I should have.
Relatedly, the other big difference is quality of the other students. I was decidedly a top student at Oregon State. I'd probably have been somewhere in the middle at CalTech. I think I learned about the same, being a motivated and smart student, but there definitely exist a percentage at the lesser schools that just skate by, and waste your time in classes asking stupid questions. On the other hand, the top schools can be highly stressful. A very personal decision, if you'd rather be the top dog in a low stress environment, or be in the middle of an awesome but highly competitive environment. This choice re-presents itself throughout your career.
Note that none of the above applies to graduate school, where you're working directly with professors and learning a less generic expertise. For that, where you go matters a great deal.
This may also not be accurate outside of the West Coast. I'd easily believe we place less of a premium on prestige and pedigree than the rest of the country.
If you want to go to the liberal arts school, there won't be any problems for you, but I'd recommend the tech school because you'll make better, more useful friends. You're more likely to end up at an interesting startup with other super smart folks, more likely to make a big splash. But anyone can do these things - it just takes a little more luck and hard work post college.
Yeah, I hear some people are using this new Linux thing, but Windows 3.1 works just fine!
Seriously, there's a substantial gap between features between the two devices, including:
* Ability to record high definition on the TiVo (VCRs are very poor quality, which is easily noticeable, especially on modern televisions). Ability to record good quality of non-high def shows as well. The new boxes even record 5.1 sound.
* Ease of repeated recording of favorite shows
* Ability for device to know the difference between first run and rerun
* Ease of delete without subsequent quality loss
* Not taking up valuable space with stacks of videotapes
* Ability to auto-record based on keywords (Particularly nice for sports fans), directors, actors, and such.
* Auto-fill of space with shows you like. Seems small, but I _always_ have two or three Simpsons and Buffys sitting around, so I don't end up watching Home Improvement on a slow Sunday when I want to veg.
* Ability to record two things at once.
* Ability to watch something recorded while recording up to two live shows.
* Ability to pause, rewind, and fast forward 'live' tv. Very nice if the phone rings, or if nature calls!
* Ability to auto correct for schedule changes. No more losing track of a show when Fox moves it to Saturdays, or miss the last 10 minutes of Lost because it's a 70 minute episode! This is not a small feature. Tivo has an excellent track record at being on top of this kind of thing.
Now, there are downsides, mostly in the cost department, but if you consider television to be a hobby, I highly recommend tivo. (If you think TV is a waste of time, and are reading this thread, well, is trolling really a better use of time than tv? Honestly.) Other DVRs provide most of these features, and are better than a VCR, but Tivo still has the best featureset. Hopefully, they'll work out these cutting-edge-technology stumbles in a way that's good for current consumers. (But I've had the original HD box for almost a year and never had any problems.)
A career is going to take up the bulk of your time for the bulk of your life. You damn well better like what you do. If you do, if you really enjoy thinking about CS problems, then do it. You'll have energy and passion, which usually mix with experience to form competence, and that leads to money.
Everyone told me not to go into CS, that it was dead, when I graduated from High School in 1992. When I got my CS Degree in 1996, everyone was scrambling to get into this dot-com thing. Then, four years later, everyone was getting out again. Don't make career decisions based on fashions and trends like this.
If what you enjoy is actually just making money, and that's a perfectly fine thing to enjoy (if not really geeky), go into business. Minor in CS, and then become a project manager with an aspiration of management. Lots of room for business people, particularly ones who actually can understand the technology, and they get paid well too.
If you just want to be lazy, and do the minimal work to get the maximal money - forget about it. You'll be mediocre at whatever you do. If you're lucky, you can get a soul-crushing job, blend into the background, and collect a paycheck. Soul-crushing CS work pays better than average, but damn, you've made a serious mistake if you're going this route.
I'll reiterate the formula, even though it's obvious: Passion leads to Competence leads to Money. It's very hard to be competent at something you don't care about, and the odds of making money if you're not competent go way down. Some passions are harder to find regular work in than others, but if that's what you want, that's what you'll be best at, so go for it. There's almost nothing as awful as being bad at your job.
This is part of the reason why I weight college degrees so lightly when I interview people. It just doesn't mean much, when half the students only know how to google for answers. While that is a useful job skill (I google problems every week, if not every day), an employee that just does that, and isn't thinking independantly or really understanding the problems is a big problem.
Good companies to work for will generally treat this kind of attitude with a 'fired with cause'. There are a lot of bad companies out there to be an Initech slacker at, collect a paycheck, and do as little thinking as possible. I have no idea why anyone would want to end up there. So, it's kind of a self-correcting problem in that sense.
For those actually working for a college degree, it's more annoying. I have a CS degree, and I never cheated in college. (Really. Risking explusion is so not worth it.) Yes, it was obvious that some jerks were, and it leads to more experienced people like my present self finding very little corrolation between the degree and good hires, so it does devalue the diploma. But if you actually can contribute individual insights, are smart, and can get things done, you'll rise above these shortcutters very quickly. They'll work in the trenches at a job they hate, while you decide between Google or a hot startup for a career path. You'll win, in the end, 9 times out of 10. So don't worry about that other guy.
Winners don't do drugs!
I don't really buy into the idea that languages are good for beginners or are expert only.
A programming language is good if it is easy for you to express powerful ideas in. Any language will cause you to become comfortable with it to the exclusion of others for most people; therefore, you're far better off sucking up the learning curve of a language you want to keep using, than learning Logo and Pascal and throwing them away. If a language forces you to use conceptual language that you can't get your head around, that is not the right language for you.
It's also a good idea to pick a language that's actually used if you want to have a career in it, or others will support your code later. If you don't know what language to learn, the cutting edge is probably not the place to start.
I recommend: perl, python, C, lisp. Maybe C# or Java, but my personal bias says that if you want to go that route, python is a better language. They're reasonable languages, though. If you know you have a particular need to write utility scripts for windows applications, particularly MS Office, you probably should consider VBScript, but once you've used something else, you'll never be able to go back.
If your goal is not to have a programming toolkit in your back pocket, but instead to understand programming languages, I'd recommend basic understanding of: Assembly (to really know what's going on behind the scenes), Lisp (to really see what a powerful abstract language can do), C (to have a low level control in a high level language), and perl (to have a useful blend of high level abstractions of things you don't want to worry about (memory allocation, strings) and still have a more natural syntax than pure lisp.) Once you can write a non trivial program in all four of those languages, you'll have a good understanding of what you value and don't in a language, and can make informed decisions.
(I've done all of those, and a few others, and found I like perl the best. Different problems and different people are suited towards different solutions.)
(However, with this many parenthesis in a post, you'd be right if you concluded that I also think lisp is nifty.)
That's super convenient. Now I only have one hobby!
I know this is probably a joke, but if I came across a cover letter or resume that had no capital letters and no apostrophe in I'm, I'd throw it straight into the trashcan, regardless of content. And so would most companies that aren't absolutely desperate for people. This is one of those places where attention to detail matters.
(It also gives you less authority and respect from others if you email like this. It's a surefire way to get people to not like you for seemingly no reason. Really, a lot of people care about text presentation.)
(However, I do concede that Slashdot is one place where it really doesn't matter.)
There are two reasons someone chooses a particular major most of the time:
1) They think they'll make a lot of money doing it.
2) They think they'd enjoy doing that the rest of their lives.
Seems like you're worried too much about group 1. Don't. Ignore them. You're better off if they major in business or Chemical Engineering or Sports Medicine or whatever else strikes their fancy. They're not really interested in the field. There are worse motivations, and many people are successful who are mostly looking for a payday, but that's not who you should focus your attention on.
For the second group, that are already interested, you need to convince them that they'll be able to make a living at it, and that this is more interesting to them than another field. I can't offer super specific advice, since I don't find IT interesting in the least (I'm a perl programmer) - but you probably want to give as much real world examples of what kinds of jobs people actually get in IT and problems they actually solve. The people who are drawn in, those are the ones you want to keep.
And really, above all else, treat the students with respect. This will be so strange and rare, you'll instantly be a step up on how most people seem to approach them.
There's almost never many good launch titles in these genres, particularly RPGs. It takes a lot longer to write an RPG than to port and upgrade the Madden code to a new platform.
Remember when the PS2 came out, and Summoner was the only RPG for months?
The original Playstation had just a few in the first six months, and it wasn't until Suikoden that a really good one came out. People used to complain that the PS just had action games and racing on it too.
Companies are a little more cognizant these days that launch titles get a lot of press, so they try to get some good developers together and hope that something like HALO happens amongst the Madden and Ridge Racer and other typical launch titles. But if you're a fan of more complicated games, generally, don't worry about launches.
It's better to wait six months and let other people get the first production line models, have them work out any bugs, and pick up your system without going through insane lengths to acquire one, when there's actually games you want to play. And you have a better idea what the competition is anyway. (This time, the PS3 and Nintendo Revolution.)
Of course, any time a slashdot article talks about a programming language, there's a concerted effort by the language's detractors to say things like, "Does any one still use Perl?" "C++, isn't that a dead language with C# and Java taking its place?" "Java's just marketing hype, and C# doubly so, nothing beats C." and so on forever.
But of course we do this. As programmers, winning the language evangelism wars is one of the few things that really matters. And by matters, I mean it affects how much money I make.
I'm a good Perl programmer. I'm a novice at several other languages. I could pick them up, but it'll take years before I'm as proficient in anything else as I am in Perl. The same is true for most programmers after they pass the five year mark or so.
So, if the VP of an up and coming company chooses Java, I'm very unlikely to work there. If they choose Perl, I might. And it increases demand for Perl programmers. It's nothing but good for me if there's more options available when the day comes for me to change employers. And so, I have a vested interest in people believing Perl is faster to develop in and easier to maintain than Java or C#.
And so, don't believe me. And don't believe anyone else either who is detracting. It's in their interest to see people start projects in their language of choice. There's very little impartiality here.
Instead, ask yourself: does this language do the job? Is the development time acceptable? Is the performance acceptable?
I think Perl is very hard to beat on development time, and very few people need the performance of C or assembly - but I've just told you that I have invested a lot of time in becoming an experienced Perl programmer, so I want you to believe Perl is the tool to use. I don't think I've attached myself to a bad language, and I think it'll really win a fair fight quite often, but the court of public opinion (especially Slashdot Comments) is just such a terrible place to form technical opinions.
Because no other online comic creators decided to host a convention that got 7000 attendees? Really, it doesn't take a lot to figure out why they're getting the press this week.
It was an outstanding event - far better run than any Anime Expo I've been to, and a lot more involved than any regular sci-fi con. There was a _lot_ going on - at least one tournament in console, PC, and tabletop each at any given time, concerts, an exhibition hall, freeplay and bring-your-own computer rooms, panels, and far too many people in far too small a space, and they managed to make it work.
Plus, the gender ratio was a lot better than expected. Girl Gamer Geeks aren't as rare as the typical slashdot poster jokes about.
Remember the saying, "When all you have is a ceremonial hammer, everything looks like an obsolete nail."
*SMASH*
Realizing this is responding to a troll (or at least a troll tone), there's a reason I'd be willing to pay $7.50 for a week of a late-beta.
I'm really on the fence about buying this game. I like MMORPGs, but I'm really happy with City of Heroes right now, so I'm not sure if it's worth my time.
Only way to really know is to play.
So, if I don't like it, I save the $45 it takes to buy the game and play for the first month. Sounds like good math to me, IF you're likely to buy the game but not sure if you'll stick with it.
I've actually found it to be the opposite effect, with MMORPGs. While collectible games are a definite money sink (which, like many, I've successfully sworn off of by now), MMORPGs are much more of a time sink.
It costs me between $10 and $15/month for a typical MMORPG. As someone with a Real Job, this isn't terribly much. And, if you're playing one seriously, you're putting 20-40 hours/week into it.
When you're doing that, I find that you spend a lot less time playing other games. And noticing that, at least for me, I stop buying other games entirely.
I have tons of jewel cases for games I've played for less than 10 hours. They looked fun, and some of them were, but I never got around to really getting involved in them. Maybe this is a personal flaw, but I don't think it's that rare.
When I'm in MMORPG time-sink mode, I don't get the itch for a new game, knowing my video game time is spoken for, and I don't buy them. So, instead of buying a new $50 game each month (not unusual), I'm spending $15 or less each month to play the game I've already got.
The same logic is why Netflix saves me (the actual me, not the hypothetical reader) real money - for some reason, I used to buy a lot of DVDs of things I liked, knowing I'm unlikely to watch them more than once or twice again ever. Now, I just drop them in my rental queue, and know I can re-rent them anytime I feel the urge to watch, say, Adventures in Babysitting again. It's a nice little movie, but doesn't need to be taking up my shelf-space.
Maybe this is more about breaking worse habits with better ones, but I find the process fascinating.
One, I think you're right, that the people who use gay slurs as insults are often not doing so in a homophobic manner. (I'd rather there was another term, since it's more akin to racism and anti-semitism than a phobia, but I'm not going to succeed in language shift in one Slashdot post.)
But, here's a direct, real world analogy. A few years back, a cousin of mine was playing some version of Madden, and finding it the case that whenever he scored, the AI would immediately make a huge play and re-tie it. In frustration, he exclaimed, "This game is so Jewish!"
Now, I don't think he's particularly anti-semetic. I doubt he knows any Jewish people - there aren't a lot in rural southern Oregon. He's using it to mean a combination of cheap, and cheating.
I don't see how you can't equate the offensiveness level of this to the offensiveness of using 'gay' or 'fag' in a derogatory manner.
Ultimately, say what you want to say, but it's your own damn fault if people conclude that you're a racist, a homophobe, an anti-semitist, or just an asshole based on what you say. There are plenty of offensive taunts a clever person can come up with, without bashing decent, innocent folk, and if someone can't be bothered to do that, that's someone that quickly goes on my ignore lists.
But if you want people to conclude that you're an asswipe, please, keep using 'gay' to mean 'bad'.
>I suppose it has to do with the old debate of losely or strict typed langauges. Perl is highly modular but I would hate to work in a team of 10 or more perl developers all writing in their own styles and methods. Shudder.
You know, having actually worked in teams of 10 or more perl programmers at two different companies - it's really not any more difficult than at C-shops or Python or whatever.
Really, most of the style debates I've had have been about indentation and whether to put function { characters on their own line or after the sub foo. And this is hardly a perl issue.
One good idea is that, when you hire new people, do a code review after their first major code is ready, and pay attention to style issues. And again, this is a good idea anywhere. (Regular code reviews are also a good idea anywhere, but good luck!)
I've seen a very few people who write code that nobody else can follow. Maybe 5% of professional perl coders? And these people are, indeed, a problem. But isn't this always going to be the case? Aren't there C-coders who write mysterious stuff that somehow works? Of course.
The idea that perl is hard to maintain, or that it's hard to run an enterprise-level software division with perl, is pure Myth. In practice, I've not once, in 6 years of professional perl work, seen the flexibility and more-than-one-way-to-do-it mentality cause an actual problem.
Not once.