Comment by pedalpete | Hacker News Reader

Comment by pedalpete | Hacker News Reader

Parent Full thread

I bet if you get them to REALLY think about it, they know they are not productive more than about 4-5 hours per day.

If they spend 20 minutes writing an e-mail, is that 20 minutes of productive time? I bet it's really only 5 minutes of what is considered 'productive', because they didn't write the e-mail for 20 minutes, they edited for 15, checked other e-mail, etc.etc. When they go to a meeting and it starts out with niceties, and talking about progress updates, etc. etc. Is that 'productive'? Necessary, yes, but productive? No.

We need to look at programming the same way. When I'm setting up my environment, I'm not being productive. When I'm researching a bug I'm fixing, I'm not being productive. When I try a fix and it doesn't work, I'm not being productive. When I'm looking up the most efficient way to write a method, I'm not being productive.

When I'm completely focused on coding, I'm at my most productive. I use a pomodoro timer, and if I really pay attention, I'm hopefully productive for 20 of the 25 minutes. If I get a few of those a day, I'm happy. That's the productivity of our job.

The sad trap I fall into is that if I've been productive for 4 hours in a day, I normally stop being productive, rather than continuing to push through, which I know I should do.

"When I'm setting up my environment, I'm not being productive. When I'm researching a bug I'm fixing, I'm not being productive. When I try a fix and it doesn't work, I'm not being productive. When I'm looking up the most efficient way to write a method, I'm not being productive."

All the activities you mentioned are part of what you're being paid for as a developer, so you should consider yourself to be productive while doing them. If your employer thought that setting up your environment wasn't an essential part of your job, they'd be paying someone else to do it for you. And if they don't want you to write crap code, then finding an efficient way to write a method is also an essential part of your job, and thus productive. And how can you possibly fix a bug without first researching it to figure out the exact conditions that cause it to occur? Even meetings are productive, provided that they allow people to come to an agreement on how to solve a problem (rather just being for status reporting that could be done better with an automated tracking system).

"When I'm completely focused on coding, I'm at my most productive."

What if that code turned out to be the solution to a problem that didn't actually exist? Would you still think you were productive just because you were completely focused on coding at the time?

Now, look at the other side: Let's say that during a meeting, you figured out that some piece of code that your company wanted you to write was completely unnecessary, and it saved them hundreds of hours and thousands of dollars. Wouldn't that be productive?

And if you refactor 1000 lines of code to do everything it did before with just 100 lines of code, is your productivity negative because you threw lines of code away?

As developers, we're paid to solve business problems, not just to generate lines of code.

I completely agree with a lot of what you're saying, but I feel there is a difference between what I 'produce' and what I'm paid for. As you say, I'm paid to solve business problems, so any time that I dedicate to not solving those business problems or improving the business is essentially not productive.

I'm not suggesting we count lines of code, but I'm only actually producing when the code I write makes it into a final product. If I spend 5 hours writing code, and then throw it all away, I'm not productive. When I re-write a bit of code, was I productive the first time and not the second? Was I productive both times? Does it matter what has changed between the time I wrote them both, or why I'm making the change?

Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business? I may not have, and therefore, that time was unproductive, or I may have added value, and therefore the time was productive.

Interestingly, it seems the definition of productive may be up for debate itself.

"If I spend 5 hours writing code, and then throw it all away, I'm not productive."

Writing throw-away prototype code can be very productive, since it's a way to learn about your domain and the problem you're trying to solve. It can certainly contribute toward making a better final product. If we're trying to solve hard problems, we can't expect to be able to come up with a perfect solution on the first try with no backtracking.

As Thomas Edison said about his numerous unsuccessful attempts to make a light bulb, "I have not failed. I've just found 10,000 ways that won't work." Each unsuccessful attempt got him a bit closer to being able to make a working light bulb.

"Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business?"

Speaking from first-hand experience, sometimes the code base you inherit is so bad that you can't add anything to it without breaking it. By refactoring, you've made it possible to add the new functionality to the code which your customers desperately need. You've also probably made the code more reliable, since there's less stuff in there to break in the future.

On the other hand, if you had code that worked perfectly and didn't require any new features, and you refactored it merely because it offended your sense of esthetics, then you were probably not being productive.

> Each unsuccessful attempt got him a bit closer to being able to make a working light bulb.

Wikipedia on the merger between Edison and Swan - "The lamp bulbs manufactured by the company were almost entirely to Swan's design."

I think that when you dispose of code to create a better solution, say to reduce from 1000-100 lines or throw away a prototype to build a real application it's productive.

It's like throwing away the scaffolding that was supporting a building during construction but is now redundant. It's like removing the stone from the sculpture that isn't part of the figure you're trying to create.

as a former journalist, I have to disagree that editing is unproductive time. Saying exactly what you mean to say is extremely valuable, well-invested time. "I would have written you a shorter letter, but I didn't have the time."

Concise emails really ease the workload by reducing inefficiencies.

Totally agree with this. I'm a software engineer and I would estimate that half of the time I spend writing emails is formatting. I believe this is productive as it takes less effort to communicate. The point here being that communication requires effort by two parties.

Reply on news.ycombinator.com