|
Brad, the first thing you have to know is what your code is supposed to do. I mean that quite seriously; it has to click in you mind, whether it's from imposed requirements or from your own devising. You then devise a way to do that. Along the way you encounter new things that you must conquer, so you refer to literature and to the forums, whatever is necessary for you to gain that knowledge. Then you produce it. Then it doesn't work. Part of that "doesn't work" is that you didn't implement it correctly. Those errors can be of many kinds (syntax, fuzzy thinking, etc.), but sometimes they reflect a lack of thought in the beginning that is now going to require even more thought in the correction.
You may easily think, "it doesn't work." It's not quite as easy to think, "it doesn't work because the presentation line wraps, but the content doesn't." You have to identify WHAT the failure is, how it manifests itself. Then you have to determine WHY. Information is crucial; it is the key. If your program is not producing enough information in its normal operation, then you have to make it produce more or you have to use a tool that can peep inside and gather that additional information. Until you learn to do that, your corrective efforts are going to take much longer than the production effort.
This post is not meant to be derogatory, but explanatory. I think that you are ready to move on to more mature code production, so you need to think seriously about incorporating these quite-normal approaches.
|