Would you do time tracking for someone writing a script for a movie? Or for a painter? Writing code not only requires skill, it's a creative process. You not only need to think about what you write, but also need to stop and relax. When your mind is tired, you're going to write shitty code. It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow. Worst case scenario, everyone writes bad code, unnecessarily increasing complexity, making the code prone to failures and requiring more rewrites, more developers and more time to understand it.

I don't follow how that is related to time tracking.

I have used time tracking for personal projects and also professionally and I genuinely think that it can add value to my workflow, in a way that I can analyze how much I spend on certain tasks etc.

I would guess also painters and script writers track quite often track their time. I think some level of time tracking is good for almost any level of work. For example, if your goal is to produce paintings and sell them for living, you probably want to know how long does it take for you to produce something so you can see if you are approaching sustainability. Similarly if you write movie or tv scripts it is probably relevant whether it takes 2 months to write the script or 2 years. Some work is just structurally different so different approaches to time tracking make sense.

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.

> It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow.

I'm on the fence regarding this statement. If you are accumulating increasing amounts of fatigue by being there and writing bad code, then yes, go home, rest, and recover. But, optimal is the enemy of good. Write some shit code in your own branch, learn from the mistakes you made, so that the code you write tomorrow might be "the good code".

Movie scriptwrites are not getting paid per hour though. What they get paid for a script is unrelated to the time they spent.

I realised years ago that getting paid per hour is anathema to my enjoyment of work. I'd much rather charge per project (even if that charge is based on an estimated number of hours) then spend whatever time it takes to complete the project than work at an hourly rate and find myself staring at the clock.

Opposite for me! In my experience, being payed a fixed sum for a project requires a very detailed spec up front and still may lead to bickering about whether any issue is a bug or a feature request. Being paid by hour makes it possible to continuously adjust the project without either party getting screwed.

Do you think software developers get paid for completing the features or for the hours spent hitting keys?

Typically employed developers get paid per time (i.e. hourly or monthly salary). Contractors may be either per hour or a fixed sum to deliver to an agreed-upon specification.

With scriptwriting (and often art in general) you first develop the "product" and then try to find a buyer. This is IMHO not a feasible model for individual software developers.

> Would you do time tracking for someone writing a script for a movie? Or for a painter

If change the flattering comparisons then why not? Instead of someone writing a script for a movie, imagine it is someone writing sales copy. Instead of a "painter" presumably working on some masterpiece, imagine instead it is someone in one of those Chinese factories churning out still life 3265.

Most programming tasks are well understood - most programmers in big corporations are working on CRUD apps. The correct comparison is not to some highly creative process but to some semi-creative process. Sure the details might be different but in the main it can be well understood how long it takes to add crud screen 26.

I guess pg himself popularised the flattering "programmers are just like painters" nonsense: https://idlewords.com/2005/04/dabblers_and_blowhards.htm

It's up to you to choose a more creative engineering job that almost requires you to be a painter (or a screenwriter). Sometimes it's the jobs that are product-level slash engineering, sometimes it's purely engineering ones that require a lot of innovation. If you are a creative type and if you want to make your life more interesting, you will be attracted to these jobs.

It's easier going the other direction: what is time tracking good for ?

Tailorism was good for simple, repetitive and immutable tasks, where the only planned improvement would be the worker. If the task was to be revised, it would be top down from an 'analyst' that designs a new task and test it on workers.

What changed this perception ? Toyota like factories, and the idea that tasks should progressively evolve, workers can change their environment in non top-down ways. The metrics was not how much time it took to do a single task, but how much the whole pipeline was efficient.

It's just an example, but I think time tracking should be a relic of the past, as an idea that was too simplistic and too seductive to micro-managers to be really valuable.

From a throughput management perspective for more office-like work:

It's easy for one person to increase in time-tracked productivity in ways that decrease the aggregate productivity of the group they are in.

Sometimes, the person is happy with their own work and unhappy with everyone else's, and they have a blind spot because it's so hard to understand how improving their own productivity can slow down other people so much to be net negative.

But I've seen it, I think it's real. I think it's sometimes a very strong effect, which can make or break a business.

Just like manufacturing pipelines, people affect each other's work in non-linear ways that clog up the system.

As with pipelines, performance improvement lies in working with those non-linear dynamics well enough to reconfigure the system, so each person can excel at their best.

Because making software is like oneoff or small batch production as opposed to a traditional production line.

Engineering practices vary wildly depending on what type of engineering you are doing.

That's one of the problems they had when developing BS5750 and ISO9000 , "where do you hang the defect ticket" was one of the areas where they had problems - that was what the head of the BSI software quality project told me back when he was auditing a project I worked on ack in the 80's.

It increases anxiety and stress, which probably decreases productivity to a much greater degree than whatever benefits you'd get from time tracking.

I suspect the number one factor to a successful project is a happy, healthy team. I'm pretty sure there's a section in Peopleware that backs that up. I'd be really careful with any approaches that risk losing that dynamic (or preventing it from forming).