“Damn! This solution just won’t work! I have tried everything and all I get is a bunch of mush! Stupid programming I hate it!” Does this sound like you? Do you feel like one of those people on TV at the beginning of some paid television commercial? Many times the newbie and the expert alike finds themselves in the situation where a project just seems to stall. As human beings, we then go into a form of panic mode where we throw everything we can at the problem hoping something will stick. But does this really get the problem solved any quicker? How might we solve the situation when we realize we are in this panic mode and deadlines are looming? We explore the issue in this entry of the Programming Underground!
The process of throwing everything including the kitchen sink at a problem is typically known as brute force development. I personally call it “take a break time”. Many times on the board we get individuals who state a problem and in a paniced tone are asking for immediate help. This panic is usually caused by some kind of looming deadline, a need for sleep, or outright frustration at wanting to get this part of the project done and move onto more interesting things. We then proceed in providing a few solutions or a few “have you tried this” scenarios only to receive replies like “I tried that and this and that… and none of it is working! What am I going to do!!!!!” Notice the extra exclamation points that are a clear indicator of the panic and or frustration.
So how do we address the problem? First we must realize that we are in a panic. This is typically the hardest thing to realize. If you find yourself saying “Let me change this code to this… I am not sure what it does or if it will even work, but it is worth a shot.” This situation usually happens after we had been working on the project for a few hours straight now and the deadline is in little as a few hours. But once realized, we can move onto the solutions to fix this and give you a much better shot at fixing the problem and making your deadline. Here are some tips to help you out when in a panic and avoid the brute force programming tactics…
1) Take a break. What? Are you nuts Martyr2? Didn’t I mention that the deadline is in just a few hours? I can’t afford to take a break! And my answer to you is “Yes you can.” Think about it for a minute, would you rather be frustrated and not get anything done for 2 hours or take a 15 minute break and come up with the solution in 45 minutes? Some of my best solutions have come when I realized that I had been working too long and too hard and that I take a quick break. Go have a drink, go do something for 15 that will completely get your mind off the problem. While you think that you are abandoning the problem, usually your mind will work on the problem in the background. Typically this causes Eureka! moments.
2) Take your hands off the keyboard and using a mouse only, scroll through the code, following it from the beginning. Don’t write any fixes. Just review the code and see if it makes readable sense by reading it out loud (so what if the neighbor is staring at you). This is where readability comes in handy. When reviewing, don’t fixate right on the problem line, but the environment it is occurring in. About 90% of the time the line you are looking at isn’t a direct problem but how a variable or object might be setup before the line is reached is. Think about the current state of all objects at the time the line is encountered. Can’t add an entry to your queue? Think about the queue itself. Does it exist? What situations may cause it not to exist? What safeguards have you put in place? No safeguards? Could you then be running in some kind of error state? Test it! That is why the debuggers are there and allow you to pause on a specific line.
3) Break out the good old paper and pencil. Write down the values of variables as the code is executed. Write down assumptions being made at the time of the problem and then check to see if those assumptions are indeed happening. A lot of errors are based around assumptions and you assume a value is being set to the correct value when in fact it is not.
4) Write out a list of what you have left to do and how much time you have to do them. Always attack the harder stuff first because then it will tell you how much time you will have left for the little stuff. And if you turn in an incomplete project, you want to turn it in with the complex stuff done and the little stuff that may not matter as much unfinished. Most instructors will just mark you off a few points for the little stuff while marking you off severely if the main goal of the project is not finished.
5) Lastly, always start a project early and work hard on it from the very beginning. Do it correctly and you can avoid most panic situations to begin with. This will also give you the time to hit your problem areas and ask questions on boards just like DIC. As helpers, we like to see someone say “My project is due in two weeks, but I have this problem” than “I have this problem and my project is due in 2 hours!” In short, manage your time properly and don’t ever procrastinate. Procrastination will kill you in programming because you can know the entire solution and still need a substantial amount of time to just write it out.
When in a panic and seeking help here on DIC, there are also some great tips that can help you get faster and better service.
1) Ask a full and complete question. Many times people are in a panic and hurt themselves by writing only a few words as their question, providing us no details of what is going on. This wastes time because we then have to ask for more info rather than simply answering.
2) Provide the problem code and any code that interacts with the problem. Code samples are great descriptions for problems. It even tells us what the true problem is even if it is not what you think it is. In short the code don’t lie.
3) Error messages. If you get them, show them. Everyone gets an error message from time to time, so don’t feel ashamed to let the error messages fly. Along with the code they can tell us where the problem in your code is, even if you don’t understand them yourself. If the error message has a line number, tell us what line it refers to and hopefully that line is in your example code.
4) Tell us of any assumptions you are making about the code. Your assumptions might just be wrong if the code doesn’t agree with it.
5) Lastly, use code tags. Just surround your code snippet like this… :code:
Brute force programming, because of a panic, to get something done will almost always cost you more time than sitting back a second and thinking about the problem. It can also lead to sloppy “rigged” code that will just break later and cause you more headaches. If you solve it right the first time, things will get much easier later and more streamlined…. typically leading to faster development down the road.
Once you do hammer in a solution, you may not even know why you did it. But by that time you don’t care… “as long as it works”. The problem is that if you don’t understand why it works, you may find it doesn’t work because it causes problems down the road.
I brought up this entry for one important reason. Many of the newbies, and even some seasoned programmers, come on the board and ask their questions, listen to the suggestions and respond with a small tweak to a line of code that addresses a symptom of the problem and not the problem. Just like an illness, it is better to understand what is causing the symptoms and treat the illness, not just the symptoms because the illness will just rear its ugly head later. Feel free to ask us what a particular change we suggested does if you don’t understand why we did it. Always know your code.
Procrastination leads to panic which leads to brute force tactics to finish which leads to bugs which leads to more panic etc etc. Break the cycle, be smart. Plan ahead, take your breaks from the problem, when seeking help do it right, and never pound the code into the solution.
I hope this helps you out in the future when you find yourself in a jam and have a deadline looming. It will be all ok! DIC has you covered.
Thanks for reading! 🙂
