Eliezer mentioned in a past discussion where he got the name Verres. Iirc it was a reference to someone/something, though I don't remember who/what. (This falsified my standing hypothesis at the time, which was that EY got the name from Latin for "truth".)

Took the survey. Cooperated because most puzzles which explicitly use the words "cooperate" and "defect" have been created in such a way as to make cooperation the better choice.

(Considering my fairly low chances of winning, a deep analysis would have had only recreational value, and there were other fun things to do.)

Preliminaries: Make sure you can touch type, being able to hit 50+ wpm without sweat makes it a lot easier to whip up a quick single-screen test program to check up something. Learn a text editor with good macro capabilities, like Vim or Emacs, so you can do repetitive structural editing of text files without having to do every step by hand. Get into the general habit of thinking that whenever you find yourself doing several repetitive steps by hand, something is wrong and you should look into ways to automate the loop.

Working with large, established code bases, like Vladimir_Nesov suggested, is what you'll probably end up doing a lot as a working programmer. Better get used to it. There are many big open-source projects you can try to contribute to.

Unit tests, test-driven development. You want the computer to test as much of the program as possible. Also look into the major unit testing frameworks for whatever language you're working on.

Build systems, rigging up a complex project to build with a single command line command. Also look into build servers, nightly builds and the works. A real-world software project will want a server that automatically builds the latest version of the software every night and makes noise to the people responsible if it won't build, or if an unit test fails.

Oh, and you'll want to know a proper command line for that. So when learning Linux, try to do your stuff in the command line instead of sticking to the GUI. Figure out where the plaintext configuration files driving whatever programs you use live and how to edit them. Become suspicious about software that doesn't provide plaintext config files. Learn about shell scripting and onliners, and what the big deal in Unix about piping output from one program to the next is.

Git is awesome. After you've figured out how to use it on your own projects, look into how teams use it. Know what people are talking about when they talk about a Git workflow. Maybe check out Gerrit for a collaborative environment for developing with Git. Also check out how bug tracking systems and how those can tie into the version control.

For the social side of software development, Peopleware is the classic book. Producing Open Source Software is also good.

Know some full stack of web development. If you want a web domain running a neat webapp, how would you go about getting the domain, arranging for the hosting, installing the necessary software on the computer, setting up the web framework and generating the pages that do the neat thing? Can you do this by rolling your own minimal web server instead of Apache and your own minimal web framework instead of whatever out of the box solution you'd use? Then learn a bit about the out of the box web server and web framework solutions.

Have a basic idea about the JavaScript ecosystem for frontend web development.

Look into cloud computing. It's new enough not to have made it into many curricula yet. It's probably not going to go away anytime soon. How would you use it, why would you want to use it, when would you not want to use it? Find out why map-reduce is cool.

Learn how the Internet works. Learn why people say that the Internet was made by pros and the web was made by amateurs. Learn how to answer the interview question "What happens between typing an URL in the address field and the web page showing up in the browser" in as much detail as you can.

Look into the low-level stuff. Learn some assembly. Figure out why Forth is cool by working through the JonesForth tutorial. Get an idea how computers work below the OS level. The Elements of Computing Systems describes this for a toy computer. Read up on how people programmed a Commodore 64, it's a lot easier to understand than a modern PC.

Learn about the difference between userland and kernel space in Linux, and how programs written (in assembly) right on top of the kernel work. See how the kernel is put together. See if you can find something interesting to develop in the kernel-side code.

Learn out how to answer the interview question "What happens between pressing a key on the keyboard and a letter showing up on the monitor" in as much detail as you can.

Write a simple ray-tracer and a simple graphics program that does something neat with modern OpenGL and shaders. If you want to get really crazy with this, try writing a demoscene demo with lots of graphical effects and a synthesized techno soundtrack. If you want even crazier, try to make it a 4k intro.

Come up with a toy programming language and write a compiler for it.

Write a toy operating system. Figure out how to make a thing that makes a PC boot off the bare iron, prints "Hello world" on the screen and doesn't do anything beyond that. Then see how far you can get in making the thing do other things.

Also this list looks pretty good.

I'm back in school studying computer science (with a concentration in software engineering), but plan on being a competent programmer by the time I graduate, so I figure I need to learn lots of secondary and tertiary skills in addition to those that are actually part of the coursework. In parallel to my class subjects, I plan on learning HTML/CSS, SQL, Linux, and Git. What else should be on this list?

Interesting to hear your experience as a TA validates mine as a student. That's a good example of what I mean by an unnecessary assumption or simplification that was done purely to make the class more manageable for some students.

A not-insignificant portion of engineers don't know much anything about physics or math and want nothing to do with either. This is very scary, because these people tend to blindly follow standard engineering practice (which is not necessarily correct) or worse, make up something that is very wrong. A friend of mine told me they went to a job fair and heard a recruiter for an engineering company brag that you won't have to do any more calculus if you worked for them.

Not stepping back and thinking strategically about where to go and why before beginning a PhD program.

Because of a deteriorating relationship and problems in my current lab, I felt completely overwhelmed by the prospect of choosing a PhD. I was being told by my superiors that I had loads of potential and therefore had to get into the most prestigious institute possible. I therefore copped out of the difficult task of doing a PhD and essentially allowed my supervisor (who I knew was incompetent) to choose one for me. I never asked myself if I really wanted to do the research I was being pushed towards, if labwork was a rational choice for someone with my skillsets, or, more importantly, if I wanted to do a PhD at all.

Imagine my embarrassment when I start reading lesswrong and discover that stories like this about grad school are a stock example of irrational behavior...

Not having any friends or interests outside of STEM (during university), or even outside a very specific nerdy mindset.

Seconded. I still find this hard to undo, though I've realized the problem at least for a few years now. The problem is that your sense of what people value and think about is highly, highly skewed if you just hang out with nerds. Further, people outside the nerd community have a broader emotional repertoire.

I realized that I had a narrow social circle when I counted how many of my friends can do "Integrate[Exp[-x^2],{x,-Infinity,+Infinity}]" in their sleep. You can use a similar test to figure out the narrowness of your social circle.

Just a guess: you need more working memory and more complicated processing to parse the second case -- try writing a parser for each!

In the first form (which is like RPN) it's push-on-stack all the way through until the first verb to construct a complete determiner. In the second form you have to first push all the nouns on stack, then keep popping the stack up for each verb to match with the corresponding noun to construct the determiner. Except that the last verb corresponding to the first noun is not a part of the determiner, so you have to check that.

TL;DR: RPN expressions and parsers are simpler than the alternatives.

At which point, Polly decided that she knew enough of the truth to be going on with. The enemy wasn't men, or women, or the old, or even the dead. It was just bleedin' stupid people, who came in all varieties. And no one had the right to be stupid.

• Terry Pratchett, Monstrous Regiment