My question is similar to this one; but rather than focusing on how you attempt to solve your programming problem before asking, I want to know how you organise the technical questions that you come across, if at all. Often, I get engrossed in a programming problem, and find it easier to write a number of them down quickly off-line so that I can review them at a more convenient time. I'm curious to see how other people organise their questions before asking them.

Do you write your questions down first, queue them up, and move onto other things until you get chance to ask them, or do you fire up your Web browser and start asking as soon as your brain starts to hurt? Why do you think your method is effective?

Also, does this same trend apply on other communication channels you use, e.g. IRC and mailing lists?

For the record, I wrote this question down a couple of days ago :)

share|improve this question
    
better try to post programming based question. –  Warrior Jan 13 '09 at 9:19
    
"*detailed and specific *written clearly and simply *of interest to at least one other programmer somewhere" I think this post fits the bill. –  GordonG Jan 13 '09 at 10:49
1  
Belongs on meta. –  jjnguy Aug 31 '09 at 19:43
add comment

migrated from stackoverflow.com Aug 11 '10 at 1:03

This question came from our site for professional and enthusiast programmers.

2 Answers

Here's my question escalation process by category:

Problem in my project

  1. Experiment with code
  2. Google for an answer
  3. Google custom search for an answer depending upon if it's T-SQL, SSIS, C#, or VB.NET
  4. Ask one or two of my senior team members what they think about the problem either at their desk or in my office
  5. Pound salt at 1am in the morning until I find a 80% solution

Problem in a team member's project

  1. Review the problem with the team member either at their desk or in my office
  2. Call over one of my senior team members for a third opinion
  3. If the problem isn't critical for delivering against the business need in the short run, then we create a future project for the team member; if they don't resolve it on their own by the time it is a critical issue, then it becomes a Problem in my project
  4. If the problem is critical, then the responsible team member posts the problem in the approriate forum (a vendor's support line if it is a critical vendor-specific application problem, C# / VB.NET / T-SQL go to StackOverflow, Business Object to BOB, etc.)

Problem in another department's project

  1. If it's someone in a non-IT department, then we're usually their method for solving a technical problem
  2. If it's an IT department, then we follow Problem in a team member's project for step 1 and 2. Failing that, we direct the person to another department lead
share|improve this answer
add comment

My vote would be on "organise them first".

I often find that if invest enough effort in formulating my problem in an independent form (detached from my project), I often end up either solving it myself or finding that such a problem has already been discussed and solved elsewhere.

It is usually the process of coming up with a SSCCE version of the problem that I eventually declutter my thought process and break down the problem into a size that my mind can cope with.

If by then I still can't find a solution, I'll post the question. It should by then be in a form that the solution would not only benefit me but hopefully others as well.

share|improve this answer
add comment

You must log in to answer this question.