Ignoring coffee, table tennis and window watching, I reckon that a programmers time is:
70% reading research material
20% thinking really hard
5% trying to remember how the solution you implemented yesterday worked (you're sure you saved a backup to VC, but....)
5% writing new code that doesn't work
<0.1% writing code that ends up being used (for the next few months)
For reference over the past three /days/ at a fulltime programming job I've got ~50 lines of code (LOC) ready for review. It's supported by ~500 LOC that I've knowlingly discarded (dead end solutions), probably >2000 LOC that I wrote that never worked at all (compile errors/), 2 pages of written documentation/decision making, and ~5 pages of (typed) scribbled notes.
What do you reckon your ratios are like?
3 years ago
(2) At home, say when working on my search engine I'm about probably 60% writing code and 30% trying to figure out why the code I wrote doesn't work (and 10% repairing the tests I broke). With some exceptions. Some pieces of code are just 99% staring at code trying to figure out why it isn't behaving well, and 1% slapping my forehead and going "well duh!". But that's usually complicated bit twiddling stuff. · 3 years ago
Really depends on what I'm doing. (1) At work I'm probably 70% trying to find the code that's causing the bug (in some far-off library maintained by, well, that's what I'm trying to figure out), 20% trying to repair unit tests and 10% writing new code. · 3 years ago
For me, if code that I've written/copied off of some other part of the program that eventually makes it in is 10 parts, then code that I chucked out is 25 parts, me banging my head on a solution is 75 parts, reading other bits of code for solutions is 150 parts and background digesting of thoughts is ~375 parts. Sometimes I get confused about what I was originally doing and have to spend some more time recovering from that too. · 3 years ago