That was exquisitely well put. Nicely done.

I don't envy project managers who are responsible for tracking all our engineering shenanigans and trying to communicate trends to upper management. They have a hard, thankless job that probably needs to be done. But the tooling they so often inflict upon teams (I'm looking at you, Jira), is soul-deadening. Bug trackers are great. As soon as they involve a workflow with statuses more complex than backlog/to-do/doing/review/done, too much of the devs' job seems to involve keeping the task manager happy instead of building software.

I don't know where the happy medium is. I won't claim I know a better way. But I do know I've worked in shops that optimized for getting work done, and I've worked for shops that optimized for tracking how much work is getting done, and the former outdelivers the latter every single time.

▲

mr_toad 4 days ago | parent | next [-]

> I've worked in shops that optimized for getting work done, and I've worked for shops that optimized for tracking how much work is getting done, and the former outdelivers the latter every single time.

In the past I’ve attributed this to the people in those organisations. Some people like to get things done. Others just like to be doing things (and they don’t understand the difference).

▲

codeduck 4 days ago | parent | prev [-]

I've maintained for a long time that Jira (and similar tools) are where work goes to die.

	▲	Xss3 4 days ago \| parent [-]
		It really depends how you use it. My interaction with JIRA is read ticket, assign myself, add estimate, create branch, check out, do thing, put pr up, merge pr, next day after builds have run overnight i move the ticket to 'ready for test' and add the build number so QA can look at it. Overall its less than 5mins per day in general. For big tickets i wont touch it for many days, sometimes even a couple of weeks. Its better than qa messaging me to ask which build has the new feature they need to test.