Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:Why? (Score 1) 130

It's more like an opportunity to create a storyline where Google fails and Baidu succeeds. Even the linked article offers it up: Baidu outcompetes Google, forcing them to close shop in China. Now they're going to succeed where Google has misstepped. Or something.

Comment I hope they keep working on Gridworks (Score 1) 63

One of the challenges with generating and using data sets is cleaning them up. Data entry errors, OCR failures, conflicts between multiple sources, etc. make it a pain to search and summarize data. Gridworks helps me hunt down bad records and normalize fields. If it keeps improving, people might start using it before publishing their crap data.

Comment Re:Why does this article scare me? (Score 1) 269

OEMs do. Canonical's business operations are largely opaque to the community. Sources of revenue I've discovered include: OEMs like Dell buying engineering support contracts for their Ubuntu laptop/netbook offerings, hardware manufacturers paying Ubuntu to port to their new platform, and OEMs like Toshiba paying Canonical to run certification testing.

For netbooks, faster boot and performance is a feature worth pursuing. At this point all I've seen is Scott mention they'll try it and test it before the point of no return that comes with time based releases.

Comment Re:Why not high school? (Score 1) 1138

In part it depends on the kinds of programming you want to apply for. There are three kinds of programs:

1. Simple programs that largely revolve around "business logic" and writing and reading from a database. The most complicated stuff is either modeling the whole damn business process or maybe generating some reports. This stuff CAN become complicated, but I treat that as a design flaw. You will have a hard time getting into this without HR buzzword compliance. I think they're doing you a favor. Lots of poor CS students and business/IT majors end up in this place.
2. Simple programs that have complicated results. Lots of EE work revolves around designing simple circuits or programs and demonstrating they satisfy certain engineering properties. Control loops and whatnot. The programs are simple but the consequences may involve differential equations or recurrence relations. The programs are generally a variation of a small set of algorithms, with parameters tuned for your design's requirements. This is where EEs turned programmers generally end up.
3. Complicated programs. Wicked applications of math, like Hidden Markov modelling, or optimizing compilers, language theory and software verification. Speed reading CS won't count here, as you need to deeply understand the principles of computers and programs before you'll be productive here. If you've written a Fast Fourrier Transform implementation in school, you might have a shot. Otherwise, top CS students and grad students only.

So my advice is to find firms that do place EEs into programmer roles. Embedded systems places mainly. I have many EE friends that landed in programming roles, even though they insisted they would fight the trend. Try to position yourself in your current EE employment to work alongside programmers, learn what they do and pick up a few tasks for them. Eventually your CV will have programming related material to pull from for a targeted resume. And you'll have the friends and contacts to pass your resume directly to hiring managers for consideration.

If you're after category 3 work, consider getting graduate degree (don't waste your time on another bachelors). Plenty of EEs go back for different degrees. Look for institutions with EE and CS in one department, and I personally recommend against financing it. Spend 10s of thousands of someone else's money earning an advanced degree. There's TA positions, research positions, scholarships and employer paid options. Be prepared to sacrifice some portion of your life; be it your family, your career or your sanity.

Comment Re:Problem (Score 1) 694

When I TA'd for an advanced undergraduate level OS design class, we used team based projects for instruction and the best weapon we had against freeloading was secret peer evaluation and interrogation about the code. There's a lot of good reasons to go for collaborative design projects. They're closer to real world assignments; when you run into a problem with three people coding, chances are one of them can figure out the typo or think-o. The best students use it as an opportunity to test out revision control systems in collaborative fashion.

I think a lot of students skip the course now because it's been made optional and famously hard. With some effort it could be salvaged into a quality Software Engineering practices course covering revision control, automated builds, testing, static analysis and the engineering implications of NP completeness in operations theory.

Slashdot Top Deals

Play Rogue, visit exotic locations, meet strange creatures and kill them.

Working...