When you’re stuck on a programming problem for a while (everyone has their own time threshold), it’s customary to look for a hint. If you’re working on a competitive programming problem from a past contest, they’re easy to find. Problems on uHunt are categorized by algorithm, so that’s a big hint already. Popular problems often have editorials (I have written a few myself) or even complete source code in multiple programming languages. On the other hand, if your problem has to do with a programming language or tool rather than a puzzle, Stack Overflow is the standard resource.
But what if your problem is more general than a programming puzzle or language quirk? What if you have the type of question that gets closed on Stack Overflow? In other words, what if you’re looking for advice.
Generic Answers to General Questions
Advice questions are often very general, which makes it a challenge to write a useful answer. For example, consider the various incarnations on Quora of the How do I get better at competitive programming? question, which inevitably attracts answers that boil down to “practice more.”
In contrast, targeted and specific questions tend to get a small number of targeted answers. If someone wants to know how to approach UVa 514: Rails, you can advise them to use a stack. If they need more details, you can elaborate on exactly how the algorithm should work. You can tell them how to solve this particular problem. If you’re not familiar with the problem, then you just don’t answer the question.
So we have general questions that tend to attract generic answers, and targeted questions whose answers tend to be more specific. And while a specific answer can be helpful in learning how to solve a particular problem, what you really want to know is how to apply the lessons from that problem to problems in the future. And that’s where the role of the advice provider becomes more difficult. It’s a lot easier to tell someone how to solve a specific problem than to explain a process for coming up with a solution on their own. There’s nothing surprising about this, especially for computer programmers. Even a computer can be instructed how to solve a specific problem, but we don’t expect computers to solve general problems.
But that’s not the whole reason why it’s difficult for providers of advice to come up with general problem-solving procedures that work for everyone. After all, human beings, unlike computers, can create original solutions. The primary reason is the following: Learning and productivity systems work best when they are highly customized to one person. If you’re the person asking for advice, then you’re the best person to customize it for your own purposes. Therefore, despite the wide variety of advice that is available, you ultimately need to construct your own system.
Listening to Advice vs. Taking it
There’s nothing wrong with asking for advice. A good academic or career adviser can give you very personalized advice. Then, if you want that person to keep giving you good advice, it’s best to do something with that advice and report back with your results. But no matter how personalized the advice someone gives you, it can’t match a system that you have customized yourself. You should consider the advice you get to be a starting point, which you then experiment with and adjust it to make it fit your personality and circumstances.
Online Advice
Another source of advice is online advice, like the article you’re currently reading. Advice from blogs and articles isn’t targeted directly at you. This means no one will be offended if you ignore it. However, if you’re going to read online advice, you eventually have to take action on it. Otherwise it’s just aimless web surfing. So the best way to use online advice is similar to how you should use one-on-one advice: try it out, experiment with it, and customize it for your own needs. This is true even though you won’t necessarily be reporting back with results and getting updates, as you would with one-on-one advice.
Online advice from Q&A sites like Quora and Stack Overflow has some things in common with personalized one-on-one advice. Although questions and answers are intended to benefit future visitors as well as the question asker, they are nevertheless posed by an individual, and therefore can be very specific. On Stack Overflow, they can’t even be anonymous, so you have no choice but to build a reputation as a good or bad question asker as well as a good or bad question answerer.
Rules for Asking Questions
For both in-person and online questions, there are a few rules that will make the experience more rewarding:
Rule #1: Do some research before asking a question
This is a somewhat controversial recommendation. On Quora, it is an official policy that users are encouraged to ask easy questions (otherwise known as let me Google that for you questions). On Stack Overflow, the policy is a bit different:
Asking a question on Stack Overflow is the absolute last thing you ever want to do. You want to avoid it at all costs. You want to think of it as a horrible shame that will forever haunt you and pass down from you to your descendants.
Although that may not technically be their official policy, it’s a widely-accepted cultural norm on that site. But regardless of your opinion of the Stack Overflow question asking process, you’re likely get more out of the answer if you do some preliminary research.
Rule #2: Make use of the answer if you get one, and report back if appropriate
If the question was worth asking, then it’s worth taking the time to evaluate the answer. And as in the scenario with the in-person adviser, people are more likely to be helpful in the future if it seems like their efforts are being put to use.
Rule #3: Customize the answer to your own circumstances
Even if the answer you get doesn’t solve your problem completely, it probably gets you closer to the solution. Spend some time with it to see what you can do with the new information.
The more general a question is, the more you need to customize the answer to meet your own needs. This comes up a lot on Quora, which is happy to host very general questions like How do I learn to code?. Some question askers like to ask general questions which they clarify with specific details, but since questions with similar meaning, this isn’t a good long-term solution.
Productivity Habits
Productivity is a common subject of online advice, and productivity habits can certainly help you get more done with less effort. But they are also very personal. For example, I mentioned in the linked article that I find it useful to record how much time I spend on various tasks. For some people, this will sound like a crazy idea. Why fill out a timecard unless someone is making you do it? Other people might like this data-driven approach, even if they might not want to have it imposed from above. But whatever your first reaction, you shouldn’t just take the advice at face value. If you like the idea, think through why it makes sense to you, and what you hope to get out of it. If you hate it, try to imagine why someone would think it’s a good idea. The point is to get beyond the specifics of the suggestion (record time spent on tasks using a time tracking app) and think about the underlying value. If you dislike what you see as excessive detail, maybe tracking at the level of Pomodori (25-minute increments) would work better.
Part of the reason to think in terms of productivity habits rather than productivity techniques is that habits are easier to turn into something that you own rather than someone else’s procedure that you’re just following. The trick is to adjust the habit to fit your work style without losing its benefits. In other words, find a balance between strictly following a set of rules, and being so flexible with a process that it becomes no different from an ad hoc approach.
Competitive Programming
Here’s area where it’s easy to find opposing advice: using competitive programming to learn algorithms and data structures. For some reason, the idea really bugs some people. If you decide that programming puzzles are a good use of your time, and you read online advice, you have to figure out how to approach these opposing opinions when you encounter them. Just as in the time tracking example, I wouldn’t recommend just ignoring the dissenting opinions. For example, common opinions of competitive programming include:
- It’s a waste of time that would better be spent working on programming projects that result in software that someone uses.
- It encourages bad coding habits that carry over into other work.
- Programming should be a cooperative activity, not a competitive one.
If the person writing these opinions has taken the time to justify them, then there may be some things you can learn from them, even if you don’t agree with their conclusions. Here are three possible responses to those three opinions that do more than just disagree with them:
- Some competitive programming practice, like working on problems that are too easy for you, might indeed not be the best use of your time. But you can also learn new things by solving puzzles on topics that you might not encounter in project work. Make sure you’re choosing appropriate problems to work on, and look for interesting puzzle topics.
- Programming style for a puzzle solution can be different from the conventions used on code that has to be maintained over time. However, some of the same guidelines that help prevent bugs in project work can also help when solving puzzles, especially difficult ones. Once you’re more experienced and need to adjust your style for maximum speed in a contest, just be aware that you shouldn’t carry over those practices to your project work.
- The ACM-ICPC is a programming competition that explicitly rewards cooperation among team members. In general, competition and teamwork aren’t mutually exclusive. On a software project team, competitive activities like video games and sports can be a way to improve team cohesion.
Personal Experience
Even professional advisers are influenced by their personal experience. If you hear advice that doesn’t seem to make sense for you, it could just be the result of someone’s unique experience. For example, consider a programmer who has reached a high level of technical expertise without ever participating in competitive programming or any programming activities other than working on projects. Because they have succeeded in this way, they make dismiss the competitive programming approach, perhaps giving some of the reasons listed above. Another factor may be that it takes significant practice to reach the top levels of competitive programming. Someone who has spent that practice time becoming a programming expert in some other way may have an incentive to downplay the benefits of an activity that they chose not to participate in.
The State of your Brain
Reading and experience are usually “compiled” at the time they happen, using the state of your brain at that time. — Paul Graham
Even if you find an adviser whose personal experience, circumstances, and philosophy match your own, they could be at a different stage of life from yours. Maybe they remember what it was like when they were in your position, but that’s hard to do unless they recorded their thoughts at the time.
One thing that’s particularly challenging to remember is how hard a subject is to learn. Once you get good at something, it’s easy to discount its difficulty level. You may know intellectually that it took a lot of effort to learn it, but you nevertheless have a gut feeling that it is easy, because it seems easy now. So if you are using advice from an expert on how to learn something in their area of expertise, you will have to fill in gaps.
And Finally, a Paradox
It is of course impossible to follow (or not follow) the imperative in the title of this post. So of course, what I mean is: Question the advice that you receive. There’s a lot of good advice out there, but none of it is exactly tailored to you. Don’t try to apply it without modification. Instead, work with it until you have molded it into your own customized learning and productivity system.
(Image credit: JD Hancock)