canspice.org

This tutorial isn’t about specific programming tips, it’s more about tools that you can apply to your programming skills.

Computer Science + People = Software Development

Now that you’ve grown up and don’t have structured learning, how do you learn new things? You have to unlearn how you previously learned, because those techniques don’t really apply very well any more. Buy why learn? Learning takes time, time that you could spend doing things that you already know how to do. One reason to learn is that you’re doing it wrong and you need to learn how to do it right. Also, cross-training is sexy; you can steal ideas from different areas and apply them to programming. If you tie yourself to a specific technology, that technology will eventually die and you’ll die with it.

A lot of people don’t get over the discomfort hump when they’re learning new things. Over time your discomfort with something new will diminish. Having a substitute skill (i.e. QWERTY when you’re trying to learn Dvorak) also prevents people from adapting new skills.

And a lot of people are afraid to say “I don’t know” and “tell me about it” — counter-intuitively, asking these questions can actually help your credibility. So ask them. And ask why, as doing so can teach you things when you try to find the answer. Knowing how something failed isn’t necessarily the same as knowing why something failed.

One of the ways to learn is to fail. You can’t learn from your mistakes if you don’t make any mistakes in the first place. And failing is something that you’ll do if you start learning new things, so failure shouldn’t be seen as a failure, it should be seen as a victory.

Hang out with people who like to learn. Don’t hang out with the 9-to-5ers who are just there to earn a paycheque. Join a community, as the community can help you learn with its massed knowledge. Try broadcasting your problem via blogs, IRC, user groups, etc.

Go be stupid. Go somewhere where nobody knows you’re supposed to be smart.

Learn a different language or language type. There’s procedural (Perl, C, assembly), functional (Haskell, Scheme, Lisp), object-oriented (C++, Java), and declarative (Star Trek computer: “Tea, Earl Grey, hot”, SQL).

Watch out for communication breakdowns. If possible, rely on face-to-face communication instead of email, where the communication is more “people talking at each other”. Video is nice as well, then try voice, then try IM. Don’t second-guess what people say. Assume that what they wrote is what they meant.

If you’re having an argument, you become emotionally invested in that argument and you really want to win. Find the courage to say “you’re right” to the person you’re arguing with. If there’s a problem somewhere in your code, don’t focus on the person who caused that problem, focus on the actual problem with the code. Tools are not good or bad, they have advantages and disadvantages. If you find you’re going back and forth with the same person on a mailing list, odds are good you’re talking past each other and there’s a source of miscommunication somewhere. Bitching about a problem isn’t the same as doing something about it.

The problem with programmers is that they care about code. Everyone else cares about the goals.

Avoid communication breakdowns by being available. If your business’s regular hours are 9-to-5, try to make yourself available for a slice of that, even if it’s just via IM.

Get stuff out of your head so that if you get hit by a bus, the project doesn’t die. There are various ways to do this, through code documentation, a wiki, a bug tracking system, use Getting Things Done philosophies.

Don’t do fear-based programming, because you’ll never do anything interesting. If you work in small chunks, you can get things done quicker, the less impact a failure will have on the larger picture. An antidote to fear-based programming is testing. Test first, test during, test automatically, and make sure all your tests pass all the time. Test your bugs; whenever you fix a bug write a test testing that that fix is correct.

Use effective version control. Use a code-test-commit cycle. Commit small chunks. Commit one idea per commit. Branch tasks off to their own branch so you’re not always committing to the trunk (more modern version control software such as SVK make this easy).

Two things to take home: software is about people, and do things in small chunky pieces.