I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.
I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?
I have personally also tracked time on my personal projects. While not sure if it does bring much value, it is not a huge investment time-wise.
So what the super productive guy learns after a while is that they just need to "work overtime" and delay presenting results to get ahead. If this attitude starts pervading your team the productivity might start tanking too.
Situationally. With programming there are loads of different tasks. For some tasks I think time can be quite a good metric. Still, metrics matter and I think having lousy metrics is better than not having metrics at all. Of course you have to realize what purpose the metric has in certain situation.
I fundamentally disagree. Metrics don't live in their own world. They affect the world around them and incentivize certain actions. Bad metrics can produce bad incentives. There are certainly many cases where simply not knowing something is better than knowing something that's only partially right. However, that requires a level of humility and acceptance of one's limitations that can be hard to defend to others looking for straight answers to all questions.
But generally I think my main point stands. We need to be humble enough to sometimes accept lack of control (i.e. not using certain metrics/processes) rather than deluding ourselves by through certain metrics that really aren't very good.
Never mind that the task spec changed 5 times in those 3 days.
Because: 1) you know what you are lacking 2) you won't take action on wrong information.
But if you're a manager giving out raises to your team, taking no action (i.e. giving no raises) might seem a worse choice than using the unreliable data - and there's no expectation reliable data will arrive if you wait.
Happy employees, at a certain level of knowledge work, have a degree of autonomy.
Unhappy employees who could otherwise be happy employees are a waste of potential and money.
Having a clock on/clock off and a 9-5 butts-in-seats management style and incentive structure reduces perceived autonomy.
I don't agree with using it as a slur, but I do think it's an awful way to work in a creative field. Some of my most productive work happens as a direct result of my taking breaks - a walk here, a cup of tea there. All the while I'm thinking about the problem at hand. Time tracking discourages this of lateral approach in favor of brute forcing your way to the answer.
I would like to understand why on earth time tracking is against "genuinely good engineering practices".
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
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.
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.
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.
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).
For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.
But every time there’s a problem, you compromise and it creeps a bit more in the direction of ‘command and control’. And all those little changes add up to the results you observe.