In the past i have dealt with developer that make the car look like a Corvette even though when put on the road performs like a Pinto. Which means they spent 80% of their time on the GUI and 20% of their time on the content of the development. Which is "bass ackwards" and leads to developers getting a bad rapoire cause of a few "idgiots"
I just dont put alot of time or effort in developing the interface as it is fluid and can be easily changed with a few mouse clicks, drag-and-drop, or ultimately the delete. The content of the software is a different point in case and is almost always the opposite of the GUI.
This, and what Adam said above, is why I like the Visual Studio suite. When I build an application, I end up doing a little bit of both together. If its an application I need quickly, I can do nasty code and just tie functions to my display and make it work. If I need something more complicated, I can wrap it nicely like Adam's third example. Sometimes, I'll start with the quick and dirty so I can get some real working data on the form, and then after I get the project operational, I start refactoring the project as a whole to make everything cleaner.
Recently, a lot of my job has been taking Excel reports that were generated by our QA Manager running prebuilt stored procedures and plugging in data and automating them. So the GUI was already "built" because they had a layout for how the data looks. In the process of automation, I may move the report layout around a bit, sometimes to make it easier to code, and sometimes because I don't care for how they have their report laid out. This is one case where I would say the "GUI" was built first and the code tailored to it.
My other pet project is a monitoring service for multiple aspects of our production outfit. I'm not exactly sure what I want to see or what I may make it do, since there was never any scope. Most of the time, I'm sitting in my cube going, "Hmm, this might be interesting.." and then I start doing my mix of GUI and code until I figure out something I like. Once I've got a basic working concept, then I can refactor my code and adjust the GUI as necessary. But maybe my environment isn't standard, because I'm the only software engineer in the building. I have (mostly) unsupervised control over what I build, as long as what I'm doing is making the entire operation better or is solving a specific problem. I work best in this type of setup, because 99% percent of my time is spent with a whiteboard, my mind, and my compiler, and we're all pretty good friends.
I also understand the "code first, make it pretty later" train of thought, because I worked for a more standard software company several years ago. Multiple developers and a few QA personnel to try and break our software. In that environment, it was more helpful to take a problem and get the code to be as reusable as possible. Reason being: with multiple developers all working on different aspects of the same program, if you solve a problem and wrap it up, then the other devs can basically drop in the code you've written, and they don't waste their time doing it again.
All in all, the way you code is dependent on the project and the environment.