Get it right, then get it...

When I was in college, university for you non-Americans, I worked a few jobs as a cook in restaurants. The biggest challenge in starting a cooking gig is to learn the menu, the cooking techniques, and how to prepare the food. Getting trained as a cook takes a good chunk of time and it's a daunting task to try and keep up with the pace of the restaurant and your coworkers. You usually start out as the slowest person who knows the least. You come in and know almost nothing about the business and then there are people making food at lightning fast speed flipping sautée dishes and chopping food like the cooks do on tv. It really makes the job a challenge.
The places I worked were distinct in their menus and kitchens, but in each of the places that I worked we had the same mantra to trainees: Get it right, then get it fast.
If you focus on making the item what it should be, and stay to that standard, you will produce it faster with practice. It takes a bit of time and it isn't exactly clear when it happens, but you get good at what you do. It's like one day you are that person flipping a flaming dish in a sautée pan--while not spilling a martini glass in the other hand, and chopping veggies quickly with a knife.
When I worked at the lesser known Jimmy John's, most of us who had been there a while could make a full sub faster than it took for a customer to walk to the end of the table.
Get bread, slice bread, pull bread guts, measure then spread mayo, fill with lettuce, add tomatoes, add meat, add cheese, fold sandwich, wrap, tape and give to customer.
We had learned the motions so well that we didn't need to think at all, the actions flowed out of us. We learned what the sandwich should be, then we learned how to do it as quickly and efficiently as we could.
The same approach works for developing software. If you focus first on delivering software that gets the job done, you can then work on making it fast, flexible, or whatever it is you want it to be, in addition to correct.
In the agile approaches, they call it refactoring. Refactoring is achieving the same results in a piece of software in an improved way from the original.
If you first lay down a baseline that achieves the results that you want, you have something that at the very least is correct. You can also build deep integration tests around that base and include it in an automated testing suite. If the tests are good, team members check in code in as granular segments as they can, and you run a continuous build server, the team can be confident that efforts to improve code will not cause any breakages that go unnoticed.
You then can work on making it better. I would suggest involving others in this stage, pair programming or small group design sessions will yield more than an improved piece of software. In my opinion, this is where people really grow as mentors and as programmers. Mentors are able to see things in others' code and share their experience, the learner is able to learn from the other. What happens after a group refactor is more than just making better code, you have people who learn from the experience who are more likely to write the code better the first time the next time they encounter that situation. There is also a good chunk of cross training in different parts of the product.