How to Ask Questions About Programming

Hey, all!

I’ve been browsing CD a lot more lately, and I’ve noticed a lot of things that might be hurting people’s ability to answer questions regarding software. This is my guide (others may have a different process) to asking questions about software.

First up: Know what you are trying to accomplish
This will help you direct your question. I know for a fact that you are learning advanced PID control to use for pathplanning just because. Asking questions for a specific reason will make sure that you get the answers that you actually want.

Next: Context, Context, and More Context
This is an extremely important aspect of your question. We need to be able to know what it is you’re trying to accomplish and know what’s going wrong. Having a code example, a link to github, or something of that nature will do wonders to the people you are trying to get help from. If your code is generating errors, maybe include that as well so we can see what it is you’ve done wrong. Then we aren’t trying to solve some other part of your code that is actually working.

Also: Listen to the advice that people are giving you
This is a critical aspect of the process. A lot of times people might not just give you the answer on it’s own. Oftentimes (at least for me) people will include a sometimes lengthy explanation of their solution. Don’t just skip the lecture and paste the code into your project. Part of learning is actually learning (big surprise there). You aren’t going to learn anything by pressing ctrl+c then ctrl+v. In the end, you’re probably going to forgetting what the solution was and end up asking it again for a different iteration of the exact same thing.

Don’t forget: See if you already know/can find the answer on your own
One of the most difficult aspects of programming is that no solution will work every single time. You might get something that will work in a specific context, but not in another. The opposite applies here as well. Maybe whatever your doing is already applied somewhere else in your code and you just need to tweak it a tiny bit to work in the new environment. Another thing, and I know it’s super cheesy, but reading the docs might give you everything you need too. Try going to WPIlib’s documentation and searching for the task you are trying to accomplish. Chances are, a lot of people have done the same thing and there’s an overview of it on WPIlib’s site.

Penultimately: Don’t blame the person helping you if it doesn’t work
Sometimes when someone gives you a answer to a problem, it won’t work. Maybe part of the problem is they aren’t fully understanding the context of what you are trying to do, or it doesn’t really apply to whatever you are doing, but either way the people helping you are smart. Even if what they offer doesn’t work, you can still save that knowledge for future use. You never know what problems might occur in the future and maybe that misplaced advice could help!

Finally: Accept that the people helping you know more about the topic than you do
I know this is a pretty obvious thing, but It’s sad how many people will throw away someone’s input because they think they know more. Granted, it’s not nearly as bad an issue here, but it still needs saying. Just be humble even if you think some person is inferior to you. Honestly, you can think those things all you want as long as you don’t say them out loud. If you ask a question then claim to know more than whoever is helping you, they aren’t going to want to help you. Now or in the future. Just be a good decent human being.

Even if you are pretty good at asking for help, in my experience I’ve found that people who tend to somewhat follow these principles will end up getting the help they need and be able to have an actual learning experience so you don’t need to keep asking the same question over and over.

–Good luck this upcoming season!


Thanks for posting this. I respond to a lot of programming question posts, and I have some tips for things to do before you post, and things to include in your post. Many discussions spend a lot of time cycling on these points before they get down to the meat.

Before you post:

  • Check your status lights. Know what they mean.
  • Check your wiring. Exposed metal? Whiskers? Power connected to the right place? Is the problematic motor controller on the far end of the CAN bus? Are you using the correct port on the radio?
  • Check your logs.
    • Driver Station logs: Any loop overrun events? Any disconnections? Is the current draw what you expect?
    • Smart Dashboard / Shuffleboard: Add your key data just to check that it’s doing what you expect. Make a graph.
    • Riolog: Look for loop overruns, missing CAN devices, exceptions. Commands starting and ending when expected.
  • In your code:
    • Check requirements. Is your autonomous routine fighting your arcade drive?
    • Check all command execute and subsystem periodic methods. Are they doing what you want them to do and no more? Did someone sneak a long-running loop into one of them?
    • Did it ever work? What changed?

When you post:

  • Include a link to your source code. Github is good, but not the only game in town.
  • Include as much information as you can about what you tried, and what you observed. Include error messages, status lights, DS logs, graphs. Maybe include pictures of robot mechanisms and wiring. (Tip: Take photos when the robot is off. Status lights confuse your camera.)
  • Be clear about what you did, what you expected to happen, and what happened instead. I know you’re very frustrated by this point, but try to use clear technical language, not slang.

Help us to help you. Oh, and after you post, please follow up. We love to hear what happened.


