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.