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.
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.
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.
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...
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 think the only known-length task is a completed task.
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.
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.
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".
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.
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