Make it right
Once the code works, then make it right. Eliminate duplicate code. Split large methods into smaller ones that each only does one thing and at one level of abstraction. Spit classes into ones where each one only has one set of responsibilities and only contains the code for doing that. Use intention revealing method names.
This is called "refactoring." A great way to learn more about this process is to read the book Refactoring by Martin Fowler with a lot of input from Kent Beck. Although the title doesn't say so, the material is organized as patterns, repeatable solutions for improving the design of existing code. Refactoring is a key part of Extreme Programming (XP) and one of the main motivators for writing a lot of JUnit tests: First make sure all your tests pass, then refactor, then rerun your tests. If any fail, fix the code. Once all of the tests pass again, the code must work as well as it did before, but is now designed better.
Two of the contributors to Refactoring are Don Roberts and John Brant, now of The Refactory, who developed the Refactoring Browser for VisualWorks Smalltalk in the late 1990's as part of professor Ralph Johnson's (co-author of Design Patterns) program at UIUC. Today, we take it for granted that IDEs like Eclipse and WebSphere Studio Application Developer (and others) offer lots of automated refactoring features, but Don and John are the guys who started the whole thing. (Back then, I thought, "Why not just refactor code by hand?" This is what we all did at the time. Don and John were more visionary than me.)