In April, I did my Naming is Hard talk at ACCU 2021. I'm getting better at doing talks online and handling interactions, at least I think I am :-). The recording is now online, so if you weren't at the conference, you can watch the talk. Being there is still better, even when it's digital - being able to chat to other attendees and the presenter is always going to be better than just watching a recording.

I added the talk to my youtube playlist of conference talks, so if you like that one and want some more, take a look!

Kate

I’ve been thinking lately about a lesson I saw taught in a martial arts class over a decade ago. A young student was misbehaving. I knew this kid from field trips and other school activities, and he was doing typical things for him – not paying attention, calling out funny responses from the back row, making faces and showing off, that sort of thing. He was always a little difficult to manage but this particular day he was worse than usual. One of the instructors stopped the class and took the boy aside from the group. He picked up a lightweight rattan sword. They use these for practice – they’re very light, and they are made of several light sticks bundled together. They make a loud clattery noise when they hit, and use up most of the energy doing that, so they don’t hurt. They weigh very little.

The instructor got the student to sit or kneel, and hold his hands out straight in front of him at shoulder height. Then he held out the sword and asked the student to take it with both hands, holding the sword and his arms all parallel to the floor. Simple. You could do the same thing yourself right now with a ruler or a pencil or anything else rigid and lightweight. It’s trivial to hold your arms extended, elbows locked, hands a fixed distance apart (because they’re holding something that doesn’t bend or stretch.) Easy, right? By now everyone was watching to see what the actual punishment was going to be. Would the instructor now hit the student, or demand they do something difficult? (It was common in that class to assign pushups for misbehaviour, and I adopted the habit myself, giving my kids pushups in the grocery store if they were driving me crazy.) But no, the instructor just stepped back and said “just hold that as long as you can.” The kid grinned. Everyone else looked puzzled. It was trivially easy to do.

But if you try this yourself, you’ll soon discover that very quickly it gets harder. It starts to really hurt after just a few minutes. If you’re stubborn and you grit your teeth, you can keep going. This student was very stubborn. After a while though, his arms would occasionally droop down. “Either put it down or keep it up! Shoulder height! Arms straight!” the instructor would call and the student would try again and manage to get back into position. Eventually he was clearly in distress. The instructor told him “you can put it down whenever you want” but it was quite a while before he did. His muscles were clearly very sore.

On that day, the instructor didn’t explicitly close the loop. He seemed content to have found a way to get through to this student that classes were not his to disrupt and there were things the instructors could do that the student didn’t like. But years later, I saw a larger lesson in the choice of that particular exercise. Lifting that light sword (or the pencil or ruler you tried this with) is nothing. It’s really nothing at all. No effort. Anyone can do it. And at first, holding it is nothing also. If you had never lifted a pencil before, and you met someone who was struggling after holding one for many minutes, and you tried lifting a pencil yourself, you would be really puzzled. “Why are you complaining? This is super easy. There’s nothing to it! Anyone can do it!” The student’s misbehaviour was like this. Each little thing – the funny comment, the silly face, doing the move backwards – was in itself nothing. Easy to deal with or ignore. Not a problem. But enough of them add up. Just like the time holding the light weight. It becomes hard. It becomes painful. It becomes unbearable.

I really urge you to try this. How long can you hold the pencil or ruler out before you start to feel an effort? Before it hurts? Before you physically cannot do it any longer? Try predicting these times and then doing it.

The world is full of things that are trivial and nothing if you only experience them once, or once a decade, for a few minutes. It can be nearly impossible to imagine that these trivial things could ever add up to something painful. In 1970 (yes! 50 years ago!) a university professor coined the term microaggression for tiny moments of “you don’t belong” aimed at racial minorities, disabled people, women in male-dominated industries, gay people, and so on. People who haven’t experienced a steady diet of “you don’t belong”, however mild, often literally cannot imagine how it could add up to something painful. Sure, maybe you wince for a moment when someone assumes a group of developers are all male, or all straight, but it’s no big deal, right, and I’m sure the women know that when we say “men” we mean everyone, and the gay people know that when we say “wife” we mean wife, husband, partner, whatever. On its own, one tiny moment of “the only people I have to consider are X” is a little needle for people who aren’t X, but it’s such a tiny needle, who would complain, who would object, there was no nasty intent. Think about holding your arms out for 10 or 15 minutes and then think again about exclusionary language, policies that assume only married people have children, asking people “where are you from”, telling someone “you don’t look like a software developer”, making jokes about people’s weight or appearance, and all those tiny tiny little things that are nothing once, but that truly genuinely add up over time to real pain.

And then ask yourself: if it really doesn’t matter whether you say “men” or “people”, then why is it so important you keep saying “men”? That sounds like it actually does matter after all. If it’s no big deal and of course we all know that there are people who differ from you in some way, why are you not prepared to do the work of talking as though such people exist, instead asking them to do all the work of translating your literal words into what you probably meant, or would have meant if you had thought about it? How can you lessen some of the pain and effort other people have to put in all day, every day, day after day? It will be no big deal to you, right?

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

