11 ms·

If an engineer can create a ticket and work on it, thats not reducing autonomy. Thats adding accountability. If documentation requires a pull request / merge t

• carlisle_ 4y ago
  Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?
  • mr-ron 4y ago
    It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it. This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example). Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.
    • carlisle_ 4y ago
      We’re still talking about updating documentation right?
      • mr-ron 4y ago
        I think we started there but have extended into a different discussion as to 'why is jira important to engineering teams'.
        • carlisle_ 4y ago
          I think you made that leap, but I was responding to the specific example. I don’t think anybody is contesting the use of tickets in engineering, but I’ll certainly oppose the idea that Jira is important.
      • azemetre 4y ago
        I'm explicitly referring to internal docs for the engineers that no one outside the team sees or cares (unless they want an example of docs). They're mostly markdown files or adding annotations to various code. I still think it's inane and seeing all the justification for "believe in the process" it's no wonder how little truly gets done in the name of agile/scrum/control.
  • treis 4y ago
    It's not a lot of value but it's also not a lot of effort. At minimum it gives a little bit of visibility into what you're doing and why to the rest of the team. That's probably worth the 2 minutes it takes to create a ticket.
    • carlisle_ 4y ago
      For updating internal documentation? I think we should be careful to ensure we’re actually adding value when we add friction, and not just hoping.
      • mr-ron 4y ago
        What is the scope of this documentation change? Is this a quick edit, or is this a whole new tutorial for new engineers getting their stack up? How long is this going to take? Do you want an engineer every standup saying 'im working on documentation' without any accountability?
        • carlisle_ 4y ago
          You really want to add friction to completing those tasks? How long does it really take to complete any one of those things, and how is a ticket going to change the fact it probably needs to get done anyway? Why am I going to write a ticket for docs I can write in an hour and be done with? Why would you want the docs to stay out of date until a ticket is created, rather than just fixing them? Frankly I think you missed the point of the article. If you don’t trust your engineers to prioritize their own time when it comes to writing documents, you don’t trust them to do anything. You’re exactly a part of the problem that Will is talking about.
          • mr-ron 4y ago
            I dont really think you are grasping what I am saying. I want engineers to make tickets, and prioritize their time themselves. Creating a ticket to update docs is fine because it allows the engineer to set the scope, and define the audience. That said, I dont want an engineer spending days on a task that will not bring value, nor do I want work done that will fall through the cracks, or have duplicate work done. Asking an engineer to create a ticket to create documentation is not the hurdle you think it is.
• lostdog 4y ago
  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?"
  • mr-ron 4y ago
    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?
    • lostdog 4y ago
      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.
      • 4y ago