Word up. I use "Software Smithy" as many projects are trying to bang two moving projects together as it is about any kind of design or engineering. And, yeah, I got the CS thing going, but as the OP points out, the academic is nothing like the actual.

I'll cut slack for the "opinion" bit, but having a degree doesn't mean anything becomes instinct.

Or more likely that Slashdotters don't read TFA. The 13 is a reference to the number of games researched, not their age. Pac-Man is noted as a game from 1980. Neither the introduction article (first link) or the research paper itself (led to by second link) suggest Pac-Man is only 13 years old.

What does this really mean? You're old again.

I agree also on the WYSIWYG editing, but was commenting in context of OP. In general I do my editing in text editor and view results in a browser. Usually as many browsers as I can access (evil IE, FF, Chrome, and Safari usually suffice). Unless layout is of no concern (and that rarely happens) the browsers seem to have some quirk that messes up somethg.

Agreed, but I think it fails as a WYSIWYG HTML editor...and, probably for the purposes of the post, it equals vi...

Post before yours (in my stream anyway) was for VIM. I think that counts.

And that can lead to some pretty bad programming habits. There are exceptions, and I'll give you the benefit of the doubt that you're one of them.

You might not need to know the details of an internal combustion engine to make a hobby around driving a car, but you do need to understand the complexities of lift and drag and such to fly an airplane. Software's at least as technical as flight, even in many pretty simple games.

If one knows nothing of data structures, control statements, and even error handling, then one is likely to write inefficient, unresponsive, and even faulty software.

Certainly it isn't as much fun learning the technical details right away, but writing software is a technical undertaking. If one is going to skip the technical bits, then one's going to end up doing it wrong. It might become easy with practice, but it's pretty heady, technical stuff, and some people won't get it and will be driven away from it.

That said, these kids don't need to start out understanding heuristic pointer manipulation in C/C++ or inline assembly. However, they should properly learn some basics like for() and if() and how to create and handle structures or classes, like what it means to pass those as parameters. Even a simple game of rock-paper-scissors requires conditionals and input handling. If you want to make a "simple" Pacman or Asteroids or Tetris clone will require knowing where many things are on the playing field, many of which are moving, most of which will interact with each other and game controls. That's a lot of "make it up as you go" that has opportunity to learn some good data handling and coding practices along the way.

Given that Blender is in the list, the easy assumption is OP has some idea of writing a 3D game, and that's going to require some rather technical understanding, whether just for the modeling, or if including kinetic skeletal animation. Even if a library does the hard bits, some understanding of matrix-based multi-dimensional math will be required; how's that for needing some basics for ya? Blender makes that kind of easy with its game engine requiring scripting in Python.

