For me, preparing data for my unit tests takes a big chunk out of my time. For example, I spent hour after hour squeezing out logical expressions, such as "('A'='B') OR (1+1=2)", for my expression evaluation function; yet I'm still unsure if the test data covers every obvious bugs.

So let's share What yours are and what you do to overcome them.


Definitely debugging. Some hard find bugs can take a lot of time. Especially if you have blinders on and you're missing something that should be obvious.

Writing plumbing code used to take up a lot of my time as well, but since more and more .Net libraries are being released that solve those problems (data access, logging, etc.), it's not as bad.


Thinking. I spend a lot more time thinking than doing anything else. There are a lot of activities that facilitate this, by giving my mind a break from concentrating on the code, e.g.

  • Making cups of tea
  • Going out and buying a coffee/sandwich/whatever
  • Compiling
  • Reading blogs
  • Answering questions on forums

But ultimately everything comes back to thinking.

Oh, and of course, I spend some time writing code too.


Trying to decipher 300-line methods in uncommented legacy code.


Redoing previous work because of clients that change their mind.


Documentation and estimation


Working with my peers - in addition to designing/writing code, I actively guide, pair with, or otherwise help my peers become better engineers. It is an investment that pays off in the medium to long run.


Meetings. Verbose, endless, pointless talking-shop meetings.


Answering questions on SO.

Ok, it's really debugging.


Reporting and documentation.
For every single change to the codebase, i have to:

  • write the commit-log
  • Update the project status tracking tool
  • Update the wiki

Filling out timesheets and other general admin.


I actually spend a lot of time refactoring and optimizing code. Quite enjoyable :-)


Write code and talk with people involved in project.

Kind Regards


Being interrupted by others and recovering from said interruptions.


Sorting through user feedback and bug reports.


Writing well-thought out functional routines, be it Lambdas or functional languages or SQL (especially when it's complex,over many tables, lots of potential indexes, etc)

It goes hand in hand with that quote (forget the citation, but it's not me) that when writing code, you should 'spend more time thinking than typing.'

The reward from having something so concise and powerfull is worth it though - and it gets easier over time as you begin to think in those terms more naturally.


The most of my time consume the support for the customers. The most causes of the support are bugs that we have not find because we have to few unit tests.

If you spend 30% of your time for testing then you can reduce the support time in the future.

Look in the code coverage to find cases that are not tested. A pattern like 1+1=2 seems me very simple. Exotic values are more interesting. like -1+1=0, 0+0=0, 3+NaN=NaN, etc.


1) Listening to a client that wants "some minor change" that usually means that I have to rewrite 50% of code.

2) Trying to reproduce a problem while debugging... it always crashes in production, it always works in test.


Figuring out what the output should be. Not exactly debugging in my case (as rather complicated text processing system)

  1. Debugging
  2. Changes resulting from requirements changes
  3. Changes resulting from design changes
  4. Changes resulting from QA beating the crap out of my program. (didn't do #1 enough).
  5. Inane meetings/conference calls

For my current project, globalization and localization.


3D development:

  1. Debugging
  2. Documentation
  3. Deployment (building Setups)

Checking corporate boxes, answering Very Important Email (!) that should have been filtered by my management, trying to get equipment in my lab to test like the delivery platform, jumping security hoops imposed by the defense department. Filling out timesheets down to the 0.1 hour. Going to useless meetings that could be summarized in an email for most. Jumping process hoops. Fixing defects that never would have made it to production if we had been doing unit tests, continuous integration, and automated regression testing.

You know. Fun stuff.


Deciphering QA bug reports.


Understanding what the customer want and finishing his concepts (and consider the technical points).


All the paperwork, approvals, sitting in a "design" meeting where the business owners are only nit-picking about the most pointless and marginal aspects of the system.


What?... Nobody codes here?

My most time-consuming task as a developer is always coding.

Nobody say "time-consuming" should be bad.

And when I say, coding, I don't mean I write for 4 hrs. and then test. Not at all.

I would say that I code for some 5 - 10 minutes.. then 1 minute of testing or see if I got what I wanted, but I don't see that as two separate task but one. There are time when I spent 4 hrs coding.


Communicating takes the most time for me. I find some developers who consume all their time coding and spend no time communicating (even simple things like writing comments in their code, or worse, not typing useful check-in comments!) end up wasting other people's time. It's tough to decide whether communication or lack of communication consumes the most time.

We use FogBugz to centralize communication between developers, managers and clients. Sometimes this feels like a lot of overhead, especially when the issue is a quick one line of code change behind a long case history (or a long explanation to be typed out after making the change). I'm not complaining though, FogBugz is great!


Writing designer/unit tests easily takes the most amount of time for me. I think many developers (including myself) often underestimate the time it takes to properly test something, ensuring that:

  • The component behaves as expected
  • Corner cases are adequately tested
  • Backwards compatibility isn't broken
  • Performance isn't affected

In my experience, all of this can sometimes take longer than the original implementation.


Checking in files. We use a web-based client and have to copy over changes for each file separately using something like Beyond Compare as opposed to simply merging.

Boy do I hate checking in files.


I maintain over 500 client websites written in ASP or ASP.NET. I spend alot of time getting them to work properly on vista machine with VS 2003, 2005 installs... Oh and there is Com objects that won't run on vista.... painful.


Estimation, proposal writing, contract/legal stuff - all prior to the project even getting approved.


Refactoring. Just when you think you've finished a writing a function, you realize you can write it a much prettier way.


Trying to explain my diagrams to people who have no clue what I'm talking about. People who want me to give them an ETA without them giving me resources or budget. People who would only understand me if I could show them something that doesn't exist yet!