Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?.

share|improve this question
2  
It's different for everyone. I used to know someone who wouldn't touch a keyboard for a long period of time, then he could knock a good solution out in no time. For me, I find TDD funnels my view into the correct solution quickest. No one can possibly tell you what will work for you. –  pdr Dec 2 '12 at 22:34
1  
Well, that's two techniques. If people listed enough techniques, different techniques would work for different people. –  GlenPeterson Dec 2 '12 at 22:37
2  
I'm afraid there is no finite number of programmers that can help you. Normally programmers understand the problem, and they just do that by... understanding it. There is a number of trivial methods to make sure you got it right, but it's hard to impossible to find one for you, given the fact they should be outright obvious. The kind of rush you describe seems... slightly insane? Have you tried practicing more, with real timed tests? Have you considered seeking psychological help for anxiety, or at least reading some self-help books about working under stressful conditions? –  ZJR Dec 2 '12 at 23:30
2  
@ZJR - Good suggestions to practice with timed tests and look into psychological sources of better performance under stress. Maybe I'm being negative here, but part of your comment reads like you think I either have no talent, or I have a clinical psychological problem. Ouch! –  GlenPeterson Dec 3 '12 at 13:33
1  
First find out what EXACTLY is required or expected. WHAT to solve is quite often harder than how to solve it requires more analysis and often reveals a different question altogether. –  minusSeven May 3 '13 at 15:00
show 1 more comment

3 Answers

...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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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 five 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. Collect and analyse information at the incident
  2. Predict incident behaviour
  3. Tabulate and keep track of resources
  4. Prepare available strategies to control the incident over time
  5. Apply appropriate strategy for the time
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.