Is Code also a model?

How come many good programmers seem to be able to write code without e.g. an explicit UML diagram? Let's look at the following piece of code from David Flanagans Thread programming examples:

public class Deadlock {
    public static void main(String[] args) {
        // These are the two resource objects we'll try to get locks for
        final Object resource1 = "resource1";
        final Object resource2 = "resource2";
        // Here's the first thread.  It tries to lock resource1 then resource2
        Thread t1 = new Thread() {
		public void run() {
		    // Lock resource 1
		    synchronized(resource1) {
			      System.out.println("Thread 1: locked resource 1");
			  // Now wait 'till we can get a lock on resource 2
			     synchronized(resource2) {
			        System.out.println("Thread 1: locked resource 2");

The important point is that an experienced programmer (experienced BOTH in Java and transactions) will recognize that the code inside the first synchronized statement (including the second) represents a UNIT OF WORK which is supposed to perform uninterrupted to guarantee the business semantics. The problem is that neither the concept UNIT OF WORK nor the business meaning behind is explicitly visible in the code. An experienced business programmer but new to Java e.g. might not catch the problem behind "synchronized".

So program code represents a model as well - it is just often not made explicit or in a syntax which is not understood by non-specialists.

EJB e.g. decided to make such semantics explicit through declarative statements and hide the imperative aspect from the business programmers.