Hacker News Reader

Comment by donatj | Hacker News Reader

This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I've done my best to actively ignore/subvert it, but it's coming up more and more.

It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell.

All that said, if anyone needs a Go dev ;)

View on HN

Simple fix: apply inner platform effect to your benefit. Either highlight a 'high level feature management tool' (trello/wrike/etc) different to your development workflow, or abuse the current tool by requesting very generalised tickets like 'standing outage prevention' (maintenance!). No one will reject that because the consequences are lots of revenue.

The problem is not creating tickets. It is the process around them.

Creating a ticket takes seconds and you can even build templates around them if you think they're time consuming. If you cannot report tickets your workflow is wrong.

Seconded. You should be able to create tickets or at least file an initial ticket that a PM can flesh out. Tickets (or any type of change control system including git) really serve two purposes. 1) To track what changed 2) To track WHY something changed. A dev should be able to look up your ticket a year from now and be able to untangle the logic in your code changes tied to that ticket. If your ticket only has a title, or the briefest of descriptions you'll find it hard to debug any issues introduced by this (and you'll also be going to dev hell)

git bisect + git blame I find usually more useful than verbose likely partially correct notes.

That doesn't scale to large or multiple teams.

That often tells What changed, but rarely does it seem to tell Why. When the logic changes (and tests too) because the sales team now needs Different Things, it's very useful to have a ticket.

That really assumes that

1) Tickets are detailed enough and have been for a long enough period of time.

2) The functionality that's to blame was implemented in one ticket.

Unfortunately, that's almost never true anymore for anyone.

Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html

One day I hope to find some place small that applies that by the 'book'.

My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before.

Found a typo in what is otherwise awesome writing, "loosing".

Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.

You could get overall progress even with separated boards.

Overall progress doesn't help us who have to open/close/comment on them. You wouldn't use a single issue tracker for five repos, how is this different?

Regardless, they wanted to switch once they realized how cluttered things became for non-devs as well.

As a developer, I love having tickets linked to changes! It makes it trivial to trace a git merge to a review and then the original use case.

This allows commit messages to be more succinct and technical.

Also, if your company is publicly traded in the US, there are requirements to document changes from SOX.

We're privately owned, but that is an interesting thought I'd never even considered.

Reply on news.ycombinator.com