Something to add for these two, include information on the things you have tried already, the documentation you’ve looked at, etc. This shows you have tried to solve the problem yourself and aren’t just looking for an “easy” answer, additionally it helps others see what paths you’ve gone down, which may reveal either a misunderstanding on your part (incorrect implementation, or looking at the wrong thing), or help you to not get the same info/recommendation you’ve already found, again.


A recent contribution has a few good suggestions and describes a critical method I use - get the failing code down to the minimum example. You’ll often see the answer at that point and if not, then ask your question. They make an excuse that it’s tricky and I agree it’s hard but you have to do it even if the minimum is many lines of code instead of the ideal one line of failing code. It’s most efficient and enlightening - better answers, faster, and really it’s less work and frustration for everyone.
Look at their Suggestions Within


The corollary of this is if you don’t understand some advice, ask questions. It can be tempting if you have several pieces of advice to only try the things you understand, but all too often it’s the ones that you don’t understand that are important.


Another debugging method instead of trying to reduce code to an MVCE is going backwards in time using Git to find where the error first appears and then look at the diffs of that commit to figure out the issue. If you’re familiar with git bisect, that process can be done pretty quickly; otherwise, you have to manually jump around your timeline (but the idea is the same regardless of the commands you use).


If your problem is with a crash (say a null pointer exception), include the stack trace.


I’m going to skip the detailed advice and instead offer a fundamental principle:

Put as much effort into asking your question as you expect to receive in your responses.


A little bit duplicative but an adjunct to all the great advice already posted:

Don’t ask a qualitative question for a quantitative problem.

example 1
Poor: I’m getting the wrong answer for a formula
Better: For this formula y = f(x) I’m expecting the value 200 and am only getting 100. What is happening?

example 2
Poor: My signal is noisy
Better: My sensor ___ signal averages .7 which is right but randomly jumps a lot between .6 and .8. Is this normal?
Best: Here’s a graph of my time series for sensor ___ and I think it’s noisier than usual. Is it normal?

example 3
Poor: Velocity for my shooter wheel isn’t what I set it to.
Better: I set 2000 but it oscillates +200 to +300 of the setting. My parameters are …
Best: Here’s a graph of the shooter velocity that should be at 2000. My parameters are …

1 Like

Today’s newsletter from Replit describes their History++ slider to go back through all your keystrokes. We use Replit for Java training.


Sometimes the only way to move forward is to go backwards. And Replit’s new and improved history tool allows you to do just that. Instead of taking snapshots through git, History++ captures every single change you make. There will never be a state you can’t get back to. To use History++, just click the clock in the top left of your workspace. See your creative bursts, your changes, and how you evolved your code all in a nifty slider bar UI.

1 Like

That’s definitely a nifty feature for practicing, though I still think the discreteness of Git commits is superior to the continuous nature of a slider in actual full code bases.

I have to agree here. At least for 1895, we prefer github for various reasons but one of the biggest is how easy and quick it is. On our software laptops (really old Dell laptops) we install git bash and install the git bash extension for VScode. That way just in VSC’s integrated terminal we can do all the repo stuff there. It makes for easier version control and it’s pretty good at live updates every time someone does anything on any branch. I don’t know if replit does the same thing (I don’t have any experience with it) but our (“our” being team Lambda Corps as a whole) github has all of the software we’ve made for ourselves (past seasons, scouting apps, our software mentor’s how to program robot tutorial, etc) dating back to somewhere around 2016-ish. It’s really helpful to be able to have existing examples of how to do just about anything. Most of the time when a software padawan will ask “how do I do this” the answer is most of the time “look at x season’s repo and see if you can find the answer”. It’s a great system.

1 Like

Edit: My plea to implement these tips is moved to implemetation.

I’l keep my question-could-be-improved example to complement

Answers only lay within the context of the question. Significant effort in troubleshooting here on CD is greatly expanding the context from the OP’s brief, misleading statement. A questioner should recognize that the answer often doesn’t lay near where the questioner has looked. Bugs in software are often nearly unrelated to the reported trouble. Erroneous results often are related to hardware configurations.

Today a question was posted

The answer which they posted themselves was they

replaced the limit switch and resistor with a jumper wire … and now it works

We started this compendium of tips in programming and this example shows programming robots involves a broad context of hardware. Questioner should have described the context within which the software was running.

[My guess is questioner repurposed a test board that they were playing with an RC circuit with the limit switch providing the on/off and decided to use the limit switch with resistor still attached to turn on/off a motor that was spinning the encoder. How this got into the encoder signal who knows.]


For emphasis I’ll add more example to this important step that’s been well stated often in this thread. If person with question is installing or copying something (programming in this thread but applicable elsewhere) state what instructions are being used that a helping answerer can view, state what steps have been accomplished, and state what step seems to be the problem and why the result doesn’t seem right.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.