Lately a lot of people have been asking me for help as they write C++ code. I’m usually happy and able to help. There are times, though, when I either cannot help, or choose not to help. I thought it might be helpful to explain some of these a little. It’s quite likely that other members of the community have a similar set of guidelines in their heads for when they do and don’t help people with code.

Warning: this is long. I think it's worth reading it all. You want a TL;DR? It’s this: if you want free mentoring and consulting from successful people, you can have it! All you need to do is ask. But if you expect your helpers to do most of the work in helping you, and to take instruction and direction from you, you’re going to get a lot less help than if you know how to be helped effectively.

The first choice is where and how you ask. People often email me, message me on LinkedIn, DM me on Twitter, DM me on the #include <C++> Discord, and so on hoping to get personalized, instant, one-on-one help from me. That’s not a good use of my time. I prefer to help in places where others will see the question and the answer. That helps more people. It also enables more people to help – so it produces better advice as well as helping those people learn and grow. Often, I learn from the times when other people chime in. So I encourage you to post on StackOverflow (if you have the sort of just-one-question, just-one-right-answer problem that fits there), or on the #include <C++> Discord, or some other public place where a number of people can see the question and the answer over time.

The rest of the issues have to do with how much work the person expects me to do, or how much they save me. Think about how you ask the very first thing you ask. Compare “here is a zip of all the files in my project can you tell me what’s wrong with it?” to “here is a link to an online compiler (Godbolt, wandbox, etc) showing a compiler error on line 43 that I don’t understand. Can you tell me how to fix that error?” Expecting someone to install things, trawl through multiple files, guess your question, and then solve your problem and explain it all to you is really too much. At least tell people what your problem is! Often people ask for help saying something like “it’s not working” or “what’s wrong with this?” and I don’t even know if it’s a compiler error or a runtime error or running fine but calculating the wrong answer. So before you post on the discord, for example, try to have a single crisp question, not just “help, it’s not working.”

• Show us your code, and your errors. And not as screenshots! You can copy the code into an online compiler like Godbolt or Wandbox, or if it’s less than 20 lines or so, paste it into the chat window – but please learn how to format it as code when you do that. Copy and paste the errors as text. That makes them much easier to read, and lets us copy and paste parts of them while explaining things to you. If you can’t show your real code because of how big it is or because it’s work-related, create a tiny example that shows the same problem and show us that. Stack Overflow has some tips on how to do that.  Whatever you do, do not free-type some code into the chat window that you think is the same as your problem, and then whenever people point out missing semi colons or undeclared variables, reply “oh yeah, that’s not really my code it’s just something I typed to give you the general idea.” Compilers (and runtimes) are picky and asking for help with something that’s vaguely like your real code (but not really) is pointless.

Now let’s assume you manage to get a conversation going with someone who is trying to help you. They solved that compiler error, for example, but now you have another one. As part of this process, I often make suggestions to people that they reject. I think they believe the suggestions are to make things easier for themselves in the long run, because they say things like “I can do that once it’s working.” I then have to spend a lot of effort explaining that I want them to do these things so that I can help them get it working. These suggestions include:

• Write good variable (and function) names. If your variables are all called i, n, c, r, s, and so on – I don’t know what they represent. If I ask you to change those to words like next, rate, total, and so on, or to words you think of yourself, that’s because I can’t understand your code (I don’t know the problem you’re trying to solve) without some help. Good names aren’t a someday thing that you paint over working code once it’s all good. They are how you make code other people can read. And you’re asking me to read this code. Make it readable.
• Use a debugger. When I ask “have you looked in the debugger to see the value of a before the loop?” an answer of “I don’t know how to use the debugger and I don’t have time to learn that today” is a great way to end our conversation. Real programmers use the debugger. We don’t have some magical compiler-simulator in our heads that can read code and tell you if it compiles or not, and we don’t have a magical runtime-simulator either. Sure, maybe I can tell at a glance that a is 0 before the loop and that’s why it’s not working, but in that case I would tell you so. It’s more likely that I want you to quickly check and see if it’s 0 or not. When you refuse to debug, you’re making it so much harder to help you. You need to learn to use whatever debugger is available to you, and you will probably save enough time today to make up for the time it takes to learn it.
• Add some tests. You don’t have to go learn a whole unit testing framework. But if you’re writing a function to do whatever, work out by hand what it does for simple values, and write a test harness that passes it those simple values. Then you can debug the test harness and see what the function returns and confirm whether or not it works for simple values. Whether you’re reversing a string in place, calculating the Fibonacci sequence, calculating sums of things, whatever, you should be able to think up simple test cases and test your code with them. And eventually, you should be writing tests as you write your code. It’s a good habit you can build now.
• Break up big things. You don’t have to embrace full OO or write functional programs, but don’t give me 1000 lines of code and ask me to load it into my head. Write some functions. Heck, throw in some comments and some blank lines. Show the structure of your code so it’s not a wall of text.

