You're talking about two completely different levels of granularity. It's fine to discuss "what did we accomplish this month" and try to quantify it. It's not fine to ask a script writer why they didn't write any lines between 8:30 and 9:00 this morning.

Personally the software development tasks I have been doing are quite often separable in tasks that take several hours. Sometimes there are tasks that take days without clear separation.

I think asking whether it is discuss "whether you did line this amount of lines within X hours" is more like management and workplace culture than software development issue. It seems that people here are fed up with their managers and funnel that bad feeling against time tracking. In my opinion time tracking is valuable tool and should be used in principle almost everywhere. Bad managers of course make any type of work a pain.

I always found a strong disconnect between what the business side thinks is meaningful and what an engineer and his technical manager finds meaningful. Typically the detailed granularity just isn't there and the data is really noisy as well.

More of late I've thought it'd be better to look at the rate features are added and ignore 'hours' completely. As in Bob seems to be able to complete one hard feature a month, or three medium features. You got to ask, do you care how many hours bob worked? Not really.

Heh, presuming management knows what a hard feature looks like. Or understands the reason why it is hard. They sometimes conflate a patch, a hairy patch or writing correct code from start.

Bonus points if said manager does not understand that writing tests makes one go faster rather than plugging the code and trying to run scenarios manually...

One of the things I now always do is tell my boss both how much work work somethings going to be and how 'hard' something is going to be. Features/changes that are hard have very unreliable estimates. A lot of that has to do with how difficult it is to reason about and debug the feature. And how much other stuff needs to be changed.

When I know ahead of time exactly what the code I’m about to write will look like, I takes this as a warning sign and check in with myself.

Why do I know exactly what this code is going to be? Is it because I’m doing something repetitive? I’m a software developer. My job is to make the computer do the repetitive parts, not get paid for spending four hours doing something we’ve done ten times before.

Mastery isn’t doing more, it’s about being more effective. You develop intuition. And the way your intuitive brain surfaces warnings is as discomfort. If you cultivatea sensitivity to this discomfort it means you are adverse to powering through. On some level you “have to” address this issue instead of tolerating it. You have to scratch.

Now you’re not doing rote work. How long will it take? Who knows. But it’s less time than doing this thing eight more times this year. And it’s not just time. It’s energy and face. A repeated process that can introduce human errors makes you look like a clown to your customers, and your boss’s boss.

I also sometimes track time, so I know how long takes particular task. Good developers do this and can quickly estimate project’a complexity by breaking it into known length tasks. I saw this in a highly specialized consulting company. My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow. This time tracking thing can become very ugly in micromanagement environment.

> known length tasks.

I think the only known-length task is a completed task.

Known exactly, maybe. But when I was a consultant we had a pretty good idea of how long it took to do a good job on a project.

We'd add in some padding because you don't know if something will need a bit more research or if the lead is going to come down with the flu or whatever. You write deadlines that are under the client's control, rather than yours, into the contract.

So you don't know exactly. But if you have a decent handle on the scope of work and aren't trying to solve wide-open problems, you can usually get pretty close.

Certainly, a lot of people don't have this level of experience in a domain. When I do similar work internally at a company now, people are often surprised that I can come up with time estimates (and meet them) pretty easily.

You know how long your budgeted for it. Which is fine up to a point, but when things go over budget then corners get cut. And that costs in time further down the road.

I suppose you can always spend more time but the type of work I did didn't create downstream dependencies. There was no maintenance. (It was reports, competitive analysis, and the like.) Although I can't ever recall a situation where we were like:"It's not good. But it's good enough. Ship it."

That’s the kind of work that can be automated. You’re arguing with people who are doing new feature development almost exclusively. These are apples and oranges.

And frankly if you get too smug about it in a work environment you’re going to antagonize someone into scripting your job out of existence. So I wouldn’t pull on this thread too hard if I were you.

When a task is of known length is the time to automate it.