Nice recovery.

There is more often than not a gap between the design and the actual implementation, though, that sets the "hackers" from the "engineers," to use the OP's idea of it.

I try to practice quality standards and easy to follow patterns or algorithms. KISS is the fall-back; if it's too hard to write the software, then the design isn't appropriate. Likewise, if the software is too hard to read or manage, then you didn't follow the design.

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.