Some Ideas I Like About Development

I read http://edweissman.com/53640595 and here are some bits I especially liked.

I work in 2 modes: (A) At the computer and (B) Away from the computer.

When I'm in Mode A at the computer, I'm cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I'm not working that fast, then I must not be prepared to work that fast, so I don't deserve to be at the computer. I should be in mode (B).

Mode B is generally much slower. Reviewing code, specs, or notes. Refactoring code. Laying things out with pen and paper. When I have enough work clearly laid out, I know it's time to get back to the computer and return to Mode A.

The most important thing for me in Mode A is to see results, any results, quickly and often. It doesn't matter how correct anything is, just as long as it's progress (or sometimes, reverse progress). I like to think of programming as making incremental progress in micro jumps, evaluate where I'm at, and go for the next micro jump.

How do you stay productive?

1. Do not have access to the internet on your work machine. If you don't have 2 computers, get a netbook for < $300 and connect it to the internet. They should be in 2 different workstations, ideally in 2 different rooms. The thinking is that if you have to get up, you'll only do it if it's really necessary. It works pretty well.

2. You should have 2 modes: coding and not coding. For coding, you should be at your desk coding. For not coding you can be anywhere, but "not at your desk". One of my biggest problems is that I often find myself in one mode when I should be in the other. If you're having trouble writing code, then you probably don't know what to write. Grab source code listings, pen, & paper and "get away from your computer". Don't come back until you know exactly what you're going to be working on. Better yet, until you're "dying" to work on it. On the other hand, if your doing analysis and are stuck, stop. Go back to the computer and code something, anything small, just to get going.

3. End every day in analysis mode. Don't go to sleep until you have tomorrow's plan ready. You should wake up knowing exactly what you're going to be working on and excited to do it.

4. Never text or IM when working. Have the cell phone nearby only for emergencies. For email, go to the other computer once an hour (see #1 above).

5. Try 48 minutes on, 12 minutes off. For long coding sessions, this works pretty well for me:

http://successbeginstoday.org/wordpress/2006/09/the-power-of...

6. Ipod.

Where do you like to sit in your office?

I prefer to sit with my users. As you can imagine, this concept is met with a bit of resistance in corporate America.

I want to dwell with them and be a part of their lives. I want to hear them complain about their apps, their customers and vendors, their bosses, and each other. I want to know what they go through all day every day.

When I sit and suffer with them, the resulting software is "always" better. All the meetings, prototypes, demos, specs, etc., etc., etc. have never been able to deliver the same knowledge needed to develop their apps.

On the other hand, I "don't" want to sit with other programmers, unless we're working on the same thing at the same time. I don't care about your problems, I have my own.