Myself and a friend worked for Nick a few years back helping build out some of the HTML5 game concepts. We prototyped different games using various engines (PlayN, etc) and ended up along with some other contractors on Haxe-based Flambe as the best choice for HTML5. We actually launched a couple of games [1][2], though a lot of our work ended up internal-only.
When we started, the iPad 1 was still considered a current browser. The performance on that device was abysmal. When the iPad 2 and newer versions of iOS came around, we finally had access to accelerated <canvas> and could really start making things work.
The other things we prototyped for Nick were in-game video and multiplayer gaming. The in-game video was pretty bad for cross-browser support. In the end, Flambe gave us a tool (Flump) that had the ability to import from Flash animations that was significantly better than trying to force iPads and Android devices to play video reliably and consistently.
Multiplayer support was the least painful new ground we worked on -- using engine.io and Redis on the backend we were able to scale to tens of thousands of simultaneous users without spending too much on EC2. For the most part it "just worked".
If there's one lesson I learned from this experience, it's that developing games for existing properties is tough work. There are so many stakeholders that things take forever to get done. Considering the value of the properties, this isn't surprising.
The second lesson would be that HTML5 is moving so fast that you'll probably have to rebuild your games every few months to support all of the changes that are happening in the space. Most of the games we launched a little more than a year ago are already starting to bitrot.
[0] https://github.com/aduros/flambe
[1] http://www.nick.com/games/spongebob-squarepants-spongebob-sq...
[2] http://www.nick.com/games/data/korra/korra-pai-sho/
[3] http://www.nick.com/games/kca-2013-multiplayer-trivia.html (no longer there -- probably our most polished release)
The goal isn't to make everyone want to become a programmer as a career, but for more careers to better integrate modern technology.
Hence the confusion about why we're encouraging interest in programming rather than an overall interest in STEM fields.
The number of programmers we need is not relevant here: they may not need to know how to write complex programs, but knowing the basic principles of programming will make them more able in a worlds relying heavily on computers. This is already the reason why we teach basic math, physics, biology, history, geography, English, etc. to kids.
Not sure if there's a direction connection to the Nick.co.uk efforts, but definitely interesting.
[1] http://techcrunch.com/2014/02/05/media-queen-gerry-laybourne... [2] http://techcrunch.com/2014/03/18/kandu-is-an-ipad-app-that-t...
What is the goal? I could see kids clicking on stuff for a few minutes, lose interest and close it.
Even in other STEM fields, programming is very helpful. It's very common for physicists to write programs to analyze their own data. Physics as a field is ahead of the curve here, but economics, chemistry, and all the engineering fields are catching up.
Programming is the applied knowledge of technology. Everything else is just learning - and being restricted to - someone else's idea of how you're supposed to operate that technology.
All of engineering that isn't programming disagrees with you, for starters.
Programming is one kind of application of knowledge of one specific area of technology. But so are lots of other things.
So programmers aren't restricted to Computer Engineer's ideas of how to operate technology?