When programmers can write no more
news.zdnet.com
news.zdnet.com
"I've never suffered from it," said systems software consultant and XML specialist Bill Schindler. "Why we let people get away with silly things like writer's block/programmer's block, I don't know."
It really annoys me if people are proud of their ignorance. I wish Mr Schindler a healthy dose of programmers block to open his eyes. But granted, as an XML specialist he probably really is almost immune to the condition, must be rather thick skinned to begin with.
Personally, if I'm absolutely stuck at how to approach a coding problem, I simply start coding the dumbest solution for it, violating every rule in the book just to move forward. Usually that is enough to get the ball rolling and with today's tools, refactoring the code afterwards does not take very long at all.
There are two solutions to this. First, cultivate a good source of ideas. Beta testers are wonderful for this purpose. Second, don't start coding as soon as you have an idea -- write them down, and when you don't know what to do next, go back to your list of ideas. I aim to have 1-2 months of ideas for tarsnap planned out at any given point, so that if I'm feeling uncreative I can just pull up my coding to-do list and start implementing things.
What happened to me was complete lack of programming problem solving skills. For about 6 months I was dead in the water. Coders block seems like a cute analogy but I was plain old burnt out. I managed to get by coding by numbers but it wasn't pretty. I quit my job, within a month I was getting the itch to code and then I was off again. I was lucky to be able to quit though. I know a lot of people can't take such extreme action.... it works though.
- Decouple analysis from coding. There are some things that should NOT be done in front of a terminal. Get a pencil and paper and go somewhere else. By the time you're done, you'll have plenty of stuff to code. (I have found that the main reason I get stuck is because I have not spent the requisite time away from the terminal laying things out. I'm always in too much of a hurry to "get back to work" before I'm ready.)
- Get a customer. They'll give you something specific to work on. If it's maintenance, all the more reason to get to just dig in and get to work.
- Ask yourself the question, "How am I making this too hard?" If you listen to yourself long enough, you'll probably get a good answer and a fresh approach.
- Reduce scope. Remove outlying cases. Solve only for the most probable case. Get that working perfectly. The process of doing this will probably shed a lot of light on how to set up structure that will also handle the outlyers.
- Back up your current version and the go wild on it with some crazy approach. Knowing you have a good backup frees you up all the more. At the end of the day, if you have something cool, keep it. If not, just restore your backup and throw away today's work. You may have wasted the code, but you didn't waste your time. You probably got the juices flowing again.
- Backup your current version and forget about it. Wipe the slate clean and start over completely. You won't have to worry about satisfying all the overhead you've already created. After a day or two, keep either the original version, the new version, or more likely, you'll have a new project: combining the best of both. In any case, you'll be busy working again.
- Set the project aside and work on something easy and fun that no one needs and provides little value to anyone. The byproduct is that suddenly, you'll discover you're working and enjoying it. The next thing you know, you'll want to go back to the more difficult project.
- If you're stuck on something, post your dilemma here. Read the responses. You may get a different approach that you can play with. And even if you don't, you won't feel so alone. That may help.
"And just two months ago, Microsoft Corp. (msft) introduced yet another new language, C# (pronounced C sharp), to the market. "