I spent much of the spring working on this course, and am delighted to see it live!

Visual Studio 2017: Essentials to the Power User is 7 hours of good stuff you need if you're a Visual Studio user. My emphasis is on keeping you happy and productive by getting the tool to help you and showing you neat features you probably didn't know about. If you open that link in a new tab, you can play the course overview (a 2 minute "trailer") and look at the table of contents. I've done versions of this course for older Visual Studios and I get comments like "It's as though I have a whole new IDE" and "I've been using Visual Studio for years and you showed me things I didn't know, and I'm glad I do now."

I think debugging in general is not taught enough, so I'm happy to have 2 whole modules on it here - not on philosophy of debugging or how to narrow down a bug, but just on how to operate the machinery of Visual Studio's debugger. There's lots of it. Plus, if you have Ultimate, there's another half a module on "Historical Debugging", IntelliTrace. I also spend quite a lot of time on how to find your way around a large codebase with the various searching, finding, navigating and exploring capabilities that have evolved over time.

Here's a quick topic summary:

I really enjoyed writing this course and hope you enjoy watching it. If you need a free trial, look over to the right on this page for the grey rectangle that says Author and click for a 10 day trial.

Kate

I've started a C++ column in Visual Studio Magazine. I'm sure you've read plenty of C++ columns in your time - I sure have! I wanted this one to be a little different. So, here's what I've decided to do. For each column, I choose a guidelines from the C++ Core Guidelines, and then explain it. But the twist is that I'm not going through the guidelines from top to bottom - I'm picking guidelines whose explanations require a little language knowledge.

The first column just sets the stage and explains what I'm doing, and gives you a link to the Guidelines. The second, Don't Cast Away Const, explains the guideline, but also the consequences of const-correctness, a typical situation where you might find it hard to stay const-correct when you make a performance tweak to a running system, and the correct use of the mutable keyword. Not bad for explaining a four-word guideline!

I have a number of columns already written and plans to write more. Please check them out and spread the word!

Kate

I have a new Pluralsight course on Visual Studio called Visual Studio 2015: Essentials to the Power-User. It starts at the beginning, so if you're new to Visual Studio it will help you get started, but carries on "to 11" as it were, covering things many everyday users of Visual Studio don't know. Here are the modules, each with their length:

1. Getting Started (42:08)
2. Projects and Solutions (13:23)
3. Namespaces, Folders, and Files(27:03)
4. Understanding and Personalizing Visual Studio UI Components (26:57)
5. Exploring Relationships in Your Code(36:41)
6. Using Search and Find Effectively(28:15)
7. Letting Visual Studio Help You (46:28)
8. Basic Debugging Features (24:04)
9. Additional Debugging Features (44:30)
10. Working with Designers (39:37)
11. Useful Extensions (39:54)
12. IntelliTrace and Code Map (25:57)

If you don't have a Pluralsight subscription, click the Author link over on the right hand side of this blog - click Subscribe, then Start 10-Day trial. That should give you a good idea of how valuable the subscriptions can be. (My company buys subscriptions for my staff, and I use my free author one all the time. It's a great way to learn a new technology.)

My main goal in this course was to have Visual Studio make sense to the learner. There are so many ways to do any action that sometimes when you learn something it seems pointless, and you quickly get tired of learning an endless parade of similar features. I worked hard to put these into an order that would lead naturally through the capabilities of the tool, and put things in context. If you watch all 12 modules, you'll know more Visual Studio than most developers - and you'll have a productivity boost to show for it that should be pretty impressive! Please do give it a try.

Kate

On the Pluralsight platform, subscribers can access a discussion area for each course. The traffic in mine is light enough that I have set up an alert to send me an email for each new comment. I just got one for my StackExchange course that brought a huge smile to my face:

I have actually tried not to use Stack Exchange and stick to other sites.  I had several bad experiences and have not gained any reputation at all on any questions that I asked.  I have even deleted questions due to downvotes or other negative activity.  Well after watching this, I understand the problems that I have had in the past.  I really enjoyed hearing this and knowing the mechanics of how this works [...] I now know more about it to help me find the answers that I need when I am head scratching my way through coding.

When I first started reading I was thinking "here's a comment about how StackExchange is horrible and why have a course on it" - something I hear from some of my friends. But then it took a sharp right turn to the exact reason why I wrote the course. I mean this is exactly the persona I had in mind - someone who needs answers, but because of not knowing the way the sites work, not only isn't getting them, but is having an unpleasant experience and ends up avoiding the sites.

When I decide to write a course I let myself imagine some possible outcomes. This comment is just the sort of outcome I was hoping for. It keeps me motivated to create more :-)

Kate

In my Pluralsight course, Using StackOverflow and Other StackExchange Sites, I cover all the things you really need to know to use the sites effectively and get answers to your questions, or a chance to show your skills. In the last module I explain how to help run the sites yourself, and I suppose you don't actually need to know that to use them - but knowing how they're run can help you understand what happens and why, so I included that material. I didn't include things that are really just for fun.

