I'm also a developer by profession (and I have an MSc in Software Engineering from a famously hard uni), but nowadays I do UX. What follows comes from a view of HCI perspective of UX, this is what was taught to me, this is the school I consider myself belonging to.
In general, UX is not far from IT: what developers are taught at software engineering unis as "software design" and what UML was about is basically what UX does today. Software design went out of mainstream at the end of the nineties, beginning of the 2000s, with the Agile boom (I was there, I know), so it's hard to find people who actually practice it, but most of them heard of it in university.
UX is a lovechild of Software Engineering and Psychology
Let's put this into perspective, for which I'll draw a simple diagram:
I'm pretty sure there are many more things, but that's enough for a quick illustration.
The "micro-IT" quarter isn't empty, it's just something which doesn't have to be explained to any frontend developer on the world.
Believe it or not, for example, taxonomies are also a required study in all IT universities, and they're used every day in object-oriented programming. So it's nothing new there.
Understanding the developer: the common language
For a developer, I'd start with familiar things, like flow diagrams. I did explain the relationship between flow diagrams and so-called Finite State Machines (again, a required study) in another answer at Programmers.SE
For understanding what a developer was taught, consider reading a UML book, like this one, (dubbed the "iconix book").
As for Use Case Analysis, which deals in general how a system should behave the best book is still Cockburn's Writing Effective Use Cases
Programmers like to categorize, and most of them do like to "lego", Design Patterns are a good place for a start. Design patterns originated in architecture, then went to IT, and it went from IT to UX. Nowadays Design Patterns are still widely used in IT, but not as prevalent as they were 10 years ago.
Orientation: Goals and Whys
It is important to each party to understand goal-orientedness: typically programmers work more effective if they do understand the goal the user likes to have. We talk so much into "it has to have this button and that shadow and that transition", which are non-meaningful to a developer, if you don't tell them, why.
I feel this is also a problem in UX sometimes, a lot of "pattern libraries" concentrate on the shininess factor, instead of goals and problems. A pattern should be always a problem pattern, and should always contain the explanation why the recommended solution works for that problem.
Support your stated goals with user research or scientific papers. Perhaps give them live demonstrations or statistics from the project's own research. Otherwise, the goal won't be authentic, and you won't be respected by the developers.
I tried to do my UXes in terms of goals and problems, and patterns: for each step, there is a problem to be solved.
This is what programming education education also looks like: they present you with a problem, then wait a few minutes,then start to have a grand-scale solution, then they say, "it's fine, but", and then they dwelve into the details until a full solution is found.
Quantify, quantify, quantify
Programmers understand numbers. If you tell them it is crucial that a feedback comes within 1000 msec, they can write an automated test to check if it does. Automated tests are in full-swing fashion nowadays, and this is something they can ask a computer to test.
If you tell them it's crucial to have an answer in 1000 msec, they'll work towards that goal. If you tell them something has to be at least 1 cm long on screen, they'll work towards that goal.
But it's always important to give them reasons. Developers are not dumb, and they hate being treated as such, especially by the UX community.
For Human Factors, provide cookbooks
It's true that the stereotypical programmer is not good at understanding people. That comes from the correlation between the affinity to deal with computers instead of other people and signing up to work as a developer.
They won't really understand, for example, that humans are bad at remembering things (recall vs remember), as most of them are really good at it (it's needed for their job).
But if you have a good cookbook (10 commandments, bullet-point checklists), which they can cross at the end of the day, with explanations, it might work.
This is what the bugzilla often-quoted tags do here, they give rule of thumbs to the developers. Saying, that there's a "ux-undo" bug says to the developer, "oh yes, there's a rule of thumb that everything should be easy to revert".
A good book in such is Weinschenk's 100 things
Accept, that programmers are occupied and enchanted by technology
Programmer flame wars are about technology: you might be surprised, how much it doesn't matter at the end, which technology do you use, and yet how much of their freetime (and, ehm, worktime, actually) goes into arguing over which is the best one. They even argue between apples and oranges, and they'll argue wether it's two apples or an apple and an orange.
They also put every single shiny thing they find on a website,thinking it's "ergonomic". That's especially true for shiny interactions.
If something isn't supported well by their current technology (like, a certain widget isn't found in the widget library of the system), there, the UX designer has to invest time and effort to understand wether the technological barrier is real or not.
To sum up
I had three aims with this text:
