What advice would you give a non-programmer with a computer science degree willing to invest two years?

For languages, I wrote this piece, and I think the advice in it is good: http://michaelochurch.wordpress.com/2012/07/27/six-languages-to-master/ I recommend starting with Python because it's easiest to "do real stuff" in it, and because you can experiment with the functional style of programming if you want, but it's not forced upon you. Once you "get" list comprehensions, you're halfway to functional programming. Since you're already in finance, you may want to learn q. It's esoteric and Lisp-like and really cool, and it gets a lot of use on Wall Street. q is great for forcing you to think in terms of sets of data, which is a skill that programmers who work on traditional business apps don't pick up, but essential if you want to work on the most challenging problems ("big data", machine learning, scalable architecture). Then learn C (close to the hardware) and get a working knowledge of assembly: at least what it looks like, if you never actually code in it. After that, ML or Haskell would be great for giving you a sense of what static typing can accomplish. You'll want to pick up a Lisp (I recommend Clojure) to learn about language in the abstract. For my part, I think ML is the most educational language because the code quality in the community and libraries is phenomenal. It's actually quite fun (!) to read code in it. (Java is the most "employable" language, but the code quality is pathetic because there are a lot of substandard Java programmers, and there's also a bunch of uninspiring stuff like "dependency injection" and "design patterns" that's been slapped together to compensate for the underpowered language that you have to learn in order to be competent in Java.) For practical reasons, I generally use Scala for my projects. It's an all-around good language: statically typed, functional, and it runs on the JVM so you have access to all the Java libraries. The reason I advise against starting your programming career in Scala is that there's still a lot of cultural cruft (not in the language itself, which is designed and maintained by some stellar people, but in the culture) inherited from Java that has to be worked out (see dirty secret #4). I would not advise someone to start in Scala, but if you've developed good taste by having it forced upon you through years in ML, Haskell, or Lisp, it's a very powerful language. I wouldn't advise you to quit your day job. You have a good quant job as it is, and you don't need to be a full-time professional programmer to become good at programming. You just need curiosity and a strong work ethic. Mathematical intelligence helps, and you probably have that. Learn Git and get yourself into the open source world one way or another. Either work on other peoples' projects, or build your own and ask people you trust to review them. Work on things that genuinely interest you. My current side project is to implement (after 9 long years) a card game I wrote in 2003: https://docs.google.com/document/d/1S7lsZKzHuuhoTb2Wj_L3zrhHZh5IEKBDf56ExgErv4o/edit . My current task is to apply machine learning techniques to the game to try to (a) verify certain traits of the game's design that I believed to be true, and (b) develop competent AI so I can build and release the thing. Eventually, it'll evolve into an excuse to learn front-end development (and possibly iOS/Android) when I release the game to the world. Work on things that are of personal or professional interest to you. For example, don't focus on how to build websites unless you have something to say. This stuff is hard and you'll need motivation to get better. Some dirty secrets of programming: 1. You're mediocre and that's okay. I'm a mediocre programmer. On this scale here-- http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ -- I'm about a 1.8 (out of a possible 3.0+). That puts me around 97-98th percentile and means I'm about 10^0.8 = 6.3 times more valuable than a minimally competent (1.0) software engineer. I call that "mediocre" because the ass-kicking graybeards at 2.6+ (who are generally well-known people) are just as much better than I am, and it'll probably take me 8-12 years to get to that level. What makes programming fun is that you can always keep getting better, but the flip side is that you'll always be mediocre compared to what you can be. It's the Go (as in the board game) of occupations: there's always more to learn, and someone out there who's better. 2. Taste and simplicity are more important than everything else. It's okay to be mediocre-- if you're smart about it. Keep your own mediocrity in mind when you design systems. Always think, "Will I be able to debug and understand this damn thing a year from now?" If the answer's "no", then the odds are that no one else will either. Good programmers write code to be read and enjoyed, not just to pass the compiler. The code should be instructive on how to solve the problem, not obfuscatory or extremely "clever". If you have to be clever, put some real thought into documentation. Use only the first 110 IQ points for grind work and cleverness. Put the rest into design and taste and simplicity of interfaces. Keep in mind that programmers are about 30 IQ points dumber when in someone else's code/complexity than when in their own. 3. You don't have to be a paid programmer to learn, and if you are a professional programmer, be extremely selective about the work you accept. Very few programmers are lucky enough to get paid to work on projects that will make them great; most will have to do that on their own time. Don't typecast yourself to "a programmer". Become a risk professional who can program. Turn programming into a force multiplier, not a forced identity. Find things you can automate to be more efficient at your work. Ten hours per week on interesting work is going to do more for your career and ability than 40 hours per week of what most professional programmers do. 4. Learn small-program (Unix philosophy) methodology. Now. Don't use an IDE unless/until you have to. (If you're reading other peoples' code and have more than a couple thousand lines of it, you need an IDE. So use one. But you should be capable of developing without one. IDEs have this nasty property of making demands on your directory structure and tool chain that make IDEs somewhat like the Mafia: you can get in, but you're never out.) For this, once you start reading other peoples' code, you'll learn something painful: Big Code is almost always incomprehensible. IDE or no IDE, static or dynamic typing, object-oriented or functional... doesn't matter. Big Code is almost always miserable and inefficient. But if source code is an asset, then how could this be? The answer is that large programs are usually far less than the sum of their parts, with 2-10% of code in most enterprise-size codebases actually delivering real business value. Paradoxically, it's better to have lots of small programs (which looks like "chaos" to a manager, but is actually better) than a few big ones. There's a long-running war between small-program and big-program models of development. The Unix philosophy (small-program) is that programs should do one thing really well and be considered "finished" when the problem is solved. Scope creep into large, ambitious, general-purpose frameworks is to be avoided. Complexity in single programs should be avoided if at all possible, and complex problems that require more than a couple thousand lines of code need to be factored. For example, some of that code is actually data (i.e. that 25-line match block) and belongs in the database. Other bits of that code are reusable and should be split off into independent libraries. Factoring forces you to separate code into (a) libraries of general usefulness, (b) executable programs that are actually run to solve problems, and (c) data, rather than having all that junk garbled together. Complex problems should be solved using systems where attention is paid to fault tolerance and communication protocols that evolve slowly and conservatively, not single-program projects that succeed or fail on an all-or-nothing basis.  The Unix philosophy isn't completely right (one traditional tenet is "store data in flat text files", but databases are damn powerful and useful) but it's probably 95% right, and in comparative programming, that's about as right as any ideology can be. In small-program methodology, programmers write small programs that solve specific problems and that have agreed-upon semantics. The programmer:program relationship is one-to-many. A programmer might write 10 or 20 programs in a year of work. Programs are actually finished, and they often go into use right away. In small-program methodology, programmers spend most of their time writing new code and solving new problems; they only hack other peoples' code if they need to do so (to fix a bug or improve performance). In big-program methodology, the programmer:program relationship is many-to-one. Each programmer is "assigned" to a massive and usually bloated single-program project. Communication within the single-program project is a huge mess, semantics are ill-defined, and spaghetti code becomes a real problem. Maintenance can easily take up 50-95 percent of programmer time before the project is even launched. This makes it easier for managerial dinosaurs to track time and effort (this project has headcount 5, this one has 3) but it trashes the code quality. For the past 20 years or so, the large-program methodology has been winning. Why? First, because software used to be shipped in a box and bought in B&M stores in strip malls (and people flew on pterodactyls do get there). Second, political reasons. Small programs are written to solve problems; large programs are written to get promotions for managers who conflate bigness with success (cf. the interview question, "What's the largest team you've managed?") and therefore dream up immensely ambitious, impractical, all-or-nothing software monoliths. For more on the cultural forces at play, see this: http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ If you want to become a decent programmer, you need to learn small-program methodology, although few software jobs will teach it. Don't get me wrong: there are good programmers who work on big-ass Java projects to pay the bills, because big-program methodology is still winning, but 1.5+ programmers invariably agree that small-program methodologies are correct (and agree, as a group, on little else). Lucky for you, you're a risk manager. So scripts and small programs to perform data analysis and automate grunt work will come naturally to you, which means that a small-program methodology is a natural fit for your professional position and interests.

Good start & I see lots of good advise from Yang, Bruno, Michael & Jeffrey. My thoughts: Keep it simple & focussed. Depth is more important than breadth Algorithms - Yep, understand them & program them Git - Yep, essential Understand & work with NOSQL - MongoDB is a good choice Haskell is good, but as a learning tool for functional programming Spend most of your time on two languages - Python (or Java) & JavaScript (Node, jQuery, Backbone.js,...). This would cover the web backend & front end You can also focus on mobile development - first via JavaScript frameworks and then Objective-C Another area is the Data Science - Python/NumPy/SciPy/Pandas or the R language - tryout some stuff (for example work out my OSCON tutorial on Twitter (http://doubleclix.wordpress.com/2012/08/04/big-data-with-twitter-api-twitter-tips-a-bakers-dozen/) Again, don't focus on all of them, because you will spread yourself thin Also pick problems and learn in the context of the problems. These could be exercises/assignments from lecture notes or programming competitions Cheers & Good Luck <k/>

I typically agree with 's answer that generalist programmers should start with Python, because it's quite roughly "in the middle" between abstractness (speed, simplicity), and breadth of community support. JavaScript is where I typically tell people with zero programming background to start, but with your existing background, you should have no difficulty jumping into JS from Python if you wanted to build webby stuff. To all that he said, I'd only add that, I generally advise generalists that going into C (or anything involving manual memory management) is kinda like studying chainsaws - useful only for extreme performance requirements in certain dimensions. Overall, I'd also agree that you should start by thinking about your end-goals, before you choose the means, as said. If you're into linguistic styles, and mathematical elegance, you may specifically want to start looking at languages which are purely functional - though those tend to be less useful for general engineering projects. Erlang is a functional programming language, which runs on a VM and with a library that were both designed for industrial applications, and have been battle-tested for decades.

2 hours per day for all you've mentioned and in only two years? Sorry but you likely won't get anywhere beyond the basics that way, not even that probably. If 2 hours per day is all you mean to spend, then focus on only one of the things you mention - trying to multitask all of them in that little time will only frustrate you. I suggest you start with an easy language like Pyhton - for many, Python is a gateway drug into other languages. By the time you grasp the basics you'll know whether or not you want to deal with software development in any degree later on. Reading classics and learning theory is all very healthy, but it will do you little good unless you get your hands at least some kind of dirty. Start out with Python and stick with that one exclusively for at least 6 months (maybe even more, since it's only 2 hours a day). By then you'll be in it enough to start reading (and understanding) the coding classics you mention, and all that should open up new doors for you, should you choose to pass through them.