Because programmers are usually quite literal minded, working with UML might first feel very slow and frustrating process. At first I had thought like how am I going to know all the classes and associations even if I haven't made a single line of code? How I can desing anything, if I don't have any project plan? Do I have to create requirements analysis to create a project plan and then to create an UML design? I bet that you also can see how deep it goes when you start to think UML diagram as literal as your code would be. At worst you might fall to some kind of waterfall project, which would take eternity before you could create just a single line of code. Nobody wants that at nowdays. What I'm trying to say, is that you can utilize UML in your project as part of coding work. Most important is to have a visual image of your software architecture and the main class associations.
Try to keep it simple
I found out a quite good general rule about UML design from another web site. Don't model things in the UML what you want your coder to do. Even if you're doing your software by yourself, it's a very good rule. I see the rule in a sense, that don't do unneseccary accurate diagram and leave out all the stuff what programmer can create during the coding.
Creating a very accurate UML diagram takes a lot of time and a very accurate project plan and requirement analysis. In one man project, like I have, that would take way too much time to do. And in worst case if something is wrong in the plan, you have to do again whole design progress. Not good. That is perhaps why most of people just turn away from the UML.
Visualizing helps to avoid pitfalls
Visualizing your code with UML can help you to avoid some pitfalls what at first you might not detect. Let's say that I have a class Gameobject. I want that my gameobject is a renderable mesh, it's collidable and it has physics on on it. Pretty soon I have monolithic class hierarchy which limits design choices. I usually want to keep my class hierarchy flat and nice, so that the class hierarchy is nice and simple. With UML you might notice if the class hierarchy gets too deep and you might want to change that. These kind of design problems are good to notice before coding, hence it saves time. Nothing frustrates more than to code something again, but slightly different way.
Here I have a picture from previous example. It's OK to inherit Piece and Board types from GameObject class, because the hierarchy stays quite flat. But I have made an aggregation to GameObject class with Transform and MeshInstance classes, because I can keep code more adjustable and to prevent monolithic class hierarchy. You can easily decide things like these in advance before going to coding and save some time and archictectural troubles.
I don't also usually bother to create perfect classes in UML, like filling perfect information of members and functions. Those things I usually decide while coding. Some main functions and members I add to UML diagram which helps me to visualize the class itself. These are usually related to direct x stuff, like objects needed to hold rendering data and COM objects to interact with devices. Filling that kind of information just makes the class more instructible.
It's good to atleast learn some basics about UML diagrams, because quite many programming books uses the UML to describe class relationships. That is because in UML you can usually describe quite a complicated relationship whitout writing a novel. I also think that when you understand UML, you can also explain your code to somebody else in more standardized way and understand better when somebody else talks about programming.