Calculator shows that $27.63 is $57,4740 for 52 40-hour weeks (a "typical" 2080-hour year). It should be the case that a typical "two week" vacation is covered in that, but if you use 50 40-hour weeks, it comes out to a rounder number, $55,260. If one was just unaware of how weeks work in a year (and even 52 40-hour weeks doesn't round right), using 4 40-hour weeks in each of the 12 months is $53,049.6.

I'm an IT worker who doesn't get overtime. I work hourly, and am paid for every hour I work, but it's the same rate no matter how many in a day or week or pay period.

Much of my time is spent cleaning the Java code of those that don't understand why it even works. The "help" it gives in managing memory and pointers and the other bits it hides, and the forgiving nature of the targets of much of the output (web apps, mostly) make it an easy language to work in. Given the ease of the language and the helpfulness of the tools, the level of skill required is pretty low, which means a lot of not-as-savvy-as-should-be people work as Java developers (and PHP and VB and others).

My current project still has 1500 warnings in the code, which is 10% of what it had when I started working on it, which was a third of what the previous project started with. There were actually a few dozen errors in the JSP that went into the web-app (missing included files)! Many of the warnings are signs of sloppy habits (e.g., unused variables), but others are signs of not knowing how things work or having poor grasp of logic (objects may not have been assigned before being used)--the former are just annoying but the latter can cause problems. The point is, if you leave the warnings in place, the ones that mean something get buried in the mass of those that don't--clean them up and don't have any, and your software will be better for it.

It took a lot more to become a COBOL developer. The language is strict enough to encourage strict habits. Java doesn't have such a high bar, and because of it, a lot of "low hanging fruit" tend to get picked to work on the software.

I think you forgot to wrap your text in <sarcasm/> tags. Otherwise, your recollection of history is a little off.

Done right, outsourcing can save money overall. Done wrong, it's a headache for everyone, and an arguable pouring of money into a bunch of wasted spin.

Ultimately, for any project, it comes down to planning and management as well as execution. You can hire a room full of $100/hour US programmers who also will not get anything done if they aren't given any direction. Similarly, if the skills of the team don't match the work to be done, it's wasteful for a whole different reason.

Just because a developer in India (or Manila or Singapore or in Russia or whatever) is getting paid a fraction (third, quarter, fifth, tenth, or less) of what a similar developer in the US or Europe might make doesn't mean it's a low-cut rate in that country, nor does it mean that it hires less capable talent. Even in the US there's a spread of relative wages because relative cost of living changes.

Others have pointed out that the example $14/hour is a lot in some places. In those places, you're potentially getting the topper talent. It's up to the reader, manager, or whatever to judge whether the talent is comparable; whether comparing Saint Paul to San Jose, or Milwaukee to Mumbai. And that judgement should probably weigh in some of the time zone, cultural, and other geographic-based differences, as well as the experience of the individuals and groups involved. No matter where one looks, one should hire the right skills for the task.

I worked with one outsourcing group that had an interesting approach. Rather than stick people to a task for which they may or may not have the appropriate skill, a team is assigned and when a task comes up, someone capable would be selected from the crowd of waiting talent. The billing was only for the people working, not for the people waiting, so it was a bit of a win-win. If your plan and workflow are such that a bevy of developers can just pick a task to finish, instead of arbitrarily assigning tasks because tasks need doing and developers are waiting, then it doesn't matter where the developers are sitting. I've worked successfully with "in" and "out" sourced groups in this fashion; a developer will look at the tasks that need doing and pick something they can do well. (Yes, of course, some of the "low hanging fruit" constantly picked the "easy" tasks, or just didn't do well, but that had a benefit of removing the "easy" tasks from the list so the "better" devs could focus on the "harder" tasks.)

I work on Windows XP, Windows 7, Mac, Solaris, CENTOS, Ubuntu (older and newer), and more. They're all a little different, but really when you get into your tools (in this case Eclipse), it's more about the shifts in keyboard than anything GUI. The fonts and icons and toolbars and window frames and so on all change a little between the platforms.

Other than the not-yet-made-or-released UI/theme editor for Unity, making it so tweaking the themes is hard, there's not much worse in Unity than in the other UIs. There are forum posts to help find the CSS and other files to change (Google for "unity orange css" and you'll find them) what you really can't stand (color/size-wise, anyway).

Beyond that, it's taskbar or dock, menu in window or desktop, and eye-candy things like snapping windows to an edge.

Download and unpack a fresh Eclipse Indigo release. After starting, go to the help menu, pick the Market place. Search for Subversive (by Polarion), ignore the "cannot find" warning, and install that. Restart Eclipse. It will prompt you for an SVN connector--choose one of the SVN Kit connectors as it's a pure-Java and doesn't rely on external SVN to be installed. After installing, restart Eclipse again. Open the perspective SVN Repository Exploring or Team Sharing (and then SVN Repositories view). Add your sever. Check-out your project. Start working.

As I sit here working on a Java web app written almost 10 years ago, updated continuously since, but still with threads of old libraries and methodologies within, I think the half-life is a little bit of a weak comparison to make.

TFA is all about staying on top of your unnamed vendor's magic moving technology. It isn't about technology skills in general. Heck, it isn't mentioning anything specific either. Well, there is that one line about staying up with PL/SQL.