If you asked a software developer to delete all of the code he's wrote in a day and if by any chance he would agree, would you believe he could get to rewrite
it in around an hour? Well, believe! And the reasons are pretty simple to get; is not because we are lazy people or because we like spending time just waiting for ideas to come...no!
The following content and list of activities we do besides actually sitting in front of a screen, will help you understand why there's more than meets the eye about this great job that is developing
Exploring
Generaly, 50% - 80% of the day is spent either reading or experimenting with code. 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.
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? 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.