It doesn't make much sense for people who always heard and thought that "an interface just lists the public methods and properties of a class". In that view the classes always come first and the interfaces are unnecessary boilerplate.
However if instead you assume that "a class is just an implementation of an interface", then everything changes. Now the interfaces come first and classes are required to materialize them. In that paradigm objects only communicate with interfaces, never (or almost never) with other classes unless a specific implementation is required. Which is why an interface is always defined for a class even if there is no plan for other implementations of it.
Rather than a "contract", think of an interface as the description of a job. If you ever need to write a safety procedure, does it make more sense to write "In case of fire, call John; John happens to know how to extinguish a fire." or "In case of fire, call a fireman."? "Fireman" is an interface. "John" is a class implementing that job. It might be the only class in the codebase that implements it, but that is no concern of the caller. They just want that fire dealt with.
I discovered software programming about 20 years ago during high school by fooling around with my Casio programmable calculator. I spent countless hours writing small utility programs and games in BASIC, then I bought a more powerful calculator (still Casio though) which allowed me to learn and write programs in C, ASM (286) and C++.
Around 2005 I got myself a Casio ClassPad 300, which was like a strange combo of a calculator and a PDA. It had a big B&W touchscreen with a stylus. It was the first Casio handheld that came with an official SDK to build native apps for the device; before that it was only possible through pure reverse engineering and hacking -- good times. :) So there were 2 options to write programs for this device: you could either code in BASIC directly on screen, which was easy but very limited and suffered terrible performance -- or you could use a computer to write and compile a C++ add-on and then transfer it to the device, which was extremely powerful but of course a lot more complicated especially for beginners.
So here is what I did: I took the C code of the Lua 5.1 interpreter, embedded it into a new C++ add-on, and then I made it possible to write and execute Lua code directly on the device through this add-on. I even made a new custom font for the text editor and a new virtual keyboard for the stylus to maximize the amount of code visible on screen. I wrote my own memory block allocator for the interpreter to provide access to additional RAM space, among many other hacks. But more importantly I made most of the features of the SDK accessible from Lua scripts, which means it was then possible to write or read persistent files, draw any kind of figures on screen, create user interfaces using native UI components, use advanced math features, send data packets through USB etc.
The project quickly got a lot of interest inside our small community: now you had a third option for coding, offering excellent performance, lots of advanced features and it was very easy to start with. It was the first time I built a tool incrementally based on user feedback instead of building it just for me. Even the maintainers of the SDK and official apps followed the project closely. Eventually I moved on and never got the chance to actually implement everything I had in mind. I learned a lot, had lots of fun, and this experience has been key to the identification of my ideal career path.
Thanks Bob! :-)