Hacker News Reader

Comment by lostdog | Hacker News Reader

That ticket is just adding friction to getting things done. Why can't you track the pull request itself?

This one instance of friction might but seem like a big deal at first, but the attitude is what causes slow development and burnout. First there's this tiny process, and then why not add a few more bita of process on top, until finally your merge process takes longer than writing the updated documentation, and so people stop doing it.

Instead of asking "why can't you just do this process," you should be asking "why is this process necessary at all?"

View on HN

Imagine the inverse where you have a team of engineers working on their own projects. And you dont know who is working on what, or why. Because there is no pull request yet.

Who requested this change? What is the scope? Where is the upfront documentation?

Now imagine the PR is ready to be merged. Since the engineer doesnt like documentation (as you are suggesting) then theres little context into what this is doing, who it will affect, and what types of changes can be expected.

Now imagine those PRs create a bug and causes an outage. Where do you look to determine the context into why this decision was made?

Now imagine a dozen of these teams working on the same repo. How do you coordinate who is working on what and what types of releases need to be schedueled?

I don't know what to tell you. You're describing a highly dysfunctional organization with no autonomy and extreme micromanagement. The right answer to all your questions is "leave, and try to work for a good manager in the future."

It is useful to do project planning and task tracking at a high level. But it's counterproductive to open a ticket every time you want to take a breath.

I lead a highly productive team in a challenging technical area. I know roughly what team members are working on in a given week, and that's enough to do coordination. Individual engineers write good pull request messages, and supplement it with design or usage documentation when necessary, and that's more than enough to understand what's going on.

My comment above is describing a place that is all autonomy and no micromanagement to the extreme. Its a place I worked before I understood the value of upfront documentation.

The situation Ill describe as a good place to work is, you have tickets that are created (by engineers / product / business whoever) that are evaluated ahead of time, and the team determines if it will add value to the business /end user, scoped appropriately, and set up for success with timeline and work.

As many decisions as possible should be made by the team doing the work, and they should be empowered to change their process as necessary.

The micromanagement is implicit in your use of the word "you". "How do you know ... ?". Who is that "you"? If it's the person's manager, the answer is "because we talked about it in our 1:1 or on chat". If it's anyone else, the answer is either "don't worry about it" or "coordinate with the manager". It's good to have a plan for the week / month / whatever timescale, to help teams coordinate with each other, but you really don't need real time visibility into what a team is up to if you aren't on the team.

> Now imagine those PRs create a bug and causes an outage. Where do you look to determine the context into why this decision was made?

The PR? Whatever you'd write in the ticket you can just write there instead of splitting information between two places.

Reply on news.ycombinator.com