• Try the substitutions people tell you to try. A lot of times, people who are having a hard time don’t want to learn a new thing. I run into that situation all the time myself. I’m already frustrated and I’ve spent longer than I meant to and I can’t understand any of it, I don’t want you to tell me to go learn yet another thing right now. I have gained some wisdom over the years though, and it includes this: sometimes jettisoning all that half-understood not-really-working mess and doing something simpler is the best way forward. If someone tells you that vector would be better here, and offers you a few lines of code to use, just digging in your heels and refusing to try it isn’t going to lead you into learning. If you’ve got a problem because you’re trying to manage memory yourself by hand but you forgot about copying and so on, then using a smart pointer, or dropping the pointers altogether and using an object on the stack, is going to make a whole pile of work just fall away. The person advising you to try this knows how much effort it will save. You don’t, that’s why you came for help. It’s really frustrating to see a beginner insist on doing something the hard way (for no benefit), do it wrong, and refuse to accept any help other than “here is the precise and exact code to do that thing the hard way.” I don’t want to do things the hard way any more: why would I type out all the code for you?
• Try things that don’t matter to you, if the person who is helping you tells you that your code is harder to read the way you have it. Things like initializing member variables in a constructor with the : syntax, not between the braces, or adding some using statements – these may not matter to you, but making things too hard for a busy helper may mean that helper is too busy to help today. Or ever. I don’t want to teach you bad habits, I don’t want to teach you to “pretty things up” only once it’s working, and I don’t want to exhaust myself reading difficult code to spare you the trouble of doing the right thing. Also, when a person asks for advice but never takes any of it because they’re sure it’s not actually relevant to their problem, eventually the advice-giver will stop giving it. It’s pointless.
• Write your own code. If I tell you “the problem is that you’re not initializing x” don’t ask me to edit your code for you or paste in the new version of the function or whatever. You need to understand what you’re doing and that comes from writing the code yourself. If you don’t understand how to fix a problem that someone has told you about, ask them “how do I fix that?” If you can’t understand their answer, say “I don’t know what [whatever] is, can you explain it or show me?” Don’t just ask “what would that line of code look like?” That feels like you’re asking me to even do the typing for you.
• Work with whoever is talking to you. Maybe when you first ask, one person has a couple of thoughts, and those are good, but while you’re changing your code to see if that works, someone else chimes in. That’s great. It’s a group chat. Don’t tell them that you’re working with the first person or anything like that to reject their help. Consider all the suggestions you get. If you’re talking to someone and then they stop, that’s cool too. Many people pop into chat for 5 or 10 minutes waiting for a conference call to start, or while they’re eating lunch, and don’t stay long. People get called away from their keyboards. Don’t start pinging the person trying to bring them back or ask if they have any more thoughts or saying you’re still stuck. You can tell the room or channel as a whole that you’re still stuck. Maybe someone else will have some ideas. Your problem may end up solved over an hour or so with three different people. That’s a win!

I know, that’s a lot of advice. Thing is, you can get a lot of help from strangers on the internet, if you ask the right way. If you ask the wrong way, most people will just shrug and say “looks like you have a problem” and move along. They won’t even tell you why they’re not helping you! To get the marvelous free help, and to truly join the community, you have to put in a little effort. Trust me, it’s worth it!

Kate