Counting hours doesn't make sense(danieltenner.com)
danieltenner.com
Counting hours doesn't make sense
http://danieltenner.com/posts/0002-counting-hours-doesnt-make-sense.html
40 comments
B is the key here.
The problem is that number of hours is too often thrown around as a comparison between two different people.
I'd argue that arises from the more frequently asked question of "Is employee A more productive than employee B?" rather than "was employee A more productive on Tuesday or Thursday?"
Employers certainly ask the first question when they're looking for salaries to dump.
The problem is that number of hours is too often thrown around as a comparison between two different people.
I'd argue that arises from the more frequently asked question of "Is employee A more productive than employee B?" rather than "was employee A more productive on Tuesday or Thursday?"
Employers certainly ask the first question when they're looking for salaries to dump.
Agreed, and I think we all know this, but none of the substitute questions he proposes approach anything resembling an objective measure.
I would say, the only valid objective measure is results.
That, interestingly, is what a couple of psychologists tried and succeeded in implementing at Best Buy, of all places. See:
http://en.wikipedia.org/wiki/ROWE
They seem to have been very happy with the results they got from that.
If you want to evaluate results, why measure hours?
That, interestingly, is what a couple of psychologists tried and succeeded in implementing at Best Buy, of all places. See:
http://en.wikipedia.org/wiki/ROWE
They seem to have been very happy with the results they got from that.
If you want to evaluate results, why measure hours?
"If you want to evaluate results, why measure hours?"
I dunno-- saying that you shouldn't measure time spent as long as people get their deliverables done feels like saying that you don't need to track where you spend your money as long as your business is making a profit. Time is a really valuable resource.
Most people suck at time management, and should get better. Most managers have no clue how much (or how little) their team works or how workplace variables (like office layout and team composition) change how people spend their time. Most managers aren't good at guessing what an appropriate list of deliverables for a given full-time employee. If they try to dole out equal workloads to two developers, what happens when the manager screws up on their time estimates? Renegotiation mid-week? How does Dev2 feel when Dev1 gets to go home early? Who gets the bugs/tasks that have risk associated with them? Does SeniorDev get harder/riskier tasks than JuniorDev? Does he get more tasks?
The ROWE concept reminds me of fixed-price bids from my consulting days. To successfully give a fixed price bid with the least risk, you have to do MUCH more careful cost analysis. With a ROWE system, you have to have a pretty perfect handle on the "cost" of the bugs/tasks you pass around (which, with most knowledge work, is nigh impossible).
Startups kick ass because (among other thing) the founding team really cares about what they're doing-- I think it's pretty rare for a founder to say on a Wednesday, "Well, crap-- I finished all of the stuff we said I'd do this week. I'm off to the slopes!". Instead, they say, "I'm on a roll and there is an endless to-do list. Time to hit the next item!".
Don't get me wrong-- I think the punchclock mentality is ridiculous. But I think we're throwing the baby out with the bathwater-- You should measure BOTH.
I dunno-- saying that you shouldn't measure time spent as long as people get their deliverables done feels like saying that you don't need to track where you spend your money as long as your business is making a profit. Time is a really valuable resource.
Most people suck at time management, and should get better. Most managers have no clue how much (or how little) their team works or how workplace variables (like office layout and team composition) change how people spend their time. Most managers aren't good at guessing what an appropriate list of deliverables for a given full-time employee. If they try to dole out equal workloads to two developers, what happens when the manager screws up on their time estimates? Renegotiation mid-week? How does Dev2 feel when Dev1 gets to go home early? Who gets the bugs/tasks that have risk associated with them? Does SeniorDev get harder/riskier tasks than JuniorDev? Does he get more tasks?
The ROWE concept reminds me of fixed-price bids from my consulting days. To successfully give a fixed price bid with the least risk, you have to do MUCH more careful cost analysis. With a ROWE system, you have to have a pretty perfect handle on the "cost" of the bugs/tasks you pass around (which, with most knowledge work, is nigh impossible).
Startups kick ass because (among other thing) the founding team really cares about what they're doing-- I think it's pretty rare for a founder to say on a Wednesday, "Well, crap-- I finished all of the stuff we said I'd do this week. I'm off to the slopes!". Instead, they say, "I'm on a roll and there is an endless to-do list. Time to hit the next item!".
Don't get me wrong-- I think the punchclock mentality is ridiculous. But I think we're throwing the baby out with the bathwater-- You should measure BOTH.
What does "results" mean in knowledge work? It's impossible to know whether the results could have been achieved faster or better if you had indeed measured hours. I'm not saying measuring hours is the only thing to watch, but you can't simply track a undefined concept like "results".
You mentioned further down that you're a manager.. results are whatever you've agreed with your team is the "deliverable".
So you might agree on having a set of bugs fixed, for instance, or agree on getting a piece of functionality implemented. I'm not an expert on ROWE, but as I understand it, the key is that you agree on results which you (as a manager) are satisfied with and which the team (who will produce those results) is satisfied with.
Then, you don't care about how many hours they work. At the agreed time, you expect the result that you agreed on. If it's there, no problem, move on to the next bit of work that needs to happen. If it's not there, then you can sit down with your team and figure out why (but avoid the all-too-easy accusation that "they didn't spend enough time on it").
Apparently this technique (along with a set of workplace practices that actively discouraged managers from trying to figure out whether their teams were actually working or doing something else) worked really well for Best Buy.
So you might agree on having a set of bugs fixed, for instance, or agree on getting a piece of functionality implemented. I'm not an expert on ROWE, but as I understand it, the key is that you agree on results which you (as a manager) are satisfied with and which the team (who will produce those results) is satisfied with.
Then, you don't care about how many hours they work. At the agreed time, you expect the result that you agreed on. If it's there, no problem, move on to the next bit of work that needs to happen. If it's not there, then you can sit down with your team and figure out why (but avoid the all-too-easy accusation that "they didn't spend enough time on it").
Apparently this technique (along with a set of workplace practices that actively discouraged managers from trying to figure out whether their teams were actually working or doing something else) worked really well for Best Buy.
I guess the difficult bit is when "results" are something like "build me a new web site". Taking on clients like those on a fixed-bid basis is a recipe for disaster.
That's one of the things that agile development should ideally give you (in practice, of course, it's never as easy as it sounds). You make short-term (i.e. per-iteration, often 1-2 weeks) commitments to get things done, and base the amount you commit to on the amount you got done in the past in that amount of time. Other than that, leave the developers alone and let them get their work done. That gives developers a reasonable target that they can be held accountable for, which tends to make everyone happier.
Longer-term commitments (we'll release in 6 months with features X, Y, and Z) on software projects tend to be impossible to make accurately or to live up to, so as an engineer it's impossible to really take them seriously or to be held accountable to them.
By making the commitments much smaller and near-term, they're much more reasonable and doable and much more likely to be taken seriously by all parties.
Longer-term commitments (we'll release in 6 months with features X, Y, and Z) on software projects tend to be impossible to make accurately or to live up to, so as an engineer it's impossible to really take them seriously or to be held accountable to them.
By making the commitments much smaller and near-term, they're much more reasonable and doable and much more likely to be taken seriously by all parties.
Since with engineers you rely on them estimate how long things will take, and the last thing you want to do is keep nagging them to decrease that time, it's easy for engineers in a non-startup company to lose the sense of "urgency" and get complacent with the estimates, adding buffers to make sure they are never late. How would you try to keep ever increasing estimates?
Ultimately, you have to work with people you can trust. If they trust that you won't suddenly spring some bad surprise on them, and if you trust that they won't artificially pad their estimates and slack off (which is very unlikely unless you're working with some really bad apples), there shouldn't be a problem of padded estimates.
If it's your company, you know what results are (you'd better!). No, you can't track that, but I'm not sure it's meanful to compare startup progress.
I have literally gotten as much done in 4 hours as anther teammate did in 2 weeks. (Fixed the same bug.) However, usually we don't have direct comparisons.
I wonder if breaking a team down into 2 sub teams that compete over 2 week periods to fix the same bugs might be an interesting solution. I suspect most people would be more productive, but less than twice as productive. However, you would then be able to directly pick the "best" output which could be vary valuable. Add in the ability to discover and drop unproductive people and you might have a net win.
Edit: Ok, you might also create a hostile, environment that is so stressful you force the most productive people to leave.
I wonder if breaking a team down into 2 sub teams that compete over 2 week periods to fix the same bugs might be an interesting solution. I suspect most people would be more productive, but less than twice as productive. However, you would then be able to directly pick the "best" output which could be vary valuable. Add in the ability to discover and drop unproductive people and you might have a net win.
Edit: Ok, you might also create a hostile, environment that is so stressful you force the most productive people to leave.
This type of experiment was done by the Peopleware authors. They are the source of many of the productivity numbers you see quoted for software developers.
Yes. The concept of the "10x developer" is one of those examples that describe the variance in productivity among software developers
http://forums.construx.com/blogs/stevemcc/archive/2008/03/27...
http://forums.construx.com/blogs/stevemcc/archive/2008/03/27...
Your experiment of creating 2 teams would be an interesting one. But I think one team should be given 2 weeks and the other team should be given 1 (or less), and they cannot know of the other team or that they're trying to solve the same problem.
If teams are in direct competition with each other, you get that sibling rivalry effect that almost tore Apple apart (Machintosh vs II).
If teams are in direct competition with each other, you get that sibling rivalry effect that almost tore Apple apart (Machintosh vs II).
I think this is partly the point of the article: when you're forced to rely on objective metrics, you will avoid some of the questions that distinguish good performance from great performance. That's one advantage of tiny companies, which don't have to rely on such metrics because everyone takes the company's overall performance as their personal responsibility.
How about milestones achieved? Anything but hours. I did the startup thing (worked at a successful startup) 10 years ago, and we did work long days -- but spent most of that time creating things from whole cloth that exist as commodities today. (Everything from fast search libraries to infrastructure tools.)
I don't believe that most founders need to work 12-hour days. Not anymore. It's not the hours -- it's your progress that counts.
I don't believe that most founders need to work 12-hour days. Not anymore. It's not the hours -- it's your progress that counts.
Milestones alone are often abused, too.
In startup work, people are invested and there's too little time and even less reward to compare what I'm dong to what someone else isn't. If someone doesn't deliver, someone else steps up and we move on.
In mature organizations, everyone is not running to the copier, and people begin to take notice of the terrain. Politics, unpredictability, and general people challenges are perceived as a drag on the system. As a defense mechanism, especially if incentives are involved, milestones are defined not for the common good, but to route around points of potential failure.
Milestones make it really easy for the offense to blame special teams and the defense to blame the coach after the team lost, even though they all celebrated success at different times during the game.
I agree, progress and outcome is what counts. And I think iteration and feedback loops are essential: yesterday's unrefined solution isn't the best answer tomorrow.
In startup work, people are invested and there's too little time and even less reward to compare what I'm dong to what someone else isn't. If someone doesn't deliver, someone else steps up and we move on.
In mature organizations, everyone is not running to the copier, and people begin to take notice of the terrain. Politics, unpredictability, and general people challenges are perceived as a drag on the system. As a defense mechanism, especially if incentives are involved, milestones are defined not for the common good, but to route around points of potential failure.
Milestones make it really easy for the offense to blame special teams and the defense to blame the coach after the team lost, even though they all celebrated success at different times during the game.
I agree, progress and outcome is what counts. And I think iteration and feedback loops are essential: yesterday's unrefined solution isn't the best answer tomorrow.
Basically, we need to relate working effectively with working efficiently. Another way to look at it is: is the person that spends 10 hours a day sitting at their desk any more dedicated than the person who spends 6? The person who spends 6 hours a day at their desk can potentially produce more results if they focus on effectiveness and efficiency (Parkinson's Law in effect), especially if the "dedicated" 10-hour-a-day person spends 5 hours checking email.
It's also a generational issue that everyone goes through at some point. The young people think the old people are "dinosaurs", and the old people think the young people don't have any work ethic. The focus should be on results, not hours spent.
It's also a generational issue that everyone goes through at some point. The young people think the old people are "dinosaurs", and the old people think the young people don't have any work ethic. The focus should be on results, not hours spent.
> is the person that spends 10 hours a day sitting at their desk any more dedicated than the person who spends 6
In my observational experience (in the non-startup work realm), with a few exceptions, the people who regularly work overtime hours tend to not work enough during the regular 9-5 hours.
In my observational experience (in the non-startup work realm), with a few exceptions, the people who regularly work overtime hours tend to not work enough during the regular 9-5 hours.
Observation: Many of these are the same people who were night owls in college, and often would work the same amount of hours if allowed to come in at noon. :)
I've recently started using the Pomodoro Technique (which was linked to on HN a few months back), and I've found tracking the time I spend very helpful for my self-discipline--preventing myself from getting into that fugue state where I'm looking at the browser, going click, click, click, click, and then realizing that six hours have passed and I've accomplished nothing.
But I absolutely would not want my manager to use this kind of information to evaluate my performance.
But I absolutely would not want my manager to use this kind of information to evaluate my performance.
While I'm certainly in the "work smarter not longer" camp, to suggest speed, and therefore efficiency, doesn't matter to business is shortsighted.
How much you accomplish in a given timeframe affects everything - from perceived worth to how much you can charge.
Time is money, whether you like it or not.
How much you accomplish in a given timeframe affects everything - from perceived worth to how much you can charge.
Time is money, whether you like it or not.
I am a stay at home entrepreneur and oftentimes get this sort of flame from my girlfriend or relative. There just isn't a way to measure my work on a per hour basis. The fact is when you fully commit yourself to perusing your own ideas and passions, as mine being web development, you begin to notice that most of the day becomes consumed with the tasks at hand. On most occasions I find myself think through my ideas as I do common chores around the house, even when spending time getting physical exercise. How do we measure this time as productive? The ability to to measure productivity must be in ones ability to set and meet deadlines, yet continue to improve the output quality.
The ideal is to define, project and measure time, cost, scope and risk when trying to achieve a goal, however, there is a cost associated with each measurement (lets call it COM):
results = measurement of scope; time spent = measurement of time; cost expended = measurement of cost; risk observed = measurement of risk
When Cost + COM(results, time, cost, risk) > benefit of goal, you cut back on costs or measurement or lose money.
When (Observed Risk w/ Measurement - Observed Risk w/o Measurement) > COM(results, time, cost, risk), you measure everything. Otherwise you find an optimization of what to measure and what not to.
Something like a lawyer, its expensive to measure absolute results a lot of times, so measuring time makes sense. Similarly, a software contractor working on an ambiguously defined scope is probably best to measure hours, as the expected results may be unclear.
In a large organization, the COM(results,time,cost,risk) is often much less than the prospect of losing sales due to project delays. It increases overhead, but it may be the most rational choice to measure everything. In particular, measuring time is critical, because it can serve as a metric to accurately estimate the perceived risk of the next project.
In the case of a tech startup, Mr. Tenner is probably right on, because measuring results vs project scope is more straightforward in a small team, however, measuring risk, and time is expensive. You take your best guess at risk, keep your costs as low as possible, then measure your results to make sure you are on the right track.
results = measurement of scope; time spent = measurement of time; cost expended = measurement of cost; risk observed = measurement of risk
When Cost + COM(results, time, cost, risk) > benefit of goal, you cut back on costs or measurement or lose money.
When (Observed Risk w/ Measurement - Observed Risk w/o Measurement) > COM(results, time, cost, risk), you measure everything. Otherwise you find an optimization of what to measure and what not to.
Something like a lawyer, its expensive to measure absolute results a lot of times, so measuring time makes sense. Similarly, a software contractor working on an ambiguously defined scope is probably best to measure hours, as the expected results may be unclear.
In a large organization, the COM(results,time,cost,risk) is often much less than the prospect of losing sales due to project delays. It increases overhead, but it may be the most rational choice to measure everything. In particular, measuring time is critical, because it can serve as a metric to accurately estimate the perceived risk of the next project.
In the case of a tech startup, Mr. Tenner is probably right on, because measuring results vs project scope is more straightforward in a small team, however, measuring risk, and time is expensive. You take your best guess at risk, keep your costs as low as possible, then measure your results to make sure you are on the right track.
This article completely ignores the effect of teamwork.
Most knowledge work is done in teams. Only the team's results latency and results throughput matters. However, an individual's total throughput ("results per unit time") is only one variable in the bigger equation.
As an example using "bugs fixed" as a substitute for results, an individual who can fix a 10 hard bugs a week working only 8pm-12am might not be as valuable as someone who only fixes 5 hard bugs a week but is around 9am-5pm to e.g. mentor junior employees.
As usual, the real answer is "It depends and you should manage your own situation according to your own circumstances."
Most knowledge work is done in teams. Only the team's results latency and results throughput matters. However, an individual's total throughput ("results per unit time") is only one variable in the bigger equation.
As an example using "bugs fixed" as a substitute for results, an individual who can fix a 10 hard bugs a week working only 8pm-12am might not be as valuable as someone who only fixes 5 hard bugs a week but is around 9am-5pm to e.g. mentor junior employees.
As usual, the real answer is "It depends and you should manage your own situation according to your own circumstances."
You can't change definitions on the fly!
If fixing bugs is the "result," then fine. But you can't penalize the guy who fixed 12 but didn't mentor anyone over the one who fixed 5 and mentored junior employees, because then you're redefining what a result is to include mentoring.
It's OK to expect different results from different people, but you need to let them know that.
If fixing bugs is the "result," then fine. But you can't penalize the guy who fixed 12 but didn't mentor anyone over the one who fixed 5 and mentored junior employees, because then you're redefining what a result is to include mentoring.
It's OK to expect different results from different people, but you need to let them know that.
I despise most of my employers for their focus on hours, and in fact I left a job last week that had me working long hours despite the actual quantity of work assigned to me.
But, ironically, I use hours as an objective way to measure my own work. I use a time-tracking program similar to what freelances would use so I can get an exact breakdown on time spent per day, as well as by project. My actual coding time is there, as well as time spent answering support emails, and time doing things that support the continuing growth of the business.
Sure,sometimes a whole day flies by and I check the tracker and I've spent 10 hours actually working. But on days when I'm less motivated, it's sort of a game to rack up an hour here, 15 minutes there, and still manage to get a lot done.
It's a really good way to spur yourself into tackling a bug/feature/challenge that you'd otherwise procrastinate. "OK, I have no idea where the hell to begin, but I can at least spend 30 minutes diligently investigating the matter. If I'm nowhere closer, I'll stop then and work on something else." Then you might find that a few hours fly by and the problem is solved.
As long as you're brutally honest with yourself in tracking your time, and don't allow it just to become a procrastination mechanism (tracking time on things that really aren't constructive but seem sort of "productive"), it's a great way to measure yourself.
But, ironically, I use hours as an objective way to measure my own work. I use a time-tracking program similar to what freelances would use so I can get an exact breakdown on time spent per day, as well as by project. My actual coding time is there, as well as time spent answering support emails, and time doing things that support the continuing growth of the business.
Sure,sometimes a whole day flies by and I check the tracker and I've spent 10 hours actually working. But on days when I'm less motivated, it's sort of a game to rack up an hour here, 15 minutes there, and still manage to get a lot done.
It's a really good way to spur yourself into tackling a bug/feature/challenge that you'd otherwise procrastinate. "OK, I have no idea where the hell to begin, but I can at least spend 30 minutes diligently investigating the matter. If I'm nowhere closer, I'll stop then and work on something else." Then you might find that a few hours fly by and the problem is solved.
As long as you're brutally honest with yourself in tracking your time, and don't allow it just to become a procrastination mechanism (tracking time on things that really aren't constructive but seem sort of "productive"), it's a great way to measure yourself.
As a manager, especially when I'm not coding in the project, I need some way to know how hard the engineers are working, and whether there's anything I can do to help them be more productive. I have no doubt there is a clear correlation between hours worked and results produced. I think as long as you give engineers the flexibility in their work schedule, I can't imagine not counting hours.
"I need some way to know how hard the engineers are working"
You get what you measure.
If you really want to know how many hours your engineers are sitting in front of a keyboard and screen in your office, you can find a way to get that information. If you tie compensation to that figure, your engineers will definitely give you plenty of butt-in-seat time (or quit).
If you do not have other ways to evaluate their output, though, you may not get much more than that. They might just read Hacker News all day. You can put in measures to block Hacker News, but at that point you have an escalating battle of not trusting your employees and putting in increasingly draconian measures until you have created a call center environment where your employees have a set number of minutes a day they are allowed to go to the bathroom, and have to get really good at holding it otherwise.
How many good developers do you think will be left at that point?
I did jump over some points along the continuum there. But the point is, if you do not have some level of trust in the relationship with your developers, you're probably screwed anyways.
You get what you measure.
If you really want to know how many hours your engineers are sitting in front of a keyboard and screen in your office, you can find a way to get that information. If you tie compensation to that figure, your engineers will definitely give you plenty of butt-in-seat time (or quit).
If you do not have other ways to evaluate their output, though, you may not get much more than that. They might just read Hacker News all day. You can put in measures to block Hacker News, but at that point you have an escalating battle of not trusting your employees and putting in increasingly draconian measures until you have created a call center environment where your employees have a set number of minutes a day they are allowed to go to the bathroom, and have to get really good at holding it otherwise.
How many good developers do you think will be left at that point?
I did jump over some points along the continuum there. But the point is, if you do not have some level of trust in the relationship with your developers, you're probably screwed anyways.
"I need some way to know how hard the engineers are working."
Why? And what does "hard" even mean? (working more hours?) The goal is good results, not hard workers.
"...clear correlation between hours worked and results produced."
Working zero hours will produce zero results, so there is obviously a correlation, but this correlation cannot be linear, and may not even be positive in all cases. I would expect working 100 hours in a week would would make for worse results than 40 hours.
Hours are not a measure of output, or efficiency, or results; they are a measure of time.
Why? And what does "hard" even mean? (working more hours?) The goal is good results, not hard workers.
"...clear correlation between hours worked and results produced."
Working zero hours will produce zero results, so there is obviously a correlation, but this correlation cannot be linear, and may not even be positive in all cases. I would expect working 100 hours in a week would would make for worse results than 40 hours.
Hours are not a measure of output, or efficiency, or results; they are a measure of time.
My point is that there's it's very difficult to measure the productivity and "results" of knowledge work, and you need to look at all the data. This includes looking at hours worked, plus the quality of the end product, the way they work with others, the clients impression, and the success of the product in general. This is a complex problem the requires a holistic approach.
"My point is that there's it's very difficult to measure the productivity and "results" of knowledge work, and you need to look at all the data. This includes looking at hours worked..."
I agree with jimbokun: measuring "time spent" can be useful in many cases, but it does not measure productivity or quality of work. I understand how difficult it is to measure productivity, but the answer is not to use a poor metric just because it's handy.
I agree with jimbokun: measuring "time spent" can be useful in many cases, but it does not measure productivity or quality of work. I understand how difficult it is to measure productivity, but the answer is not to use a poor metric just because it's handy.
I'm going to take the opposite position of the last post I made and give some reasons for measuring hours worked.
It is important to track hours worked per feature or bug in order to improve future estimates. You also want to know if things are taking longer than expected, and why. You may also want to know if finishing and committing fixes and features too quickly leads to more bugs and maybe encourage developers to take more time and get it right the first time.
Is this the kind of thing you have in mind when you want to measure hours worked? That I can certainly agree with.
It is important to track hours worked per feature or bug in order to improve future estimates. You also want to know if things are taking longer than expected, and why. You may also want to know if finishing and committing fixes and features too quickly leads to more bugs and maybe encourage developers to take more time and get it right the first time.
Is this the kind of thing you have in mind when you want to measure hours worked? That I can certainly agree with.
> As a manager, especially when I'm not coding in the project, I need some way to know how hard the engineers are working
You could just ask them in a clever manner, you know.
You could just ask them in a clever manner, you know.
I like where this post was going, but I don't thing it got there. Energy is a factor, but what about the value of one's effectiveness? It's not merely time, or energy that gets things done, it's effectiveness.
If I have all the energy in the world and all the time I want, it does not follow that I'll get more done. If I'm into what I do and I'm good at it (talent + interest) I'll be more effective and that's of much greater value than how much time and energy I put in on a given day.
If I have all the energy in the world and all the time I want, it does not follow that I'll get more done. If I'm into what I do and I'm good at it (talent + interest) I'll be more effective and that's of much greater value than how much time and energy I put in on a given day.
What about counting calories consumed by the brain? I don't know how one could do this, but it seems sensible. You get a lot of credit when your brain is hammering away, and nearly none when you are dozing off in front of the screen. Also, if you can't do home projects at work, all the cerebral intensity would be expended on work projects. The worst that could happen is that the worker focuses on details rather than on the big picture.
Disagree. If you measure hours for yourself it’s very healthy. You know what you do and when. They help me a lot. ("Ah, it’s 3pm, I never get anything done in this timeframe. I think I go outside.)
Measuring the time of others is worthless, to that I agree.
Measuring the time of others is worthless, to that I agree.
Maybe I'm missing the point, but what's a good measurement of energy expenditure? You can't reflect on 6 months time and come to any helpful conclusion without data to analyze.
How much time you spend is correlative with productivity. Most of my really productive weeks are where I log an unusual number of hours in my dev environment. I think the relationship between # of hours and productivity is especially strong when:
A) Looking at a longer period of time (certainly there are raredays where you're in TextMate all day but don't get anything meaningful done, just as there are days where you destroy a critical problem in 30 minutes)
B) You're comparing to yourself. Comparing your work-month to mine isn't very meaningful. Comparing a month of my data the middle of our YC experience versus a month of data in the middle of our fundraising efforts vs a recent month of data is interesting.
But I also think that the sheer # of hours is a really interesting measure of engagement, motivation, and workload. If you're only really working for 2 hours a day, chances are the issue is with that rather than with your ability to be productive.