Maybe not directly applicable, but all application design will help you be a better programmer.

I use class diagrams and a couple others in my own personal projects, but it's all extremely high-level. Basically, I just map out how the objects talk to each other; I rarely ever put actual function names or variables in the diagrams.

As far as professional game development, I've never seen any UML in a game company. We often do formulas and solve fun math problems that make people like me cry (our chief architect has a PhD in mathmatics). I do draw up crude flow charts if I need to wrap my brain around an algorithm I'm creating, but nothing fancy.

However, I agree completely with Larrik that it's a worthwhile skill to have. And to be honest, there are times when I would love to have a class diagram for whatever system I'm messing with. Everytime you document your code, an angel gets it's wings. I'm sick of the only documentation being a comment that says:
// this is pretty jank, will revise later

[[ edit: Yes, that is an actual comment in Rat Race (sigh) ]]

-Rez

Never used UML in game or have i seen it used there. I have worked on other projects were it was. Personally I still prefer legal pads and pens. You can be sitting around talking to people hashing stuff out anywhere no need to gather around a computer to make sure things get recorded right

The UML from code generators I've seen for C++ don't see to do a very good job. That means to me that your pretty UML diagrams and charts wont reflect your real code. If somebody thinks they know of a good one that will handle Microsoft and GNU C++ extensions let me know.

UML is a good thing to know for a job interview

Depending on the size of your system it can be very helpful for mapping out classes and communication/interaction between them. I started with a basic diagram for my engine by module and simply showed the classes and inheritance between them. From there I moved onto collaboration between the objects and ultimately used these diagrams as a basis for my design document. I didn't flesh out my classes however in UML...I left this for my design document where I list each method, return values, virtuality, etc. as well as the steps that the method will take.

UML is definitely something valuable that can assist you in visualizing the layout of your system and helping you find any faults or flaws in your design but when it comes down to pure design that's what the design document is for :).

Well, I must say that I did learn UML but at that time I didn't know how much of it was good/bad. I've seen programmers who get all wrapped up in it -- trying to solidify the architecture before they write a line of code. Then when it comes time to code that system, they just have to throw the diagrams away because inevitably, the code changed the diagrams.

I've heard it said here and there; UML diagrams are good when brainstorming. These diagrams, though, should be on napkins and thrown away. They are a tool to communicate and visualize "possible" architectures -- not what they will end up being. The diagrams will be proven right/wrong only with coding.

Now, I must confess I am not a C++ programmer. I know C#. So when I bought Mr. Mike's book, I had to read everything like 5 times. I sometimes doodled on the page gutters. Yep, little diagrams to help me visualize what he was talking about. So they are definitely a good thing. Especially when trying to figure out communication between different modules. They are also extremely helpful when reading about a complex system to have a class or sequence diagram here and there (hint, hint).

Oh yea, I'm waiting for the next book, Mr. Mike. It seems the majority of your audience still want a c++ update, not C# & XNA. My only suggestion would be to widen the page gutters so I have more room for my doodles.