Could you (as a software developer) delete all of the code you wrote in a day and rewrite it in around an hour? Chances are your answer is yes. Why is that? Is it because developers are lazy, overpaid jerks? I would argue that it is because there is a lot more to our jobs than meets the eye. Knowing what activities we spend our time on and understanding the benefits and drawbacks of each can help us become more effective. I believe we spend most of our time exploring, designing, verifying, and writing code.
Exploring
One Friday afternoon I asked some craftsmen at 8th Light, "What percent of time do you spend exploring code vs percent writing code?" The answers I received varied a little, but all weighed the exploring aspect heavily. The typical response was 50% - 80% of the day is spent either reading or experimenting with code. Is this activity important enough to warrant that much time?
Spending a lot of time exploring is necessary to crafting an elegant application. Coding is like putting a puzzle together. Sure you can jam pieces together that look like they might work, but that will screw up future pieces. You end up spending more time studying the board and experimenting with available pieces then you do actually fitting the right pieces together.
Designing
The design process can be either beneficial or wasteful depending on how it is executed. Some companies spend entire weeks or months designing their application before writing any code. Other companies understand that requirements for projects are volatile and design accordingly. Often that means quickly mapping out a simple and flexible mental model of how things should work, then writing tests to drive the final design.
I would compare the design process to having a long term relationship with somebody. You don't plan out your living situation, schedule a wedding date, and decide how many kids you will have before your first date. You get to know the person, make a mental model of what you want your relationship to be like, and make adjustments as you go.
Verifying
Some companies have entire QA departments to verify that code is working. Yet even with a QA team, it is still the developer's job to verify that his/her code works. There are many ways to do this. You could build a suite of unit, integration, generative, acceptance, and any other type of tests. You could also manually verify that the code works. Typically the best approach to verifying code is a combination of those outlined strategies.
If you rely on one style of verification you aren't verifying your code effectively. Building unit tests for everything is awesome, but it will likely miss edge cases. Integration tests are awesome, but they can be extremely slow. Manually testing your code should always be done at certain points, but is far to time consuming to do it with any regularity. Relying on one style is like having all sorts of tools to get a job done, but only using your favorite.
Writing
Most developer job descriptions say that you will get paid if you write code. So should we strive to always be writing code? You might've guessed by now that I don't think that should be our goal. Just because we are writing code doesn't mean we are adding value. In fact, sometimes we take away value by adding bad code to a system.
If you spend enough time exploring code, designing solutions resistant to changing requirements, and implementing varied testing strategies, the code you write will likely add a lot of value (thus being an effective use of your time). You will know that you are working effectively when you can delete all of the code you wrote in one day and rewrite it in around an hour.