How to overcome the programmer's block ?

Question

How do you do when, during the development of your application, you can't decide yourself what to do next.

You have no problem technically speaking, you have no problem to write clean code BUT you have a problem to decide yourself on what to code now.

And you spend time thinking and thinking again on your design, in the car, in the shower, and you cannot write a single line of code... I think we call this "analysis paralysis".

I hate being in this state ! How can you avoid this ? How do you do to not fall in this state ?

I think this occurs when we are writting a big chunk of code with no visible improvement, but I'm not sure...

UPDATE

Like some of you said, this problem is also what we call the "programmer's block" (analogy with the writer's block). Doing some TDD doesn't help because I'm stuck, I can't decide myself what class to code, what methods to put inside (even a name of method). Though I admit that it helps to break a big chunk of code into smaller ones. Like Talesh said my head becomes full of "what-if".

Answer 1

I call this writers block. This can only be overcome with experience of knowing you have to start even if the start is not sexy. Normally you can either start by defining your common objects such as User, Product, etc or you can start in the database by modeling how you would like your data stored. Either place is a good place to start and often gets past this analysis paralysis as you call it.

But as you are starting this project, just make sure you have a semi-clear idea of what you want to accomplish. If you are not ready to start coding, start writing down your ideas and formulating the project on paper.

A physical form of your project is always the best start, either in code or on paper.

Answer 2

What do your customers want you to focus on ? What do your business analysts (if you have any) want to be done next ?

Answer 3

I don't think I'd call what you describe "analysis paralysis", which is more typically characterized by trying to make decisions about architecture and design, rather than what to code next.

What you describe is a common problem, too, which I'd more describe as "programmer's block" -- similar to writer's block -- and the solution I'd recommend is to code something. Anything. Throw all the possible features into a hat and draw one, roll dice, write a completely unrelated project, but start coding. Once you start writing code, it'll flow again.

Answer 4

I have a Post-It note on my monitor that simply reads, "Don't think; Just start"

There's always a better answer, but that's what refactoring is for. Write the simplest code that will complete your task right now, and refactor it tomorrow when the requirements change.

Answer 5

The best plan is to have an actual PLAN of action before you start coding. If you have a road map of what parts need to be built and in what order, it should not be as hard to move from step 1 to step 2, to step 3. If you just jump in without a good starting plan, you'll get some parts complete, and then get yourself jumbled up in the middle without a clear idea of where to go next or what to do.

Answer 6

How about writing some tests, that initially fail of course. Then you at least have a clear goal: write the code to pass the tests!

[ducks]

Answer 7

Oblique Strategies

Answer 8

I think "analysis paralysis" more applies to the fact that you spend way too much time coming up with obscure use cases and "what ifs" and you end up over-generalizing your design and never really get started.

I think your problem is that you need to get some momentum going on the project. A couple suggestions are:

• Try doing a little bit of research on Test Driven Development and start hammering out small bits at a time and testing them.
• Try getting the most exciting part built first ( provided it can be modularly implemented and integrated easily )

Make your project fun and you will see how the code flows.

Answer 9

write some tests

Answer 10

I think this occurs when we are writting a big chunk of code with no visible improvement, > but I'm not sure..

write some tests for the code that you are adding and make them pass. this will ground you in reality and provide some feedback to your thinking.

Answer 11

It's all too easy to say 'write some tests' but it's not very helpful and doesn't even attempt to answer the question - which would be reframed as 'which part of the application do you start writing tests for'?

Some options are (for tests or code, doesn't matter):

• Do the hardest bit (accepting you will almost certainly have to refactor it later)
• Do the easiest bit (probably ditto but less so)
• Do whichever bit will have the most return on investment of time spent
• Do the first bits (if the app is in any way linear)

Having said that. I believe a gestation process is a good thing for an application - nothing worse than diving in and writing code lots of before you have really thought out how to frame it. If you find yourself in this situation, there's always the option of writing out project documentation and the like - you'll be glad to get back to coding after that!

Answer 12

An anecdote, possibly useful

I got stuck at this point working on intranet web apps for my company. I'd dreamed up and coded a bunch of cool stuff - but what next?

Then we conducted a training course with our employees. As I reviewed some of the stuff I'd already deployed, I got a lot of "ooh, I didn't know about that!" and "could you add this? Could you add that?" Bingo: new ideas!

Moral: if you have users, talk to them. They probably have a wish list of features. And it's fun to code things that you know will be appreciated.

Answer 13

RE: Last edit made to the question.

Probably you need to read about YAGNI. Stop worrying about the what-ifs, read the big refactoring book, and start coding the funnest part of your project. I think you need to think modular with what you are building first because you are preoccupied with how its going to fit in.

If you have no GUI yet, write it as a command line module. You need to see something working, anything working, to get going. If you have to build it text only, but it shows something happening in the background, you will be off and running.

I feel like your cheerleader. "Code Slashene Code. YAYYY"

One more thing I just remembered.

• Pick some really small pieces, about five or so. eg: write sql to create x table etc.
• Put them in an excel sheet or google spreadsheets
• Mark the entire row green when you complete one
• After first two keep adding "tasks" and marking them green as you complete them.
• Rearrange as necessary, rinse and repeat.

Answer 14

If you are stuck between two equally valid approaches and you can't decide which one, search for the one that has the bigger documentation and support. Look for similar cases and see how other people did it.

Failing that, just throw a die =)

odd: solution A

even: Solution B

Answer 15

To get out of the rut, you need to start coding.

Start by defining everything - have some empty classes, placeholders etc. Basically, code up the framework.

Then start fleshing it out, piece by piece.

Once you have the framework, it's easy to see what bits are missing and incomplete and that acts as a guide for what to do next.

Answer 16

Create a prototype UI. It is an excuse to code and will help you break out of the block. Start really small. Getting an idea what you want your app to look like can get the creativity flowing again.

Answer 17

If you haven't already done so, create a structure chart (UML?) of the current design. The most important module should be the one at the top. If that doesn't seem to be the right one, select a module from the interior and (figuratively) give the tree a shake so that the new structure jumps out at you. I have done this with post-it notes, string and tape on a whiteboard, and it works wonders for getting started.

Answer 18

If you incur in this situation, it means that you don't have a clear vision of the world you are modeling with your code. This means that you have to discover it. In order to discover it, you have to tinker with it.

Therefore, I just code. Probably, it will be that I have to throw everything away in one week, but at least I learned something, and I can start afresh with new competence. This of course requires focus. If you are interrupted more often than not, you will not be able to follow the train of thoughts that leads to a deeper understanding.

Answer 19

A while ago, I answered to another stackoverflow question "Where is the dividing line between complete lack of planning and analysis paralysis?" which may help you.

Answer 20

How about doing some work on a pet project for a bit? Just get yourself in "the zone" and switch over to your project.. and then just code code code!

Answer 21

The way I tackle this is to imagine one "use case" of my code. It can be a user, another coder consuming your code, or a service.

Take what you think will be one example of how your code will be used, and stub it out, make it work for that one case. Paralysis can come from satisfying multiple use cases, but I find it's best to work on the common case and then start refactoring when you have more known use cases. The downside to this approach is that you may develop inefficient data structures or algorithms, but by imagining the usage, it helps better define exactly what you're trying to accomplish.

Answer 22

Do what writers do. Just write. Don't worry abuot structure, outcomes, correctness or anything but getting words (code) on the page. That's what I do. Planning is way overrated, in life as in code. That's what refactoring is for!

I can't remember who said this (Churchill?) and I'm paraphrasing, but somebody smart once said, "When you don't know what to do, do the work in front of you." If you know you're going to need to parse that file the mainframe guys ship over, just write it. Who cares if it's not optimal or where it fits in that crazy UML diagram. Even if you have to throw it all away, it's likely that you learned something. False starts are better than not starting at all.

Answer 23

I actually think I am the complete opposite of many posters.

Usually, if I am at an impasse I do something that is seemingly non-programming related. Take a walk, go to the bathroom, attend a meeting.

Usually I am so eager to think about something OTHER than the mundane task I am performing (especially meetings), I come up with some code to write.

That gets my creative juices flowing. Of course, I hate boredom.

Answer 24

Sigh! Code monkey's don't make decisions, a Project manager will tell you what to do.

By asking this question, you are also demonstrating why you need a project manager. Code monkey's cut code, they don't make decisions, or the system would never get finished... lol...