A year ago, I was asked to follow up on my post about the January 2013 CFAR workshop in a year. The time to write that post is fast approaching. Are there any issues / questions that people would be particularly interested in seeing this post address / answer?

I'd like to go against Robin Hanson's recommendation and tell people to go see Her. The visual direction is beautiful, as one would expect, and quirks like fashion, advertisements, and art are just jarring enough to remind you that its the future. I found it easy to overlook the 'why don't they just buy an AI and make it write the letters' problems because it isn't really a movie about technology changing us, but how relationships and their endings do.

What's the difference between corrections and criticism? Did you get any that changed the way you do things?

“Whenever serious and competent people need to get things done in the real world, all considerations of tradition and protocol fly out the window.”

Neal Stephenson - "Quicksilver"

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 a regular there. Here are my observations.

This is fun. I haven't had this much social fun on-line for a decade. I'm a corporate stooge, and usually sitting at a keyboard and typing for a living is not that social and not that fun for me. As much as I enjoy spending time there, the mere social fun is not the purpose. I've noticed that whenever I join the chat without a clear goal, I tend to drift through pomodoros without achieving that much. I first need to do some GTD-style analysis of what project I want to work on, and what are actionable steps to take during a pomodoro. I like to ask the participants about their projects and I like and find it useful to briefly explain mine.

Apparently a little social salience can go a long way with me. BTW, that is a possibly useful observation for team mangers, and it agrees with what random pop-psychology of human motivation I've heard about.

I'm worried about the long-term prospects of this idea. I think most of the participants are students. During the first summer vacation season we'll likely see a big drop in participation.

Is the idea with the case studies to conduct an email interview with the subjects? Or just collect publicly available information from around the internet?

If you are reading this book and flipping out at every third sentence because you feel I'm insulting your intelligence, then I have three points of advice for you:

• Stop reading my book. I didn't write it for you. I wrote it for people who don't already know everything.

• Empty before you fill. You will have a hard time learning from someone with more knowledge if you already know everything.

• Go learn Lisp. I hear people who know everything really like Lisp.

For everyone else who's here to learn, just read everything as if I'm smiling and I have a mischievous little twinkle in my eye.

Introduction to Learn Python The Hard Way, by Zed A. Shaw

Could anyone comment on the market for biomedical engineers? I'm specifically interested in regenerative medicine, so the common advice of "get a degree in MechE or EE and apply to biomedical companies" doesn't seem like it would apply.

It was a full-time job, with meals and accommodation for $40/week.

Typo?