6 ms·

Tangential to the main point: The OP just learned a valuable lesson in what computers actually do. The single char oops is usually programmers' first insight i

Tangential to the main point: The OP just learned a valuable lesson in what computers actually do. The single char oops is usually programmers' first insight into what it really means when we say "computers do exactly what they are told nothing more or less". This is one of those things we all have had frustrate us to no end. Similar mistakes abound, and are one of the those things that cause a lot of people to give up on the programming thing all together. Here's a real kicker about it: they don't stop with experience, we just get better at noticing them faster. For example about 2 years ago -- 5 years into a programming career and 12 years into programming in general, I had this code give me trouble: // C Code: if (test_fails) do_crashy_thing(); So I decided to throw a quick printf in there (the situation was such that learning the debugging tools available to me would take a couple weeks, so printf was my quick solution here). I should note that I hade been working heavily in python for the preceding 3 months. My code looked like this now: // C Code: if (test_fails) log("info about test"); do_crashy_thing(); Which caused my code to crash every time instead of sometimes. C coders will know that multi-statement conditionals need to be wrapped in { } but single statement ones don't. Further python if statements are indent scoped. The recent python work sort of made me blind to the problem in the code. After 3 days of WTFing, talking to the rubber duck, and so on, I called over a colleague and he pointed out the mistake in something like 40 seconds. A younger me would have been embarrased, but this just happens in programming. My point is: these things happen, and I'm glad to see a blog post about this, without the demoralization that normally comes with it. I think it should be more openly discussed in tutorials and other newb oriented posts. A few tips for anyone who is experiencing this sort of thing and not sure what to do: Get a rubber duck (or whatever) and start employing the rubber-duck debugging technique: http://en.wikipedia.org/wiki/Rubber_duck_debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging it really helps! Be willing to include colleagues early and often. Experienced programmers understand and won't think less of you. Doubly so if you are new. (The will tease you a bit about it, but in that shared experienced bonding way, not in the "mock the outsider" way). Realize that as you are chasing the bug by getting down and dirty with other bits of the program, you aren't wasting time, you are most likely fixing other bugs that would have otherwise just manifested later anyway.

jebblue 15y ago
Thanks for sharing that example. It bit me in the past too. When I harp to colleagues "use braces always" and they say "it's a style thing" ... arrrgh!! No, it's an engineering thing. In the early 1990's half of the country went without phone service for I think it was several hours due to a rare case statement that ended up running, he forgot a break, code that wasn't supposed to, ran. Crash.
kcurtin 15y ago
Are there any tell tale signs that help you notice these types of bugs faster? I am learning Ruby on Rails but I assume there is some type of continuity with how this rears its head between languages. I will definitely experiment with the tips posted above - I am learning Github which could be useful for this I think, but do you recommend any simple tools for showing someone who is remote your code? The issue with copy/pasting is figuring out which code is relevant to show someone. Thanks for your insightful comment.
- kelnos 15y ago
  If you use git, that can definitely help you. The trick is in making small, targeted changes that do one logical 'thing', and then committing that. Don't be afraid to make tiny commits -- often I'll make a series of 1-liners if they aren't strictly related. Commits are very cheap in git, so don't worry about making "too many". Then when you run into a problem, you can easily use "git bisect" to figure out which commit caused the problem, and if you've kept to small commits, you should hopefully be able to figure out the offending line(s) of code pretty quickly. But beyond this, I think the early sign is your gut says, "it should be so simple but I can't figure out what's wrong". Listen to your instinct -- it's probably right! Don't spend another 2 hours poking at it. That's a good time to either step away for a bit or ask someone else to look over your shoulder for a bit while you try to explain to them what's going on.
- mrud 15y ago
  For me a big tell is if it should work and you have no clue why it doesn't or why it really behaves strangely/unexpected. For showing code to others in general i really like pastebins. http://paste.pocoo.org/ http://paste.pocoo.org/ supports "multiple files" which means you can upload multiple distributed snippets at once. http://jsfiddle.net/ http://jsfiddle.net/ is really great for javascript/html and helps others to change/modify the stuff. I often try to simplify the example (if the persons i am showing it to are not working in the same team as i am) to make it clear what the problem is and make the problem more accessible. This simplification often helps me to understand and solve the problem.

jebblue 15y ago

Thanks for sharing that example. It bit me in the past too. When I harp to colleagues "use braces always" and they say "it's a style thing" ... arrrgh!! No, it's an engineering thing. In the early 1990's half of the country went without phone service for I think it was several hours due to a rare case statement that ended up running, he forgot a break, code that wasn't supposed to, ran. Crash.

kcurtin 15y ago

Are there any tell tale signs that help you notice these types of bugs faster? I am learning Ruby on Rails but I assume there is some type of continuity with how this rears its head between languages. I will definitely experiment with the tips posted above - I am learning Github which could be useful for this I think, but do you recommend any simple tools for showing someone who is remote your code? The issue with copy/pasting is figuring out which code is relevant to show someone. Thanks for your insightful comment.

kelnos 15y ago
If you use git, that can definitely help you. The trick is in making small, targeted changes that do one logical 'thing', and then committing that. Don't be afraid to make tiny commits -- often I'll make a series of 1-liners if they aren't strictly related. Commits are very cheap in git, so don't worry about making "too many". Then when you run into a problem, you can easily use "git bisect" to figure out which commit caused the problem, and if you've kept to small commits, you should hopefully be able to figure out the offending line(s) of code pretty quickly. But beyond this, I think the early sign is your gut says, "it should be so simple but I can't figure out what's wrong". Listen to your instinct -- it's probably right! Don't spend another 2 hours poking at it. That's a good time to either step away for a bit or ask someone else to look over your shoulder for a bit while you try to explain to them what's going on.
mrud 15y ago
For me a big tell is if it should work and you have no clue why it doesn't or why it really behaves strangely/unexpected. For showing code to others in general i really like pastebins. http://paste.pocoo.org/ http://paste.pocoo.org/ supports "multiple files" which means you can upload multiple distributed snippets at once. http://jsfiddle.net/ http://jsfiddle.net/ is really great for javascript/html and helps others to change/modify the stuff. I often try to simplify the example (if the persons i am showing it to are not working in the same team as i am) to make it clear what the problem is and make the problem more accessible. This simplification often helps me to understand and solve the problem.