↑ comment by Risto_Saarelma ·
2013-09-25T13:51:43.048Z · LW(p) · GW(p)
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.
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.
Replies from: pewpewlasergun, sketerpot
↑ comment by pewpewlasergun ·
2013-09-30T21:07:46.061Z · LW(p) · GW(p)
Regarding touch-typing, do you find yourself reaching 'top speed' often while programming?
Replies from: Lumifer, gwern
↑ comment by Lumifer ·
2013-09-30T21:22:56.709Z · LW(p) · GW(p)
It's not really about typing large amounts of text quickly, it's basically about
(1) not having to pay attention to the keyboard, your fingers should know what do without taking up mindspace; and
(2) your typing being able to keep up with your thinking -- the less your brain has to stop and wait for fingers to catch up, the better.
Replies from: Viliam_Bur
↑ comment by Viliam_Bur ·
2013-10-01T10:12:35.286Z · LW(p) · GW(p)
not having to pay attention to the keyboard, your fingers should know what do without taking up mindspace
Yes, this is a critical skill. Especially when someone is learning programming, it is so sad to see their thinking interrupted all the time by things like: "when do I find the '&' key on my keyboard?", and when the key is finally found, they already forgot what they wanted to write.
your typing being able to keep up with your thinking
This part is already helped by many development environments, where you just write a few symbols and press Ctrl+space or something, and it completes the phrase. But this helps only with long words, not with symbols.
↑ comment by gwern ·
2013-09-30T21:20:40.760Z · LW(p) · GW(p)
It's not the top speed, it's the overhead. It is incredibly irritating to type slowly or make typos when you're working with a REPL or shell and are tweaking and retrying multiple times: you want to be thinking about your code and all the tiny niggling details, and not about your typing or typos.