Here are some thoughts about ludum dare. Disclaimer: I might not be the most experienced game programmer or designer, but I have participated in multiple LDs and have learned quite a lot from it. So this are mostly thoughts for things that work for me or improved my workflow. though most of this thoughts are about ludum dare, some of them also strongly influenced how I work on my game projects now. sorry for the wall of text 
I think for ludum dare it is important to stay focused on the goal. For this you have to know what you will be doing, not in terms of tech but from a “game design” perspective. We always started our ludum dare jam by eating breakfast and brainstorming ideas. We don’t talk about how we will be implementing them, we just discuss how the ideas might play out in terms of game mechanics, artstyle etc. the ideas can be very simple or even silly. you can still refine your ideas. But be realistic when you chose your target. I might like the idea of implementing a 2d clone of portal, but I know that I won’t be able to pull something like this off during a ludum dare…
Don’t take the first idea that comes to your mind (if it’s your only idea, you might be stuck, so go for it). Though it might be a nice idea, you can bet that someone else has had the same idea. That does not have to be a bad thing, but it can be a nice thing to be unique. Last ludum dare (“You only get one”), my first idea was, that the player has a bow or crossbow but only one arrow. We then went on and found another idea, but it was funny to see, that there were multiple entries from other people, that did exactly this.
If you don’t have any idea for the theme, story, graphics style etc., but still want to participate, pick a game mechanic or a simple game (tic tac toe, flappy birds, tetris, poker, whatever, one of our entries is losely based on a popular board game) and try to execute that as nice as possible. You can’t force creativity but when you start working your brain starts working and more ideas can come up. You might find a cool twist to the game mechanic or find out how to link the theme to your game. Maybe it just ends up as an unoriginal clone, but it might not 
Split up your work in multiple steps. For my game, my plan was roughly like this: “Setup Box2d and factory for creating bodies” => “Setup controls for player body” => “Add scene/graphics” => “Add lighting” => “Add food” => “Add enemies” => “Add Music and SFX”. I started with the first step and when completed went on to the next. Sometimes you have to backtrack to clean things up, but really, you want to go forward.
It is about the game, not about the tech. While it can be fun or interesting to dabble around with tech, don’t let it go overboard. A nice architecture without a running game is not so nice in the end 
Reevaluate your ideas and tasks during your project. Is it too hard to implement? Will it be fun? Are there any problems? Be realistic and cut unnessary or hard to implement features. You can still add them later if you have time left (you won’t XD).
Use tools you know well and can handle. If you try something new (like I did with box2d and box2d lights this time), have a fallback plan, in case you fail. You don’t want to spend half of the time fighting with your dev environment. You want to make a game.
Be prepared. I have setup the git repository and the project before ludum dare started. When I knew what I wanted to do, I could just startup eclipse and start coding.
Know your schedule and set deadlines. It is important to know how much time you will have. If you don’t set deadlines, you will be tinkering in your code and lose focus. You can still stretch a deadline if it is to hard to meet, but try to be in time.
Don’t lose too much time for unimportant stuff. If there is a simple way of doing something and a cleaner one, that takes much longer to do, don’t bother with the complicated one. If you need something better you can still refactor it later, if you have the need for it. (Disclaimer: This does not mean “Write ugly code.” but “Don’t write unnessesary code”).
Take a break once in a while. I had more good ideas on the potty like I d’like to admit 
Mute communications: while it’s ok to have a look once in a while at what’s going on on the compo page / email / facebook / jgo, you should restrict yourself. try to work without distractions, then take a break and update your feeds, if you have to.
Most importantly: Have fun
If you notice that your initial idea is to hard, just scrap it und do something silly and simple. Or do a more simplified version. or stop if it is too much of a pressure for you. I had to abort my first ludum dare, because I got sick. it wasn’t fun working in this condition, so why bother.
one last thing that I find utterly important in programming in general is the ability to identify and break down problems. If you are stuck with a big mess and don’t know what to do, it is very likely that you don’t understand your problem well enough. Investigate what you are doing and find out what the factors are for your problems. You will often find that your main problem consists of multiple smaller problems. You can check those problems again and split it up further until you have a bunch of small problems that you can solve each on it’s own.
As a small example, let’s take the problem “I want to make an AI for my ludum dare game”. This are more or less my thoughts on what I did to identify the challenges of this task.
I want to have different behaviors, like finding food, chasing an enemy or evading
- Access information about the game world
[list]
[li]Access to the existing food entities
- Access to the existing cells
[/li]
- Information about the entity.
- Decide what the entities behavior is
[li]When to run away/evade?
- Who is the biggest/nearest threat?
- When to attack?
- Who to attack?
- Where is the nearest/best food?
[/li]
[/list]
I need to execute my ai routines
- access to entities
- execute behavior update
- execute behavior
[list]
[li]Find out applpied force (directional force based on target and behavior)
[list]
[li]Move towards target
- Move away from target
[/li]
- Control the entity (actions/velocity/position etc.).
[/list]
[/li]
[/list]
Conclusion: Now when I look at this list, I already have a much clearer picture of what needs to be done. But don’t start making lists all over the place. Decide on a design/architecture/whatever, start working towards your goal, and if you find any problems, just break em down 