| I read an article recently about "writer's block"; | | | | coming up regardless of how stressed you might |
| the problem writers have on occasion when they | | | | be. One trick that can help is to take a look at |
| just can't seem to figure out where to start on | | | | other programs that perform functions similar to |
| their current project or what to say next. In the | | | | what has you stumped. Sometimes just |
| article, the author commented in passing that the | | | | rummaging through other software and glancing |
| problem of "writer's block" seemed to be unique | | | | at the way it works can give you an idea of how |
| to the writing profession; that people in other lines | | | | to attack the problem you're hung up on. Even if |
| of work such as architects or programmers or | | | | the programming language is different or the |
| musicians didn't suffer from that malady. | | | | software is written for a different platform, the |
| That got me to thinking. Having been a | | | | basic approach used in designing the system may |
| programmer for many years now, I can | | | | spark an idea. |
| guarantee that I've experienced the equivalent of | | | | 4. "Talk the assignment over with a buddy, your |
| "writer's block" on numerous occasions. In my | | | | dog, or an imaginary friend": For software |
| case, the "blockage" usually centers around how | | | | developers I would add another option -- ask for |
| best to design a new piece of software or how | | | | advice on your favorite forum. How much good |
| to proceed when I run into problems with the | | | | this will do you is debatable. As a rule no one else |
| way I've built some part of the application. | | | | is familiar enough with what you're working on to |
| Getting started is almost always traumatic to | | | | be able to provide much help (even if they have |
| some degree, unless you're designing a software | | | | the time and inclination). If it's just a matter of |
| package that's very similar to something you've | | | | your code not working correctly though, forums |
| done before. Even after gathering as much | | | | can be a great place to get some assistance. In |
| information as possible about the program(s) to | | | | the end, the person best suited to help you is you |
| be written, it's still difficult to decide on the best | | | | -- and sometimes just pacing back and forth and |
| way to design the system until you've created at | | | | talking it over with yourself has been known to |
| least the beginnings of a working model of the | | | | bring forth a solution to the problem of the |
| software. | | | | moment. A word of caution however -- you |
| And even if you get started in good shape, then | | | | should probably do this in the privacy of your own |
| comes the inevitable list of items you overlooked | | | | office or, if you don't have an office, find a |
| or didn't fully understand, combined with the | | | | vacant stairwell or an empty breakroom. People |
| changes and additions requested by the end user. | | | | who spend a good deal of time talking to |
| If that list gets too large or too complicated, it's | | | | themselves tend to make those around them a |
| easy to lose your way. When you reach a point | | | | little bit nervous. |
| where you can't see clearly how to proceed, you | | | | 5. "Change your writing environment if necessary": |
| can even begin to feel like your whole approach | | | | If your environment is a problem, if there's too |
| may be wrong and you might be better off to | | | | much noise and confusion and you're having |
| scrap everything you've done and start over. | | | | trouble concentrating, lock yourself in the |
| You're just not sure what to do next -- bingo, | | | | restroom, hide under your desk, or do whatever |
| "programmer's block". | | | | you need to do to get some quiet time. When |
| So, what can you do to avoid or at least reduce | | | | you're really focused, things seem to flow out of |
| the chance of running afoul of "programmer's | | | | you in an organized stream like an assembly line. |
| block"? Let's take a look at the tips given to | | | | Constant interruptions can cause you to lose |
| writers to overcome this obstacle: | | | | focus and suddenly your assembly line goes |
| 1. "Make at least a rough outline before you start; | | | | haywire. You lose track of where you were and |
| that way you'll always have at least a guideline to | | | | where you were planning to go, and it can be a |
| fall back on": Most software projects have an | | | | major struggle to get re-started and back on |
| "outline", whether it's called "system specifications" | | | | track. It can even lead you to make hurried |
| or "the project plan" or something else. I have | | | | decisions that take you to a dead-end and leave |
| worked with specifications that were an almost | | | | you wondering what to do next. |
| exact blueprint for creating the software -- | | | | 6. "Quiet your inner critic -- the voice that tells |
| however in my experience that's the exception, | | | | you that nothing you write is good enough": I'm |
| not the rule. If a detailed specification even exists, | | | | willing to bet that most software developers have |
| it's usually no more than an educated guess as to | | | | an "inner critic". I know that I do, and it can bring |
| how to design the system. It doesn't get into the | | | | me to complete halt if I let it. There are times |
| nuts and bolts of building the software and that's | | | | (especially if I'm working in an area that's new to |
| where "programmer's block" normally occurs. The | | | | me) when no matter what I come up with, that |
| main value in a set of system specifications is | | | | voice is talking to me, telling me that what I'm |
| simply to remind you of what has to go into the | | | | doing is amateurish and poorly constructed and is |
| system and what needs to come out. How you | | | | never going to work worth a hoot. The only real |
| accomplish that is always subject to change. | | | | answer to that inner critic is to slog ahead, check |
| 2. "Loosen up; forget the deadline and the | | | | your work, and do the best you can. Software |
| assignment": This one's not usually an option. In | | | | development, like writing, doesn't just come |
| fact, one of the biggest problems for most | | | | naturally. It's hard work and the harder you work |
| programmers is the pressure to meet pre-set | | | | at it and the more of it you do, the better the |
| deadlines regardless of changes, rewrites or other | | | | result. No one's perfect and there are going to be |
| problems. If you've been working non-stop for | | | | mistakes and things that could have been done |
| hours though, it can help to take a quick break -- | | | | better -- catch as many problems as you can as |
| get up, walk around, try to focus on something | | | | early as you can and make lots of notes as to |
| else for a few minutes. | | | | how the system works so changes and additional |
| 3. "Switch to an easier project temporarily": | | | | corrections can be made later. There are a lot of |
| Working on some other program that doesn't | | | | other answers to avoiding "programmer's block"; |
| give you a headache is a good idea. It relieves | | | | peer reviews, rapid application development |
| some of the stress and gives your confidence a | | | | techniques, books on best practices. However, if |
| boost. The problem is the same as for tip #2 -- | | | | you do get stuck, maybe the best tip is simply to |
| you may not have the luxury of taking time off | | | | remember that you've been there before and |
| to go work on something else. Deadlines keep | | | | survived -- and you'll survive this time too. |