Motivated by a recent question from one of my department’s academic counselors, I’ve decided to start a small blog series with tips, tricks, or general advice for undergraduate students in computer science. While some of these may be useful elsewhere, I can’t promise that these will be good ideas when applied in other fields.
Ideally, these will be very concrete things that you can do to improve your studying, troubleshooting, or thinking skills. I’ll try to keep them specific and concrete—unfortunately, philosophizing too hard is a known occupational hazard in my line of work, so you may occasionally see some more abstract posts, but I’ll do my best to keep things grounded.
Without further ado, here’s our first tip of the series:
Why? First off, when you’re describing problems to other people “it doesn’t work” is possibly one of the most useless things you can say.
Suppose you gave your friend your apartment key and asked them to check on your cat while you’re out of town for the week. While you’re on the road, you check your phone, and see that you got a text from them half an hour ago that says:
Hey, I tried to open the door, but the key doesn’t work.
What are you supposed to do with this? Did they try the main lock or the deadbolt? Did the key turn but the door didn’t unlock? Did it not even go in the lock? Now you need to message them back, ask what happened, where they are, etc. etc. Imagine instead if the text said:
Hey, I can’t turn the key to the right on the deadbolt.
This message is pretty much the same length as the previous one, but now you have some information to work with! Maybe you don’t use the deadbolt because it’s sticky. Maybe you don’t have a deadbolt on your door, which means your friend somehow wound up at the wrong address. Maybe your deadbolt is a really weird model and you can only turn the key left on it. Whatever it is, you’re in a much better position to help them than when they just tell you the key “didn’t work”.
If it’s all about information, why do I say to avoid this when you’re describing a problem to yourself? Surely you have all the information that you have access to when you’re troubleshooting something?
It turns out that how we frame problems in our mind is very important to how we end up trying to think about them and, ultimately, trying to solve them. For example, if you believe a problem in your code is due to a compiler bug, you’re much less likely to notice a misplaced semicolon in your own code. If you think that a bug is coming from your loop indexing, you’re not going to easily notice that the return value from a library you’re using is wrong.
When you tell yourself “X doesn’t work,” what are you framing the problem as? It’s not a problem with your code, and it’s not a problem with your library, and it’s not a problem with your editor…in fact, you’re framing it as a problem that you can’t solve at all! Because surely, if you had some idea of what was wrong or how to fix it, that’s how you would have described it in your head, right?
The interesting thing is, if you force yourself to describe the problem in more detail, you’ll often find that you do have some ideas about what might be going wrong. This is why rubber duck debugging works: by forcing yourself to describe the problem in detail, you’re forcing yourself to describe the problem in some level of detail, which naturally gives you some insight into what might be going wrong, and then the other parts of your brain kick in and start thinking about what might be happening when you see these sorts of things, and you’re off to the debugging races.
So dodge the problem in the first place. Never tell yourself that something “isn’t working” and leave it at that.
What to do instead #
I find that “don’t do X” type advice is often not very useful without some sort of corresponding “try Y instead of X,” so here’s my opinion on what you should say instead:
When describing a problem to yourself, you should think about what you did (e.g. I tried to hit the compiler button in IDEA) and what happened in response (e.g. the IDE spat a massive error at me about some missing class). This doesn’t require additional work on your part since you don’t have to do anything extra: you just have to think a little to describe something you’ve already seen happen. As an added bonus, just this little bit of thought is often enough to get you started on working towards a solution!
If you’re going to ask someone else to help you, there’s a lot more to think about, since you have to worry about what everyone else knows, what you have to tell them, and so on. Unfortunately, all of that information is well outside the scope of a “quick” post, but if you’re interested, you can look at articles like ESR’s Guide to asking questions to get an idea of what you should be thinking about.