Incidentally, point #2 is key. For some reason, even compsci grads like to think their algorithm analysis course(s) was(were) useless. But having watched an MIT EECS grad write a web application that was, as I recall, O(n^2), just because he didn't want to use a database, I can only say that the course is essential. Dr Susan Mengel, you were one tough cookie, but, boy, did you teach me that stuff well.

Being a developer is about more than code.

For example:
1. You'll follow and (perhaps later on) write and refine software specifications. You need to learn different ways to do this.

2. You'll need to select appropriate algorithms for the task at hand, and evaluate performance for new code -- which you wrote against a trivially small amount of data -- against production data volumes.

3. You'll need to understand pros and cons of different software development approaches, particularly waterfall and the broad category of "agile". Why would you pick one over the other?

4. You'll need, at least on occasion, to understand one or more software modeling systems, and perhaps to create models that represent what you're suggesting.

5. You may very well need advanced mathematics for your job. Just a couple of months ago, I had to write some vector-handling code, in PL/SQL of all things.

Sure...you could learn all this on your own. But a good compsci curriculum will provide you with at least an introduction to all of these, with some kind of attestation of basic familiarity.

If you want to be "just a coder," go right ahead. However, you'll never be all that competitive with those possessing the larger body of skills needed to be a solid technical professional. Of course, real experience is very helpful in landing the first job. That's what student jobs, interning, and cooperative education are for. I'd never have landed my first job without some of the skills I learned over four terms of co-op.

Knowing how to troubleshoot systems -- whether it's code, or things like cars and other physical machines or electrical wiring -- is key. Every programmer will spend time fixing his own code, and has a good chance of spending even more time fixing someone else's. Building the skill to understand complex systems quickly, and to apply fixes that are short of "re-write the whole thing", is essential.

I've been a developer for over 20 years. Maybe 20-25% of my total time is spent writing new functionality. About 35% is fixing bugs (mine and others'), with the remainder spent on process documentation, design, etc.

...Everyone says "I only need 10% of what this word processor will do." Everyone else will agree with that statement. The problem? The 10% I need is not the 10% YOU need.

I find the article strangely short-sighted. Sure, we have to avoid overengineering solutions that are not going to be needed in the near future. But to say "you should not code features that are not immediately needed in the current sprint" will lead, in most cases, to significant rework in the future. Rework is money and time.

A key part of the work of a smart project lead, whether that lead is an active developer or not, is to anticipate the product direction. The lead has to be able to say, "Sure, we're only going to write this subset of functionality *now*, but it is a near certainty that users will want this expansion of it in just a couple of years. We might as well have the basic framework for that in place, even it's only stubs."

Further, our tools are complex because our needs are complex, even at the SMB level. I've been a developer for 30 years now, writing everything from experimental personal-use stuff, to local utilities, to enterprise software that is used by some of the largest manufacturers on the planet. Even small users expect unanticipated cases to work. Big customers expect that, not only do unanticipated cases work, but that migrations to new versions will be tailored to THEIR needs and will happen without notable incident. As but one small example that means that internal testing of a new release not only has to work as a brand new install, but it must also work as an upgrade, and it must work as an upgrade against the specific data and specific customizations (real software is customizable), even when you don't know what those are. If you expect success in that environment, you're going to need a LOT of tools: source code management (to identify what changed when you introduce a regression), an automated testing framework, a way to test builds and build functionality, a framework for testing upgrades against real customer data (that they let you use for this purpose), and then tools and processes that let you track code reviews, approvals, and the like. That's a lot of tools, and a lot of staff to follow it all around.

My organization has some excellent tools, and developers assigned solely to maintain them for the rest of the development staff. It means, though, that any new developer coming in is going to have to learn a lot more than a programming language.

Seriously. Don't do it.

I had a smallish consulting client from 6-7 years ago that ran their Oracle server on a system that had no firewall protection, because it made it easier for the application server to get to it. It also simplified remote access by a contract developer. As the remote DBA, it was also easier for me, although I advised against it from the beginning.

