Hey, author here! I'm pretty overwhelmed that this made it to the top of HN without me even thinking of posting it here :)

I made this game as a fun weekend project, inspired by another game called 1024 (https://itunes.apple.com/us/app/1024!/id823499224) and a spinoff called 2048 (http://saming.fr/p/2048/). I did mine to add animations to the latter, which was a bit hard to play without them.

I discovered Threes only today, and I had no idea it looked so similar. I searched a bit and it appears as if 1024 is also inspired by Threes, so my game is probably the last of a long chain of clones :P

The code is also open-source. You can find it here: https://github.com/gabrielecirulli/2048

Feel free to ask me anything, and thanks to everyone for the attention! :)

By the way, my highscore is somewhere around 6000. Admittedly, I'm quite bad at playing my own game :P

EDIT: Make sure not to get addicted!

EDIT 2: The game now has swipe gestures and vim keys support (added by @rayhaanj)!

It seems that they go a few directions:

The most common seems to be to try and generalize, because relearning most of your job skills every few years starts to get annoying the 20th time you've had to do it. It's different when you are younger and everything is new, you just chalk up a major tooling change as just something else to learn. But when the next hot platform or architecture or whatever comes out you get tired of running in exactly the same place. You also start to get a long view on things, where all these new things coming out don't really seem to offer any advantage to you that keeps development fun. It's just more and more layers of abstraction and you start to see the nth demo of WebGL maxing out a 4 core modern GPU system doing exactly what you did 20 years ago with a single 32-bit core, 1/5th the transistor count and all in software. So how do you generalize? One word: management. You start to take over running things at a meta-level. You don't program, you manage people who program. You don't program, you design architectures that need to be programmed. You don't program, you manage standards bodies that people will be programming against. It's not a higher level, more abstract, language you go for, it's a higher level, more abstract job function. The pay is usually better and it's a natural career progression most organizations are built around. There's lots of different "meta" paths you can take. And because most of the skills in them will be new to you in your late 30s, 40s or 50s, they're at least interesting to learn.

The problem for some people is that these kinds of more generalized roles put you in charge of systems that do not have the sort of clear-cut deterministic behavior you remember from your programming days. Some folks like this, and look at it as a new challenge. Some hate it and wish for their programming days again. YMMV

So the next most common path is to just become more and more senior as a developer, keeping down in the weeds and using decades of experience to cut through trendy BS to build solid performant stuff. These folks sometimes take on "thought leader" positions, act as architects or whatnot. Quite often though industry biases will engage and they'll be put on duty keeping some legacy system alive because their deep knowledge of the system lets the company put 1 guy maintaining half a million lines of code in perpetuity vs. 10 young guys maintaining the same, who all wanting to leave after a few years to build more skills. The phenomenon is best seen as the ancient grey beard COBOL mainframe guys. Some people love this work, they can stay useful and "in the game", but some hate it because it comes with the cachet of being stale and not keeping up with the times. YMMV

Probably the third most common path is to simply branch out and start your own gig. A consultancy or something where you get to work on different things in different places on short engagements. The money is good while it's coming in and you get to make your own hours. At some point you decide to keep doing this till retirement (if you can keep finding work) or to grow your business, in which case you generally end up doing the meta-management thing. There are thousands of these little one-man development shops like this and I wouldn't be at all surprised if this is more common than third on my list.

Probably the next most common path is to just get out of development entirely. The kinds of logic, planning and reasoning skills, plus the attention to detail required to be even a half-assed developer, can be extremely valuable in other fields. Lots of developers go into Systems security, Business Analysis, Hardware, etc. With a little schooling you can get into various Finance, Scientific or Engineering disciplines without too much fuss. The money isn't always better in these other fields, but sometimes the job satisfaction is. Again YMMV.

I'm 60+. I've been coding my whole career and I'm still coding. Never hit a plateau in pay, but nonetheless, I've found the best way to ratchet up is to change jobs which has been sad, but true - I've left some pretty decent jobs because somebody else was willing to pay more. This has been true in every decade of my career.

There's been a constant push towards management that I've always resisted. People I've known who have gone into management generally didn't really want to be programming - it was just the means to kick start their careers. The same is true for any STEM field that isn't academic. If you want to go into management, do it, but if you don't and you're being pushed into it, talk to your boss. Any decent boss wants to keep good developers and will be happy to accomodate your desire to keep coding - they probably think they're doing you a favor by pushing you toward management.

I don't recommend becoming a specialist in any programming paradigm because you don't know what is coming next. Be a generalist, but keep learning everything you can. So far I've coded professionally in COBOL, Basic, Fortran, C, Ada, C++, APL, Java, Python, PERL, C#, Clojure and various assembly languages each one of which would have been tempting to become a specialist in. Somebody else pointed out that relearning the same thing over and over in new contexts gets old and that can be true, but I don't see how it can be avoided as long as there doesn't exist the "one true language". That said, I've got a neighbor about my age who still makes a great living as a COBOL programmer on legacy systems.

Now for the important part if you want to keep programming and you aren't an academic. If you want to make a living being a programmer, you can count on a decent living, but if you want to do well and have reasonable job security you've got to learn about and become an expert in something else - ideally something you're actually coding. Maybe it's banking, or process control, or contact management - it doesn't matter as long as it's something. As a developer, you are coding stuff that's important to somebody or they wouldn't be paying you to do it. Learn what you're coding beyond the level that you need just to get your work done. You almost for certain have access to resources since you need them to do your job, and if you don't figure out how to get them. Never stop learning.

A congressman saying that an interview should not take place really tells us all that we need to know about just how much an interview should take place.

I can think of no stronger endorsement of an interview.