Someone on the Business of Software forum asked how others motivate themselves to get working. This is a timely question. The jump from FlowBreeze 1.x to FlowBreeze 2.0 has been a long struggle. The code base has grown 3X and of course that doesn’t include the re-writes and thrown away code. Facing burn out in the final stretch, I’m pulling out every technique I can think of to get 2.0 out the door.
Below are the techniques I’ve been using. They don’t come from some motivational or time management book, but I’ve found they work for me. YMMV:
- ID all the mundane TODO’s that don’t require much thinking. Do those when you’re tired or lazy.
- Start writing your help file. It’s never too early to begin, and if you put it off until the end you’ll shortchange the effort. Some people might fit this under #1 above, but if you think writing a help file doesn’t require much thinking then you’re either a naturally good tech writer or your user documentation sucks.
- Edge into the periphery of tough problems. Pseudo code, helper methods, data structures supporting the tough problem - whatever it takes. Eventually they’ll suck you in, and you’ll forget that you were tired.
- Print out your existing code, sit in a comfy chair and review it. Make notes in the margins. It’s productive, you’ll find bugs or inefficiencies, and often you’ll spot something that motivates you to take immediate action.
- Back to the comfy chair. Make a list of all your TODO’s and break them into the simplest possible tasks. Find the easiest one and tell yourself you can’t take a break (or go to bed) until you do that one little thing. Typically, you’ll finish it then knock out a few more. Often, you’ll knock out a lot more.
- Use the technique Jerry Seinfeld motivated himself with to write new stand-up material. Keep a calendar and tell yourself that everyday you need to do at least one thing on your application. When you’ve done one thing, you can place an X on the calendar. The goal then becomes never to break the chain of X’s.
- Sit down and work. Sometimes the “just do it” thing really is the best motivator.
4 responses so far ↓
Starr // Sep 18, 2007 at 7:01 am
This is a great list, Nick.
One thing that’s improved my own productivity is to have a list of non-coding tasks. Writing blog posts, doing graphics in photoshop, etc.
It seems like these use a different part of the brain than programming. So I can be exhausted from coding, then happily put in another 2 hours on graphics.
Chris Exline // Sep 20, 2007 at 11:03 pm
Good list. That is the second time I’ve heard the about the X’s on the calendar, but I didn’t know it came from Seinfeld. I’ve been thinking about that and I think I’ll go buy a calendar tomorrow to do that.
Working alone makes it hard to stay focused and motivated. During the development of my product, I found that I would let one of my beta testers know about a feature and tell them it would be ready in a week. Then I had to get it finished so they could try it out. A deadline can be very motivating. Since my product is a web application this is a lot easier to do than with a desktop app.
Good point at the help documentation. It is one thing I’ve been putting off, and I think I start on it tonight.
Nick H. // Sep 21, 2007 at 12:05 am
One thing about the screen shots and graphics - not only are they good fillers for “brain dead” time, but they ultimately make me more productive when it comes time to use them.
Whether I’m blogging or creating a help file, having to stop in the middle and create the accompanying graphics breaks the flow and slows me down. Sometimes it stops me entirely. I have a dozen fairly long blog posts and articles that I haven’t published because I never got around to creating the required graphics to support them.
Regarding the X thing - I admit I don’t do it for a full calendar. I typically limit the scope to a small project or a complex feature. I’ve just used a hand drawn grid and taped it to my desk.
For my current documentation, I have trouble determining the what topics to include and how to outline the structure.
For forms, I’d write a bit of code that would iterate through the controls and output their names and captions. I copied and pasted that into the help file, saving me the effort of typing in all the labels.
Once the outline was decided and the control labels were in place, filling in the content became a lot easier.
Chris Exline // Sep 21, 2007 at 1:26 pm
My problem with documentation is I’ve lived in the program for to long and have clicked every button and filled out every form so I think it all is perfectly obvious. Of course I tell someone else to try a feature out and they couldn’t find it. So it is not as obvious to the rest of the world. I think I have to err on the side of really obvious help, spell out each thing. Not nearly as much fun as writing the code, but it will save on a lot of time later when dealing with support. At least that is what I keep telling myself.
I like the idea of the outline and parsing the controls out to give you a start. I’ll have to give that a try.
Leave a Comment