Sure enough, an intrusion happened (whether my script kiddies or someone more serious I don't remember). The intruders left behind a lobotomized database and who knows how much rootkit. The latter was the bigger issue, as a big part of my job was to ensure that reliable database backups were being taken. I knew I could recover with what I had, but the admins had to know the system was uncompromised.

So...a good day or two of downtime resulted as a new system was built and deployed. (It wasn't a mission critical system, which is why contract offsite DBAs and developers were used.) I restored the database, AND a firewall was put in place to limit all but the most sophisticated of intruders. I also configured CMAN (Communication Manager) to restrict database access itself to known systems only, even though the database wasn't the intrusion vector.

If the system is valuable, or could serve as a gateway to the rest of an internal network, it must have a firewall. MUST have a firewall.

The OCR in Adobe Acrobat (Standard and Professional) is excellent. If the input copy is of usable quality, the OCR results are superb. I've scanned and OCR'd an entire file cabinet's worth of journal articles from a departed professor's library using a six or seven year old ScanSnap scanner on the "Better" setting. Both Spotlight and Windows Search get correct hits in the documents, and cutting/pasting works like a champ.

Maybe you're using something inferior?

Sorry. Forgot the link: The Terminator movie ending

I can't wait until Skynet becomes self-aware.

I'll emphasize my previous post by noting that weight is a BIG factor. These minivans are large and heavy. As I recall from a couple of years ago, even the Mazda 5 (which is sort of a mini-minivan) was only getting low- to mid-20 mpg on its four cylinder engine. For that kind of fuel economy, you might as well get the power output of the six.

I'd like to see 30+ mpg in a minivan myself.

My 2001 Odyssey had a 210 hp engine. My 2011 Town and Country has a 283 hp engine and gets slightly better fuel economy. The vehicle weight is about the same (i.e., HEAVY, at 4,000 pounds or so). The problem is that the manufacturers are caught up in the minivan horsepower wars. The current Chrysler delivers 283 hp, the Sienna about 270, and likewise the Honda. Add the weight of the big box, and it's a tough one. I suspect a reduction in engine power back to 210-220 hp would get us to 30 mpg, but such a model would suffer sales losses to the more powerful units.

I have to disagree concerning the other points. My minivans have all handled extremely well, with much better footing (being lower to the ground) than any truck I've driven. Leather interiors are available (my Chrysler has leather), although, long-term, cloth tends to last longer. (Leather is prone to drying and cracking from heat and UV exposure. The cloth can stain, although fabric protectant will mostly fix that, but the fabric in my well-used Odyssey looked very good when I retired the van.) Toyota offers AWD. That's a compelling feature, but I had concerns about reliability in the first iteration.

Minivan styling? Whatever. It's a box with a compact drivetrain to maximize interior room. You want swoopy style, it'll hurt the very thing you want the minivan for.

While there were 14 manufacturers of minivans 15-20 years ago, there are only five today: Chrysler/Dodge, Honda, Toyota, Kia (with a newly reintroduced Sedona), and Nissan. Still, that's five manufacturers all offering competitive products.

As a father of four minions, I've yet to find an SUV that equals the minivan in its ability to haul six or seven people AND THEIR GEAR in good comfort, all while achieving 25+ mpg. My 2011 Town and Country actually got 27.5 mpg on one tank of gas on a recent 2800 mile trip. My brother's SUV struggles to achieve 18.

Having rented several SUVs on trips, they can seat everybody, but squeezing in the bags is a real challenge.

I sure hope the minivan doesn't disappear. Truly, it is without equal for families up to about 7 people.

Kia killed theirs off for one year, but a brand new Sedona model has just been introduced.

We have buzzword BINGO in the first paragraph. Holy cow.

http://dilbert.com/strips/comic/1994-02-22/

I don't blame anybody. Use what you like. However, don't reject Windows Phone out of hand just because Microsoft makes it. If it doesn't suit you, pick something else for sure.

Platform choice is no religion. You're right there.

I'm glad there are alternatives across the board. There is, however, a knee-jerk anti-Microsoft reaction here on Slashdot that rejects Windows Phone (particularly) out of hand. It has its merits. Really, it does. I don't think Microsoft subsidized the Lumia 520.

LibreOffice is fine for the word processor and presentations package. The spreadsheet is missing key functionality (as confirmed by several Ph.D. graduate students). I don't know about the other stuff.

As for cloud based apps, I still doubt that any enterprise with confidential information is going to hand it over to an off-site cloud environment. Microsoft already offers their own cloud alternatives (Office 365 particularly), which make it easy to move between desktop Office and cloud Office.

I'm a Linux fan (particularly Mint Cinnamon), but I still don't see Microsoft going away on the desktop soon.