How to avoid jumping to a solution when under pressure? [closed]

Question

When under a particularly strict programming deadline (like an hour), if I panic at all, my tendency is to jump into coding without a real plan and hope I figure it out as I go along. Given enough time, this can work, but in an interview it's been pretty unsuccessful, if not downright counter-productive. I'm not always comfortable sitting there thinking while the clock ticks away.

Is there a checklist or are there techniques to recognize when you understand the problem well enough to start coding? When is it most productive to think and design more vs. code some experiments and figure out the over-all design later?

Here is a list of techniques for taking a math test and another for taking an oral exam. Is there is a similar list of techniques for handling a programming problem under pressure?

ANSWERS: I think this is a valid answer: How To Solve It. I found that link as an answer to Steps to solve or approach towards a solution. There were also some really good tips at Is thinking out loud during an interview really the best strategy?. A great and concise argument for TDD is the first answer to TDD Writing code vs Figuring out the answer to a problem?.

Answer 1

I recall reading a study on how fire marshalls form a plan of action on arrival at the scene of a fire; the study observed (and condemned) them for coming up with an idea, then pursuing that first idea immediately. Due to the pressure of time, it was pretty much "this might work" followed by "ok, let's do that". The study noted that better, quicker, safer options were available, but they were not followed simply because the marshalls didn't think of them first.

If you want a structured approach to dealing with "fires" perhaps take a leaf out of their (new) book which prescribes several phases:

R.R.A.P.I.D.

1. Reaction - Mobilize resources to incident
2. Reconnaissance - Collect data about the situation
3. Appreciation - Choose a course of action based on best and worst case scenarios
4. Plan - develop a plan based on the course of action
5. Issue of Orders - Use the standard briefing format
6. Deployment - Execute and monitor

or in more general terms:

1. Wake everyone up and get them moving
2. Work out what's going on
3. Brainstorm solutions
4. Pick one and plan it
5. Tell everyone what their job is
6. Execute and monitor

Answer 2

I always start with understanding the requirements and looking for gaps in them that need answers.

Then I sketch (very roughly and on paper or a whiteboard) two or three possible solutions. Then I ask myself, "Is there anything else I need to know to implement any of these?"

Once I have an my initial questions (there are questions 100% of the time, if you have none, you haven't really looked at the requirement in depth.), I go back to the stakeholders to get my answers.

While I'm wating on their responses I consider my solutions and see if any are better than the others or would be better once I get the answers to the questions. For instance if the how soon do you need it questions is immediately, I might go for the one with the fastest development but leaving open a way to improve the design later. If they tell me performance is critical, then I look at the solutions and determine which one is more likely to perform better (these are guesses at this point, but informed ones generally). If a GUI is involved, I might make up a paper prototype of several differnt designs and get the stakeholders to look at them before I code anything (Usually they will see that they forgot to tell you about XYZ which is something that is central to the design!)

Once I get my answers I choose a rough design and then I make a list of all the things I will have to do to implement it. Then I start coding.

Answer 3

...my tendency is to jump into coding without a real plan and hope I figure it out as I go along.

I did this while at university. It became a real problem and would typically result in rewriting code. I began to address this by not writing code. I placed emphasis on thought about the problem. With enough practice, I instinctively reach for my thoughts rather than a keyboard.

...in an interview it's been pretty unsuccessful, if not downright counter-productive. I'm not always comfortable sitting there thinking while the clock ticks away.

Within an interview, there must be a reasoned, well thought out implementation to a solution and that does not always come easy. What you do not want to do is blurt out answers without thinking. If you know the answer, quickly give it. If you don't, rely on your thoughts to reason a solution. Always indicate when you do not know and demonstrate how you would go about finding a solution.

Is there a checklist or are there techniques to recognize when you understand the problem well enough to start coding?

I would discourage such because you may rely on it rigidly. Rather, ask yourself if you understand the problem well enough to start coding. How would you know? Because when you reason your approach and then examine it, given your present knowledge of the language, it will make sense. Always have a plan and approach. Also remember that code is never finished and code that doesn't evolved will die so expect to return to your code often.

When is it most productive to think and design more vs. code some experiments and figure out the over-all design later?

You will want to know the over-all design and give thought to it. Then you begin making the class structure and stubs. Then review it again. Does it make sense? Coding experiments is great way to demonstrate something works well and should be used but not to be relied on to fashion or shape the code you write.