I foolishly promised Amandine on Twitter that I would write about my experiences going from hard-core C++ game tech to web tech. And so, before this ends up on the pile of Things I Could Write About, let me take a stab at actually doing so.
Anyway, very quickly and in no particular order, here are some of the things I found remarkable in going from C++ to web technology:
Lots of tiny parts
The most important thing in web tech is your stack: the combination of technologies you use to handle user (meaning browser) requests in the front end (meaning in the browser or perhaps in a mobile app's UI) and the back end (on the server).
The original stack is LAMP: Linux, Apache, MySQL, and PHP. But while solid it's also a bit... old-fashioned. (Gameconfs uses Linux, whatever Heroku uses as a web server, PostgreSQL, and Python.)
Front end and back end
Front end developers often work with "designers", meaning graphic and UX designers. Web designers often use Photoshop. Some front end developers do web design as well (like me, although I'm mediocre at it).
This is why social game companies, which grew out of web companies, often have front end and back end programmers in their teams, and their game designers are often expected to do 2D graphics.
Stateless protocols are weird
HTTP is probably the most important protocol to understand in the web world. It's fairly easy to work with but the big mindfuck coming from games is that it's stateless, meaning that the protocol requires no state to kept between requests on either the client or the server side. Every HTTP request arrives in a fresh new world of possibilities. This has advantages: HTTP is simple, you can easily send HTTP requests to a different machine from last time (great for scaling), etc. But when I first tried to "quickly" store something in a global variable only to find out it didn't work, it hit me that I was going to spend a lot of time managing state myself. And so you get to cookies, sessions, and databases.
Databases are useful - who knew?
Your technical career may not be like mine, but I had sort of vaguely heard of relational databases yet never needed to use one or knew people who did (in PC and console games, in the 90s). Well, it turns out they're useful and even cool, especially PostgreSQL, which is kind of a beast.
I'd say start with an ORM (an Object-Relational Mapping, meaning a layer between the database and your programming language). But know that there are good reasons for eventually digging deeper and getting into SQL and really using the power of your database.
And of course the kids these days like to use so-called NoSQL databases, like MongoDB, Redis, etc. My opinion on these is that they are cool, but I have not yet had a problem that *really* required a NoSQL database, especially since PostgreSQL can handle key/value and JSON data. So I prefer using a tool I know and that has been around for a long time. But, as I will explain below, that is not the typical web tech way.
Lots of Linux and OS X
For historical reasons, web development, on the back end side, is very Linux-oriented. On the client side, OS X is very popular because it is historically artist-friendly *and* has a Unix inside, so you can develop both front end and back end software.
So get used to seeing a lot of OS X, and to some software not working or not being available under Windows, or being a pain to install.
I love this aspect of web development, but then I would say that, as I switched to OS X in 2003. And I've even slowly started learning about Linux system administration.
It's all online
It's all online. By definition. That might seem obvious, but in my experience game programming tends to be very conservative, and for a very good reason: at some point you had to compile that puppy onto a CD or DVD and then it was a major pain in the ass to make any changes. That is slightly easier now, but nowhere near as easy as on the web, where by pressing a single button you can route half of your audience to a different machine on a different continent where the software is written in a different language and nobody notices and *it's not witchcraft*. And by pressing a different button you can undo all that.
(And that audience often grows slower than in games too. Being able to do *real* MVPs, where you start with a dumb website and then scale up to potentially millions is very nice.)
Lots of languages
Cons: Pick the wrong language and you'll have trouble finding programmers, or the right programmers.
Lots of open source
Most of the software you'll work with is open source. This is very different from game development on Windows, in my experience. The downside of this is that licenses matter, so you better be aware of those, and sometimes projects get abandoned and bugs remain unfixed. But that's not *that* difference from commercial software, and in open source you can (and I do) fix bugs that bother you and even get them included back in the original software.
New technology *all the time*
Everything changes really quickly, and new frameworks and tools are developed all the time, often per language. They all have stupid names: Capistrano, Desert, Rake, Mongrel, Pip, Rails, Django, Lettuce, Jasmine.
People tend to run towards the Next Cool Thing, which can be annoying and counterproductive.
Rapid development, scalability, then maybe performance
I am not saying performance is irrelevant in the web world. I am saying that many technical choices are made to make development faster and scalability easier, rather than code faster. E.g. Python is fast for a dynamic language, but not fast compared to hand-tuned C++. But it's easy(ish) to set up a nice coding workflow with Python (say) and to quickly deploy your code to a server in the cloud, and to add additional servers to your web application.
Performance is an issue, but perhaps more in terms of page load times or server responsiveness.
Different tools and practices
Automated testing and continuous integration are popular in the web world - I think more popular, or at least common earlier, than in game tech.
I think automated testing became popular because a) as someone pointed out, HTTP is *ideal* for automated testing because it forces a clean interface, and b) if you don't have a compiler checking for a certain class of bug, it's worth doing something else to catch bugs.
You now see continuous integration in game development as well. And rightly so because it's awesome. Of course, by now the web world has moved to continuous *deployment*. Which leads us to:
One big part of these different tools and practices is a concept called DevOps. In the Days of Old, server programmers would write server software, put it on a disk, put that disk in a capsule, put that capsule in a pneumatic tube, and send it to the IT department. The IT department would put that software on a server and curse when it crashed at three in the morning because it took up too much memory. Meanwhile the programmers were lying on a beach somewhere.
Slightly more seriously: DevOps means considering developing, deploying, and operating software as one whole. In practice, for me, it means there are awesome tools for automatically setting up AWS instances and loading my software onto it and telling me when it crashes.
Front-end has workflows now