Right now, Winter Bash is on and it's just for fun. I made a quick video to show what it's about - take a look and let me know what you think. I hope to keep adding more "almost-great" items throughout next year.

Kate

• Plan your sessions in advance, at least two per timeslot. Carry a paper list of session names and room numbers so if you decide to bail on one, you know exactly where to run to, even if your electronics are out of battery and there's no wifi.
• Wear comfortable shoes and clothes, but not so comfortable that you would feel underdressed when talking to a potential employer or other business contacts. You will walk a LOT so choose those shoes with special care. It will be both stinking hot (outside - many conferences are held in hot places at muggy times) and freezing cold (if you end up right under the AC that is set on stun) so have a layering approach.
• Bring your own bag so you can tell it apart from everyone else's, and know just where to find things you need. Leave as much as you possibly can in the hotel room, to save your back during all that walking and to minimize what you might lose if there's any kind of bag mishap.
• Eat at the conference - it's a great time to meet people and this is where I usually bump into people I know.
  
• Go to the trade show floor, the community area, and the like multiple times. Serendipity will happen but you have to give it a chance
• Pack a somewhat larger bag than you need to - there is a lot of swag at Tech Ed and first timers can't resist lining up for TShirts and the like. Don't be that person who stuffs it all in the conference bag and checks a second bag on the way home. For one thing, someone may accidentally pick up your conference bag thinking it is theirs. Your conference bag and all your other swag should fit in your main bag.
• Pack your days and evenings FULL. Don't you dare watch TV in your hotel room! Go to the labs and try something you always wanted to learn a little more about. Download something that was just released and try it. Go to a party. Write up your notes (or better yet, blog them.) Send your boss late night emails about what a great time you're having and how much you're learning. Watch one of the sessions you didn't get to that day and then figure out if the speaker is likely still at the conference and how you can arrange to find that speaker and say thanks for the talk or ask a question. Fill out the evals for the talks you went to. There is SO MUCH you can do while you're on site, so try very hard to do it all. Make the most of the week, make it intense, and you will get more out of it by fully engaging.
• Try to do at least a few hours of sightseeing - one afternoon or evening - with some friends if you can. Maybe the attendee party is being held in some iconic location? Go to that. Or there's a restaurant in the town that you've always wanted to eat at? Gather a few folks and arrange something. Twitter is great with the conference hashtag - "who wants to go to XYZ tonight?" - I've done this for going on tours too. Gives you fellow geeks to talk to while you sightsee and strengthens friendships if you go with people you only know professionally. But don't overdo the sightseeing - you're here for the conference, remember.
  

I hope I see you there! The better prepared you are, the more benefit you will get from the conference!

Kate

• Familiarity with one or more programming languages and IDEs
• Careful attention to detail, especially for visual design (form layouts and alignments, fonts etc)
• Willingness to learn a large and complex project
• Time management skills including estimating and reporting effort and time for tasks and projects

Nice to have:

• .NET programming experience and familiarity with Visual Studio
• Experience developing a Windows Forms application
• Background in software testing or user support

The job offers:

• Work onsite in Peterborough
• 40 hours a week as soon as the student’s schedule will allow
• Important work improving a product that is mission-critical to real customers
• Specific project to be tackled and completed; more will likely follow if this one goes well
• Training on the tools to be used and the tasks to be done
  
• Regular access to a world expert mentor in relevant areas
• Pleasant working environment with nice coworkers, relaxed dress code, and an open office

It's worth mentioning that there is no C++ involved in this at all. So don't hold back if you don't have it, and don't rush to apply thinking it's a C++ job, because it's not. If you're interested, email me directly (please don't just comment here or tweet me or the like) and I will pass along your resume and contact details. I may have another client looking for someone soon as well, with similar requirements, so let me know if I can hang on to your info and pass it along twice.

Kate

I've been working on another C++ course for Pluralsight to complement the C++ WinRT/Windows 8/Metro course I did as well as the two-part C++ Fundamentals course (part 1, part 2). It's finished and live!

The topics I cover are:

• Avoid Manual Memory Management
• Use Lambdas
• Use Standard Containers
• Use Standard Algorithms
• Embrace Move Semantics
• Follow Style Rules
• Consider the PImpl Idiom
• Stop Writing C With Classes

I had a real blast writing this - while I was editing it I could hear my own enjoyment of parts of it. I hope you enjoy it too. A Pluralsight subscription is such a bargain - buy one for the topics you simply MUST learn for work, then use it on your own time to learn all those other things that you think you might benefit from. (I recommend Annual Plus - $500 gets you the sample code and offline viewing, all you can learn for a year.) Whether C++ is "must learn for work" or "I hear it's different know, wonder if it could help me" for you, I hope you find it helpful. Please let me know!

Kate

The minute this was announced, I knew I had to go.

