Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Several times after posting over at Stack Overflow, I have found that the problem I have is somewhat specific, and may have issues rooted elsewhere in my code. These are very difficult to solve with a question, and I often end up getting poor or irrelevant answers.
When a problem is just too localized or to complex for Stack Overflow to be any use, what should I be doing to break down the problem so it can be solved? How can I approach peers or user groups about problems like these?
So to start off with, see Wikipedia:
Problems that can be solved in theory (e.g., given infinite time), but which in practice take too long for their solutions to be useful, are known as intractable problems.
Your problems may be many things, but they are probably not intractable. So let's attack the heart of the issue:
How do you break down problems to a level that others can assist with?
The obvious answer is debugging. A problem occurs when your program does something you don't expect. So, at every step, you want to make sure that reality is congruent with your expectations. When you reach a point where what's happening is not what you expect, then you've found your issue.
People often post asking for help for what they "think" is wrong. Maybe they googled the error and tried implementing the solution in the first result. Maybe their rubber ducky told them. Frankly, what you "think" is usually worthless. To quote Richard Feynman:
It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong.
So first figure out what's wrong!
From there, it's simply about isolating the inputs and outputs. People don't need to understand your whole program - they simply need to see what's coming in, and what's supposed to come out. You should always describe the source of what is coming in, because sometimes what you think is going in is not what's really going in.
At that point, the problem can usually be solved. Some SO guru will see what's up, perhaps ask you to do something, and you'll accept their answer and say "thanks a lot!" or something like that.
Remember, find the point where expectations and reality differ. Write the basic case that causes this. Implement the solution. QED.
The problem I have is somewhat specific, and may have issues rooted elsewhere in my code. It seems to me you are unable to understand the problem in first place. This situation mainly arise when we expect an error to occur because of one reason and if that reason is not the source for error, we jump to the conclusion that it's bit overwhelming problem and cannot be explained in words.
To avoid such things, i would suggest you to keep your mind open to all the errors that can happen within a code and try them one by one. Identifying the problem is a major concern which can only be done on your end. You should give some time to understand debugging and tracing fundamentals because if they are learnt you won't have any problem which is unreachable or out of words.
And once you have the problem in hands, I am sure SO is sufficient enough to solve ANY problem in coding. Cheers :-)
I believe you are not investing enough time in debugging and moving around the code you build and quickly jumping into a conclusion that its not working due to MethodA. As an SO user is unaware of what the other things are the only way is to infer from the details/code you have provided which could be wrong and at times misleading.
First you need to be sure as to what is causing the problem even in case you realise it latter update your question with the relevant facts. Jon skeet has mentioned few guidelines on how to go about for a question
Hope this helps and you get better results from SO, avoid the urge to immediately ask it and take some time on your own.(this is how all those SO veterans have learned)
Comprehension
the fastest route is comprehension. that's a skill you will need, and it develops with experience.
rather than "help! i don't understand my program/problem", work through it.
programming is really quite simple. most things just resolve to true or false. the number of large problems which cannot be simplfied to those that can be further simplified is very low (in programming).
write your program to detect its mistakes (and immediately correct the issues). ideally, this would be done as you go. simplify your program - not in functionality, but in its interactions; reduce or localize the complexity of your classes, functions, etc..
i write programs as though i am more or less an idiot - my programs are throughly defensive and simplified. this helps detect issues and serves as documentation. the end result has very few bugs because the problems are localized to the callsite, and more importantly they are detected very early on.
so now it's code review time for you: start with the problematic areas and add a bunch of sanity checks (e.g. assertions), then write unit tests - fixing as you go. then you learn what goes wrong and why it goes wrong, and you will understand the problems you face and how to approach them easily (programmer errors have a way of repeating themselves).
leaving you with a quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan
