Every once in a while, a seemingly useful piece is posted here at hn that I read and, based on what has worked well for me, I simply don't agree with. This is one of those. Here goes:

1. Upgrade Test::Unit - What, you aren’t testing? You should be testing all the fucking time (TATFT).

Except when you're coding. And then you shouldn't be doing anything but coding. Sometimes you just gotta crank in order to make any real progress. It's a lot easier to test once you have something to test.

2. Try out some TDD - Test Drive Development (TDD) makes for better code.

No. Define your target. Code to it. Deploy. Then test. Lots of quick cycles blow away few slower ones. Just code with your pedal to the floor. Test time is the time for testing.

3. Upgrade your fixtures - I’m not sure I can advocate this approach due to the fact fixtures actually do provide some use.

Just because something provides some use doesn't mean you should use it. Get a good IDE or text editor, a good work area, and a little gray matter; that's all you need. Otherwise, you risk getting caught up in all your cool tools, an easy mistake to make.

4. Install (and learn and use) a SCM - The benefits of having code in some form of repository hugely outweighs it not being there.

Uh, I'd love to argue with this one, but I won't. Good advice. Either get some kind of repository or learn to walk on eggshells. Your choice.

5. Investigate Continuous Integration - ...makes automating your tests to run at checkin next to trivial.

Making checkin trivial is not a goal while coding. Getting something done IS. Anything that is not coding is not helping you make progress while coding.

6. Know your code - It is one thing to write your code, but it is another greater thing to know your code. Four automated tools...

"Know your code" & "automated tools" are mutually exclusive. See my response to #7 below.

7. Automate your deployments - Automation is your best friend.

Wrong. This is EXACTLY to opposite of #6, "Know Your Code". Automation takes you out of the very trenches you have to be in to get to know your code in the first place. The dirtier I get, the better I know my code. (For further reading, Chapter 3 of Founders at Work by Jessica Livingston. Woz (my hero) totally immersed himself in his details without crutches in order to know them as well as anyone ever has.)

8. Collect some statistics

Code now, get something working, and worry about analyzing it later. Again, anything that isn't "coding" is slowing you down.

9. Read other people’s code - You want to be a better developer? Read code. Read bad code. Read good code. Read your code. Read my code. Code reading is a skill that many developers skimp on.

I have NEVER liked this advice. Why? I've never found it the least bit helpful. Either I didn't understand the code or it sucked so much, I was too ill to work the rest of the day. Better: find something cool (on the outside) and figure out how to code it yourself. Ask for help or suggestions if you need it.

10. Blog about it

If you have time to blog, then your project isn't big enough. Code now, deploy, and blog later. Frankly, I don't want to read about your "adventures in development" until you're done and have something to say about your (completed) work.