Two days of "C++ today and tomorrow" with the bright lights of C++ today? Just try and keep me away! I'm so glad I was there - it was AMAZING and FANTASTIC and just generally wonderful. For me, personally, seeing so many old friends was a big part of it. The C++ team, other C++ MVPs, people I went to university with, and so on. It was also wonderful to see so many young people - including speakers, but also attendees, who were clearly in their 20s (and a few who were obviously in their teens.) After Chandler's talk I told someone "we can retire now: the future of C++ is in good hands." The speakers were not "the usual suspects" at a Microsoft event either. At a panel at the end of the second day, someone asked about C++ and the cloud and one of the answers was to indicate three speakers sitting next to each other: "Microsoft guy, Facebook guy, Google guy. Where isn't C++ in the cloud?" While that was a great cloud answer, I think it also highlights how inclusive this was - it was a C++ conference held at Microsoft, not a Microsoft conference.

Some fun quotes I happened to write down:

• “if it’s that ugly, it must be good” - Bjarne, on why some newbies imitate horrible code written long ago by their heroes
• “write C-style code, expect C-style errors” - Bjarne again
• “we know where bugs hide” – Bjarne (they hide in large tracts of complicated code)
• "dot dot dot is where the fun begins" - Andrei
• "real code is not supposed to fit on slides" - Andrei
• "this is legal" - Andrei (we needed to be reassured since it rarely looked legal)
  
• "if you're using new or delete, you're doing it wrong" - Herb (it's true!)
  

And Chandler's talk was very much a 2012 talk, with lolcat-like interjections and Simpsons references and even a how-agile-is-this update with a picture of Oscar Wilde in reference to Andrei's earlier off-the-cuff description of some template error messages (aka template barf) as being "a small novel by Oscar Wilde." The humour level was very high, much of it self-deprecating - no-one, not even the coiners of the terms, thinks RAII or SFINAE are great names, but what the heck, they're the names we use.

Even the little things here were so well done. Herb opened the conference by dedicating it to Dennis Ritchie, which I found extraordinarily touching and appropriate. He opened day 2 by celebrating the 20 year anniversary of Microsoft C7 which was C++ 1 for them, with Visual C++ appearing in the next release. There on the podium was the two foot long, 44 pound box, with multicoloured plusses all over it, in which it shipped.

And what was inside? A lot of books, and a lot of 3.5" floppies (I took this picture earlier, before the box headed to campus):

There are 5 or 6 floppies in each bag and apparently each bag had a part number of its own.

This conference was far more than a trip down memory lane, of course. It was a two-day Valentine from Microsoft to the C++ community, a demonstration of the "new growth" in modern C++ and the power and capability that is there for those who are prepared to start using the new features, and a chance for all of us to accelerate the learning we have to do. I so hope you were able to be there, or to catch the energy by watching it live and following tweets from those of us who had to share the bon mots and the fun. But if not, the on-demand videos are almost all there now. Here are the links:

Bjarne Stroustrup : C++11 Style

Hans Boehm : Threads and Shared Variables in C++11

Stephan T. Lavavej: STL11 – Magic && Secrets

Andrei Alexandrescu : Variadic Templates are Funadic

Panel: The Importance of Being Native (Bjarne, Andrei, Herb, Hans)  

Herb Sutter : C++11, VC++11 and Beyond

Chandler Carruth : Clang - Defending C++ from Murphy's Million Monkeys

Andrei Alexandrescu: Static If I Had a Hammer

Bjarne Stroustrup and Andrew Sutton: A Concept Design for C++

Panel: Ask Us Anything! (all speakers)

Fair warning: both of Andrei's talks, and the Concepts talk, are hard. This is cool new stuff that we are all learning about. There is no shame in pausing, rewinding, and giving something a second listen. Look, Chandler was running through pitfalls and problems that Clang catches, and showed some code with a problem I couldn't spot. A few minutes later in the Q&A, Bjarne asked him to clarify just what the problem was. Made me feel better!

Chances are you won't be able to watch any of these on fast forward, or skip any of them. So I'm asking you to invest 12 hours of your life to watch all of them. Do it! You won't regret it!

Kate

PS: They gave us shirts (it's all about the shirts for developers) with real code on the back and this on the front:

Kate

• "You can of course still use MFC but I do not recommend it as modern C++ can do a better job of supporting the Windows developer."
• "You should never again use auto_ptr for anything."

People often ask me what Visual Studio Ultimate offers that other versions do not. There's a handy chart on the Microsoft site:

The only problem is, if you don't know what "Architecture and Modeling" includes, it's easy to think there's probably nothing useful in there. So I was pleased to see a blog post by Susan Ibach from Microsoft Canada showing how easy it is to generate a sequence diagram from code, and how that can help you understand code you've inherited from a predecessor. That's one of the diagramming tools included in Visual Studio Ultimate.

Right click in some code, select Generate Sequence Diagram, set some options (does getting a property count? What about calls to methods of String or other .NET Framework classes?) and presto, you have a sequence diagram.

• Changing a value in the watch window
• Changing a type in the watch window
• Inspecting an array in the watch window

Since Tech Ed came and went during my blogging hiatus, I didn't get around to providing links to some of the sessions you might want to see. It's time to correct that omission:

• WOMEN IN TECHNOLOGY LUNCHEON - Developing a Strong Support Network: The Key to Being Successful as Women in Technology
• ALM for C++ in Microsoft Visual Studio 2010 - one of the highest rated sessions in the whole conference. C++ sessions get high ratings!
  
• Advanced Programming Patterns for Windows 7 - my Day 2 session - no C++ content
• Modern Native C++ Development for Maximum Productivity - my Day 4 session - plenty of native code here: lambdas, auto, the PPL, and so on.

Kate

Today saw the release of the first episode (naturally, Episode 0) of GoingNative on Channel 9. As the introduction says:

GoingNative is a new, monthly show on C9 dedicated to native development and native developers, with an emphasis on modern C++.

You know there's been a lot of talk about the C++ Renaissance. I'm happy to see that phrase get picked up, and I've got another one for you: Modern C++. Or as some folks like to say "not your father's C++". If you think C++ means manual memory management, strings as arrays of characters and a strange cast of global functions, and longing for a library or framework that might rival what .NET has to offer, then you haven't been keeping up with C++. The good news is that it won't take you long to catch up - shared_ptr and unique_ptr, the Standard Library, lambdas and other Modern C++ goodies are easy for both managed developers and longtime native developers to learn.

In Episode 0, Charles Torre (longtime C++ friend) and Diego Dagum (C++ Community lead, blogger, and Tweeter) lay some groundwork and, of course, show code. It's always about the code, right? Then, they ask you to get involved. Whether you're someone who wants to learn about C++, or someone who wants to make sure something about C++ gets taught to others, speak up! And yes, that includes topics on non-Microsoft platforms. Email C9GoingNative - they're using hotmail - or on twitter, follow or talk to @C9GoingNative. (There's a Facebook group, too - whatever way you like to interact is welcome.)

But wait, did that sound like a whole episode? Nope, they grab the camera and head over to see Ale Contenti - one of my favourite team members and one I've done interviews and sessions with before. His talk gets technical fast, which is one of the things I like about him! I too have a soft spot for 6502 assembler :-) and find template meta-programming a bit of a write-only technique. I, too, like "the power the language gives you to make the language bigger with libraries" and think that's part of the appeal of C++ for me. Well, that and the power and performance and control, of course. Are there downsides? Well, there's what Joni Mitchell called "the crazy you get from too much choice" - C++ gives you many ways to do everything, according to your circumstances, and having to decide how to do it, or having to connect two components that made different choices about something as simple as how to represent a string, can be frustating. As well, it's great to be in control, but that does mean that nobody is looking after you. If you're inexperienced (and sometimes, even when you're not) you can make dangerous choices and, as we like to say, shoot your foot off. Security holes and vulnerabilities are important and C++ will let you write bad code, so you need to be aware of best practices. Both Ale and Diego address these points, and you can expect to see more of that in time to come - especially if you ask for it!

