Saturday, May 21, 2011

Some Ideas I Like About Development

I read 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:

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.

Tuesday, May 17, 2011

Link: How to Quit Your Job, Move to Paradise, and Get Paid to Change the World

People often use Twitter to post links to interesting things, but I'm not a big fan of Twitter so I'm going to use my blog.

Saturday, May 14, 2011

A New Try at Blogging

(written on Wed)

Jason on the A Smart Bear blog wrote a post about how people and companies should have blogs so we're visible online. I can't help but agree with points, so I'm reviving my blog where I'll probably post about entrepreneurship, geeky technology, and my startup Exerdare. This may trail off into nothingness again due to my RSI, lack of time, or lack of motivation, but I have little to loose and much to gain by trying.

Speaking of Exerdare, I spent today working on the 3rd generation Exerdare bike prototype. For those who don't know what I'm working on, it's an exercise bike with built in multiplayer gaming to make working out more fun and competitive. The big remaining issue blocking "public" testing is that the data I'm reading from the sound card's line seems garbled. It looks fine when I record it in audacity so I'm probably doing something wrong with pyaudio. I'm writing this on the train on the way to the Columbia Venture Club Demo Night, where I'm presenting Exerdare.

That's it for now. More to come hopefully.