At the start of the lockdown, Pluralsight made its huge curriculum free to help those who were suddenly needing new skills to find a new job during the pandemic. I saw a huge number of views of my C++ course for those who don't already know how to program. It was ironic, because I was busy updating that course, a process that is finally complete.

Please check it out on Pluralsight. The new course is called Learn to Program with C++. (The similar-but-not-the-same Learn How to Program with C++ is the old one.) Here's what I did to the 6+ year old course:

• redid all the demos in the latest compilers (Visual Studio Community Edition on Windows; Clang on Ubuntu and Mac)
  
• added more Ubuntu and Mac versions of demos and tested EVERYTHING on all the compilers
• moved content to slides and then just demonstrated it in the demo, instead of trying to explain concepts during long demos where there's no typing or other "demo" action
• took a more "modern C++" approach wherever I could
• improved the names in my sample code, trying not to have a,b,c and the like if I could
• added some explanation of "make" and removed rather a lot of "how to get Visual Studio to be nicer" because it does that itself now
  

Plus I just generally tweaked samples, slides, and demos throughout the whole course based on comments I've had from new learners since the original publication. It's a better course.

People often say that C++ cannot possibly be taught as a first language, but that's wrong. Modern C++ is not that hard. This course is a little over 5 hours long and covers most of the syntax and punctuation you need, functions, classes, type safety, using templates from the STL like vector and string, and even touches on const and RAII. If you want to learn C++ for whatever reason, don't let someone else tell you that you must go and learn some "scratch" or starter language first before coming back to what you really want to learn.

If you already know one programming language, and concepts like "if" or "loop" then you don't need this course. C++ Fundamentals Including C++ 17 is for you. It covers even more syntax, punctuation, library, and design aspects of the library.

As always, if you don't have a Pluralsight subscription, you can get a ten day trial by clicking the big white square on the blue sidebar of this blog. Enjoy!

Kate

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

Since late February, when I returned from a personal trip to Singapore, my travel and conference world has been shrinking in around me. Conference after conference has been cancelled (or postponed to next year which is the same thing), moved online, or put off to perhaps later this year. Of course, the rest of my world has also been shrinking: for the last 8 weeks I've left the house only a handful of times, and seen almost no-one. I'm sure it's the same for you. So it was quite a surprise to remember that my last conference wasn't actually that long ago: the video of it has just gone live.

This is a shortened version of Emotional Code for students, who don't all know C++ and don't all have a lot of experience with other people's code. I hope you like it. I've also updated my playlist, which has all the talk recordings I know about. If you're looking for conference substitutes around now, perhaps there's a talk of mine you haven't yet seen? Take a look at it now.

Looking forward to in-person conferences and live audio feedback once again,

Kate

This week I travelled to Montreal to deliver a keynote at CUSEC 2020, the Canadian University Software Engineering Conference. Everything was nicely arranged and I happily took the train from Oshawa to Montreal, then a short all-inside walk to the hotel where I checked in, told the organizers I was there, and settled in for an early night. I got a light dinner from room service but oddly could only eat half of it. Ah well, I thought, they fed us really well on the train, I'm probably just full. No big deal. I went to sleep.

About 10:30 I woke up and realized I needed to throw up. So I did. And did. And did. All night. For an extended part of the night it was every 45 minutes. It was bad. And then it got worse. Now I am not telling you this to gross you out or to overshare, but to get you, as a possible speaker or conference organizer, to consider this possibility if you have not done so before (I had not.) I felt perfectly normal when I left home, and even when I first arrived in town. Whatever food poisoning or virus got me, it hit fast and hard. When the sun finally dragged itself up over the Montreal horizon and into my eyes, I was exhausted, having not slept all night, and pretty sure I was not done throwing up (which it turns out I was not.) I got on Slack with my organizers and told them I could handle being tired but actually vomiting while on stage was a bridge too far for me. Could we switch with someone scheduled for Day 2?

Of course we could. They did that lovely duck trick, where above the water it all looks smooth and simple and you have no idea what amount of paddling and ruddering is happening underwater. Someone else did an opening keynote; my keynote moved to 11 am Day 2. A much needed bottle of ginger ale appeared at my door. I spent the day in bed and slowly returned to normal. I slept that night and did the keynote the next day, and very much enjoyed the rest of the conference. I didn't shake hands with anyone in case I was contagious. When the AV people started touching my laptop I gave them hand sanitizer.

So, if this happened to you, would you be able to come up with a plan B? Do you travel with anti-nausea meds? (I do, for airsickness, and took some to help me sleep during the day since they sedate me. They had no hope of working during the worst of it, but they still had value.) Do you have a little bottle of hand sanitizer with you all the time? (I do, and always will.) Do you know how to reach your organizers with some urgency when you can't leave your room? Organizers, I hope you would all react as smoothly and quickly as my CUSEC hosts did. Ellen and Afreen were ultra professional, as was everyone else I dealt with.

You don't want to think about it, I know. But -- you should, anyway. It doesn't take long to have a disaster recovery plan. Swapping two keynotes was the obvious choice, and it worked because the keynoters were staying for the whole conference not just popping in for their morning. A little prior preparation can predict proper performance, or something like that.

Kate

Every once in a while, I make a big change in how I plan and manage my speaking engagements. Early in the last decade, I decided to speak only at conferences I would happily pay to attend, and that improved my life dramatically. Instead of trying to justify a week away from home and the office in which I would try to keep up on emails from a hotel room or a hallway couch, while surrounded by people who didn't care about the stuff I cared about, I started looking forward to a week of learning and growing, of coming home knowing more than when I left, and of meeting my heroes and getting to see my friends.

While this was an important change, it was only a change in my decision criteria, and not in my overall process of deciding where to speak. I would get an email, or see a tweet, or otherwise become aware that a conference was going to happen, and then I would decide, on a case-by-case basis, if I wanted to submit to that conference. Sometimes I would have to decline because I had already submitted to another one at roughly the same time, without realizing the overlap. In mid 2019, I changed that. I listed out all the C++ conferences I knew of, and roughly when they happened. Then my partner and I went through the list, noting when various family events are happening, when we want to go on vacation, and other "big rocks" that conferences have to fit around. We talked about how many conferences I wanted to speak at, and whittled down the list to that many.

Now, as each conference opens a Call for Papers, if it's on my list, I submit, and if it's not, I don't. Of course, my talks aren't always accepted. I set myself a goal to speak at two non-C++ conferences in 2020. I was invited to one, but after I agreed they changed their dates and that conflicted with something else I had accepted. I submitted to another and they declined my talk. But one has accepted, and I have accepted another invitation, so I will be speaking at two non-C++ conferences for sure.

Expect to see me at:

• January, Montreal: CUSEC 2020 (Canadian University Software Engineering Conference) - keynote (and a Meetup while I'm in town, come ask about technical speaking)
  
• March, Bristol, UK: ACCU - Naming Is Hard, Let's Do Better
• May, London, UK: SDD - Naming and Emotional Code

I'm thrilled to announce my latest Pluralsight course:

Here are the modules:

• Course Overview
• Modern C++
• Standard Library Containers
• Lambdas
• Standard Library Algorithms
• Move Semantics
• Exceptions

• On Sunday, I am doing a preconference workshop (you can still get a spot) with John Lakos and Andrei Alexandrescu
• After the precon I hope to relax at the TShirt dinner. Pack a Tshirt that says C++ (or bring your badge, or a piece of paper on which you wrote C++ yourself) and choose a restaurant from the list that should be published by the time we all get to Colorado. When you arrive, ask where the other C++ Tshirt people are, and make some new friends! I'll be tweeting my plans just before I head out.
• Then it's back to the shiny new venue for the Registration Reception. Even if you're on East Coast time like me, make an appearance, see some friends or some of your heroes, there will probably be treats, and you'll be all set for the morning. Knowing the venue a bit is going to make you sleep better, and having your badge already will let you sleep longer.
• Monday I will be attending talks and spending time at the exhibitor table for #include<C++>, an organization working to make the C++ community more welcoming and inclusive. Come by and get a sticker! Buy a shirt! And you know, attending talks and hanging at the #include table is what I'll be doing all 5 days.
• If I manage to stay awake, I'll go to The Committee Fireside Chat after dinner. If there is something you always wanted to ask the people who create the C++ standard, here's where that happens.
  
• Tuesday and Wednesday it's talks, talks, talks! I predict I will go back to my room for a nap at least once. It's a strategic choice that lets you actually experience the post-nap talks instead of drowsing through them and needing to watch the recording in the end.
  
• Wednesday night is the #include<C++> dinner and panel! You can register for this on Eventbrite as part of registering for the conference. I'll moderate a discussion about some of what we've achieved in just two years, and what some of us would like to see next.
  
• Afterwards it's Lightning Talks. Everyone loves the Lightning Talks, they're always fantastic. I will try my best to stay up for them.
  
• If I can, I'll come super early on Thursday and Friday for recordings of CppChat. And stay all day for talks, of course.
  
• Thursday night is the Speaker's Dinner. And there's a planning meeting after that. But I might need an early night, because...
  
• Friday morning I have my one breakout session: Naming is Hard: Let's Do Better. And like last year, a lot of really good content is on Friday. Don't even think of leaving early. Fly home Saturday morning, you won't regret it.

See why I call CppCon an intense conference? 12 or 13 hours a day, every day. And no time for sightseeing! But oh my goodness the things I will learn, the people I will meet, and the fun I will have. See you there!

Kate