Looking forward to next month's show already,

Kate

• 1 - introduction
• 2 - containers
• 3 - shared and unique smart pointers
• 4 - whiteboarding
• 5 - whiteboarding continued
• 6 - algorithms
• 7 - more algorithms
• 8 - regular expressions
• 9 - rvalue references
• 10 - type traits

Most MVPs agreed that, despite not being illegal in C++, throwing primitive types like int, long, etc., or similarly Windows-based ones like HRESULT, etc. is a coding horror as inabilities to catch those in the proper place will make the application crash with a hard post-investigation to determine where they are being originated.

I strongly recommend AGAINST using the /EHa compiler option. Either /EHs or /EHsc should ALWAYS be used, with /EHsc being preferable (it's faster because it assumes that extern "C" functions won't emit exceptions - while technically permitted by the Standard, sane code should never attempt to do such a thing, so giving up that ability is worth the performance gain).

And I am sure the comments will continue to grow and the conversation continue. This is how we all get better, by discussing and sharing and occasionally defending our practices. It's a must-read.

Kate

Template meta-programming and expression templates are not techniques for novice programmers, but an advanced practitioner can use them to good effect.

It is important to understand how your programming language is implemented. Such knowledge dispels the fear and wonder of “What on earth is the compiler doing here?”; imparts confidence to use the new features; and provides insight when debugging and learning other language features. It also gives a feel for the relative costs of different coding choices that is necessary to write the most efficient code day to day.

... we have considered many of the significant C++ run-time implementation issues. We see that some wonderful language features are almost free, and others can incur significant overhead. These implementation mechanisms are applied quietly for you, behind the curtains, so to speak, and it is often hard to tell what a piece of code costs when looking at it in isolation. The frugal coder is well advised to study the generated native code from time to time and question whether use of this or that particularly cool language feature is worth its overhead.

Wow, these things get up there fast! My sessions were very well received and I had such a great time doing them! In the order I delivered them, they are:

• Women In Technology Panel - Claudia Woods, Freena Eijffinger, Paula Januszkiewicz, and Rhonda Layfield joined me to take questions from the audience and talk about what was on everyone's mind. There's really no video - just the title slide for the whole hour. Please listen!
• The Windows API Code Pack: Add Windows 7 Features to Your Application - This one includes screen capture so you can follow along in the demos. You can also download the powerpoints from this page, and as I mention in the talk, the demo code is the samples that come with the Code Pack.
• Modern Programming with C++0x in Microsoft Visual C++ 2010 - I had a great time delivering this talk even though it was the first time I delivered this version of it. The attendees responded by putting the talk in the top ten for the whole conference - thankyou! It, too captures the screen and slides, and you can download the powerpoints.
• Advanced Programming Patterns for Windows 7 - Another talk I was doing for the first time and I enjoyed it too. If you'd like the sample code, stay tuned - I will blog when the recipes are released. The slides are with the video of the screen and slides.

If you came in person, thank you! If you couldn't be there, please watch the videos and leave me a comment. Speaking on technical topics really is the most fun you can have standing up, and I can't do it without audiences.

Kate

You may have noticed that the fall tour I'm doing features morning talks that go till about 11:30, and evening talks that start at 6pm. I've decided that between those two, I'll spend the afternoon in a coffee shop and host an "on the road coffee and code". As I explain on the Coffee and Code page I keep for this purpose, this is really informal. Just stop by, say hi, we can talk about whatever you like. If you were at the morning session, you might want to just walk with me from the venue to the coffee shop and continue the conversation. Or if you're coming to the evening session, you might want to try to find me during the afternoon to ask something specific, then head to the venue together. Or maybe you have a topic to discuss that has nothing to do with Building Awesome Windows 7 Applications in managed code: a C++ question, or an extending Visual Studio 2010 question, or whatever. That's great, and the Coffee and Code format is just the place for us to have that chat.

If you live or work near the venues for the fall tour, I'd appreciate your suggestions (by email or twitter) for where to hold these. Obviously we need wifi, power, and a table we can hog for most of the day. My default choice is Starbucks, but if you know a better one that I can easily walk to, please tell me about it. Once I've chosen the location I can finalize the times.

Looking forward to meeting everyone,

Kate

Here's something that happens to me a lot. I'm working on a project that is mostly Technology A, but I need a little Technology B. I want a sample or two to show me what it can do. I search the web, but often find mostly things written by people who don't know what they're doing and are posting their (possibly flawed) code into question-and-answer forums. I search MSDN, but often the newest technologies don't have their samples yet. I also remember to check if the All-in-One Framework people (I blogged about their coding standards document earlier) have anything. And if I still get nowhere I start asking people I know if they have one.

Well, now those helpful folks at All-in-One are kicking it up a notch. And remember, they cover all technologies and languages related to Microsoft tools. (Want to know more about them? Here's a fun video.)

And this goes back to one of my earliest blog posts - what you want may be what I need to give. Imagine it's your job to decide what samples to write. How are you ever going to find out what developers out in the big wide world want samples of? You could come up with a great idea and then find out people already had all the samples they needed for that. So that person wants ideas for samples. And here you are needing a sample. See how that works?

Just visit the wiki page and follow their instructions. It's a tad more complex than "shoot me an email and tell me what you need" and for good reason. Give it a whirl if there's something you need!

Kate

I'm teaching OO design and UML again this term, and one of the things I emphasize to the class is the dangers of coupling. (Get your mind out of the gutter, I mean classes with dependencies on each other.) It's not about calling methods of each other necessarily; it's more about if-I-change-this-one, I'll-have-to-change-this-one-too. Changes that ripple through a system are expensive and dangerous.

When I am helping clients with interop, they are often surprised to learn how entire applications and libraries can depend on each other without ever calling each other's code. For example, App A writes a record to a database table. Service B checks the table regularly for new records (or records with a 0 in the Handled column, or whatever) and calls a web service (or whatever.) Those applications are now coupled - if a change in one necessitates a change in the format of that table (or its name, etc) then the other must be changed too. Thinking ahead and doing all you can to reduce this kind of coupling is part of the challenge of doing good application integration, even if there are no interop calls in the solution.

And then there's performance. So often left until last, it provides another consideration that you should ideally have in mind all the way along. And as Rico Mariani points out, it also couples applications and libraries you may have thought were independent:

Two subsystems that both (loosely) use 2/3 of the L2 cache are going to use 4/3 of a cache... that’s not good. There may be no lines between them in the architecture diagram but they are going to destroy each others ability to work.

Sound advice as always. Please read the post, and keep one more "don't forget" floating around as you design and architect your systems and solutions.

Kate

I love this image:

I know this is true because in my role as friends-and-family help desk, I get people to read the error messages and then I repeat whatever they just told me and then they are like "oh, I get it! Thanks! I'm glad I know someone who understands these darn computers!" This works over the phone when I can't even see the message.

Now why am I mentioning this, besides the fact I love this dialog? Because it comes from a lovely blog entry by Chris Jackson on why app compat problems can't be fixed by talking to the user about them. You slave over a lovely dialog with a button which might as well say CLICK HERE TO GET A VERSION THAT DOESN'T HAVE THIS PROBLEM or a checkbox that might as well say CHECK THIS IF YOU DON'T THINK ITS A PROBLEM AND ARE SICK OF BEING REMINDED but instead the user clicks JUST THIS ONCE I WANT TO USE THE OLD ONE BUT BE SURE TO TELL ME ALL THIS AGAIN NEXT TIME. 

Is there a solution? I don't know. But you need to know people are like this.

Kate

If you want to progress in business, don’t wait to be discovered.  Make sure you have a great online profile and a positive brand.  

Have you ever heard of the All-in-One Framework? Well I hadn't. They've been around for about 18 months. Back in February, on their first anniversary, they described themselves like this:

...this initiative [has been] developed by the CodeFx Project Group to an "all-in-one code framework" that includes more than 300 code samples, covers almost all Microsoft development technologies, ranks 18th among 13000 open source projects on CodePlex, received numerous kudos from customers, proved its values in real support incidents, and created a lot of win-win opportunities within the corporation.

It looks like the participants are all Microsoft employees and they're collecting pieces of code for any language and platform that can be used to solve real world problems. On the CodePlex site, they elaborate:

Microsoft All-In-One Code Framework delineates the framework and skeleton of Microsoft development techniques through typical sample codes in three popular programming languages (Visual C#, VB.NET, Visual C++). Each sample is elaborately selected, composed, and documented to demonstrate one frequently-asked, tested or used coding scenario based on our support experience in MSDN newsgroups and forums. If you are a software developer, you can fill the skeleton with blood, muscle and soul. If you are a software tester or a support engineer like us, you may extend the sample codes a little to fit your specific test scenario or refer your customer to this project if the customer's question coincides with what we collected.

For example, they've written a summary of the ways to call native C++ code from managed code. You can find the pieces elsewhere, but having them all together makes it easier for you to compare and contrast. They often blog additions as they are completed.

Now as you can imagine, a big team creating hundreds of samples needs some sort of vision and structure to keep things consistent. That's where the style guide comes in. And now you can download it from CodePlex. It's an 87 page Word document that covers everything you might wonder about, for both native and managed code, including tabs-vs-spaces (no tabs, please), how much to comment (as I blogged recently and not so recently), Hungarian Notation (use it in native code if you must, but it's a relic; do not use it in managed code), smart pointers (yes, but don't bring in all of ATL for them - I look forward to this section being updated for C++0x), the right way to implement IDisposable, and an especially nice section on Interop at the end.

I don't care what language you work in - this is a document you should at least skim. It could settle some arguments at the office, improve your code, and spare you from some horrible bugs. Download it, won't you?

Kate

I was visiting a mentoring client today and we wanted to look at the config file for an application that is deployed with ClickOnce. So I needed to know where it was installed. I know that you can get to installation locations pretty quickly from the start menu:

So I took a look at the ClickOnce app in the start menu:

That's a problem - no Open File Location. I tried a little web searching but wasn't happy with what I found. Then I remembered.

Start the app - simple enough, since it's on your start menu. Then bring up task manager. If you right click the app on the Applications tab, there's no joy:

But ... if you choose Go To Process (or just switch to the process tab and look for the right EXE name) then we're in business:

The very first choice, Open File Location.

And when we get there, sure enough, there's a config file (among other things):

Completely obscure path, but who cares, I can confirm the config settings for the running app and that's all I needed.

Kate

It's no secret that I'm not in my twenties. After all, I'm in my fourth decade of being paid to program. (To be fair, you enter that decade as you pass the doing-it-for-30-years mark.) I have gained a lot of experience in all that time, and not all of it is programming experience. I am slowly gaining wisdom and judgment in general. But am I losing things? Am I perhaps closed off to new experiences, or stuck in the mud? Is there anything you can in general conclude about a person because of their age?

I have two problems with that line of thinking. The first is that differences between any two individuals in a group are always larger than the differences between groups. I can easily find two 20-somethings who differ from each other more than either differs from a 30-something or even an 80-something. Women in general may be shorter than men in general, but I'm sure we all know a man who is shorter than most women or a woman who is taller than most men. What you know about the group doesn't necessarily apply to the individual. My second problem is specific to age - some age related effects are actually related to "you went to university in the 70s" or "you learned to code in the age of GUIs" more than to how old you are, others are actually about your life experience, still others your work experience. Two 60-somethings may not have gone to university at the same time as each other or learned to code at the same time as each other. That makes it even harder to generalize based on a single piece of information - when you were born.

A few months back, 'Dave' posted a series of myths about older developers and then debunked them. Do you find yourself believing any of these?

• Older software developers are more expensive
• Older software developers are less flexible and less capable of learning new technologies
• Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours)
• Older software developers are less mentally agile
• Older software developers are more jaded and cynical

My only issue with this list of myths is that it doesn't contain positive ones. It's also a myth that older developers are wiser, more tuned to business issues, better at talking to others, and so on. Some are -- I strongly believe I am -- and it takes a while to get there, but time passing isn't the only thing that brings about that change in a person.

I have to work with people a lot younger than me every day. Perhaps some of them think less of me because of my age at first. I'm pretty confident that doesn't last. If you're not an "older programmer" yet, I hope you aspire to be one someday.

Kate

A colleague of mine who is not near Toronto has a client in Toronto who needs .NET developers. They would like to start out with a contract position and it could become permanent if it's a good fit for everyone. Here's the job description:

Position: Senior Programmer / Analyst

Pay: $7,500 per month contract (negotiable)

Applicant must be an expert or proficient in:

• MFC
• ATL
• COM
• .NET Framework  /  C#
• .NET Services
• Microsoft SQL Programming

Experience in the following areas would be helpful but not required:

• WCF
• WPF/SilverLight
• ASP.NET
• Visual SourceSafe
• Mechanical engineering experience

Responsibilities:

The primary responsibility is to modernize a legacy C++ distributed application. This may include a redesign and possible rearchitect of the application. The final application should be an n-tiered application. The tiers would ideally be:

• WPF/Silverlight  as the presentation layer
• A business layer with business components (C#) exposed via WCF
• A data layer

Where necessary, COM components can be preserved.

Other responsibilities include:

• Move image files from file database to SQL database
• Document the application
• Handle ongoing change requests.

Someone who moved from C++ to C# but didn't forget their C++ would be perfect. They are looking for more than one person so it sounds like a fairly meaty project. This is strictly onsite work, no remote work, which is why I mentioned where they are (east of the DVP; west of Pickering.)

Anything you email to me about this I will forward to my colleague who will in turn forward it to the Toronto folks. Good luck!

Kate

Programming is not one skill - it's a large conglomeration of skills. Some people are not very good programmers because they aren't very good at imagining their way through an algorithm. Others have great ideas and imagination, but it's painful to watch them type and they can't be bothered to learn how to use their tools (editors, etc) so they just take twice as long as everyone else to create the code. Still others are doing fine until their code does something unexpected, and then things fall apart, because they can't figure out what's going on. They step too soon, spend ages stepping through code that couldn't possibly cause the problem, then get impatient and end up skipping right past the problem. Worse, they don't seem to understand the capabilities of the debugger. I've watched people spend over 5 minutes patiently stepping into so that when they reach a particular line, they know how control reached it. Then I show them the Call Stack window and they say "oh".

I've blogged before about conditional breakpoints and tracepoints, hit counts, and so on. There is so much to the Visual Studio debugger that it is very hard to know it all. But the more you know, the better you are. And what's more, being a great debugger has more value than some of the other programming skills, because so much debugging happens at urgent times, is unexpected, and needs to be done as quickly and efficiently as possible. The difference in impact between being good and great is very large.

So how to be a better debugger? Partly, it's practice, especially practice with someone who's really good. That person can say "hey, what are you doing? Here's a way easier way to get there!" Even practice alone can motivate you to learn how to do something and get you reading the documentation or searching the web. You could buy a book, if anyone even buys books any more. You could take a debugging course, and spend a day or a week with someone who really knows every speck of this enormous tool. Of course, that costs money, travel time, and so on. Some of you will do it, and benefit from it tremendously.

But ALL of you can benefit from watching John Robbins' latest set of videos on Channel 9. It's in three parts and they total about three and a half hours. It hits the ground running and just doesn't stop. It's all using Visual Studio 2010 but the vast majority of the features he shows are in earlier versions too. I knew a lot of it (even the Go To Find box and the file opening etc) but I learned new things in the first ten minutes and continued to learn new things as they continued - both actual capabilities of the tool and interesting ways of thinking, like using hit counts on a breakpoint not to stop, but just to count how much some code gets run. I wish I could get the slides and code, but I guess some things need to be saved for the folks who actually take the course.

If you're a .NET developer, watch these videos. Now.

Kate

I teach a course at Trent University on Object Oriented Analysis and Design with UML, and have done since the last century. I teach my students how to make decisions about the systems they will some day build, and how to draw diagrams that communicate those decisions to others. We find as often as not that the act of trying to make the diagram leads us through the thought processes that are needed to make good decisions. That brings huge value even if you never show the diagram to anyone else and never update it.

I've never been a big fan of "technical documentation" in the form of a giant binder that some poor person has to keep up to date any time the code changes. If you want to know all the methods of the Employee class, why not use Intellisense or the Object Browser or the like? But that doesn't mean I don't like making those diagrams at the beginning, when they help me to do my thinking. I also make them when I have something to explain, including when I bring a new person onto a project. So how much do I love this quote?

the UML ... was to be a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system—in short, a graphical language to help reason about the design of a system as it unfolds. Most diagrams should be thrown away, but there are a few that should be preserved, and in all, one should only use a graphical notation for those things that cannot easily be reasoned about in code.

It's in an interview I already linked to, but it took Patrick Smacchia to point our those sentences to me. As I wind up the last few weeks of the course, it's nice to know that my position on the point of the diagrams and deliverables is aligned with one of my heroes.

Kate