• FlashMobOfOne@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    18 days ago

    When it comes to project work, it’s the quality of work that matters, not the time spent. If someone produces good-quality work, it doesn’t matter how they manage their time.

    • Oth@lemmy.zip
      link
      fedilink
      English
      arrow-up
      6
      ·
      18 days ago

      Also, when developers have lots of cross-team and cross-skillset coordination that needs to happen, you can spend the majority meeting, documenting, and reviewing.

      Case in point; my Cloud team spends a significant chunk of time coordinating between backend and frontend, Ops, Firmware/Hardware team and DevOps.

      Product Owner wants a feature, specs how the feature should look in the frontend, and what the device needs to do when used. Backend has to spec the cloud logic and API glue between them. A feature might need support from DevOps if infrastructure needs to be updated, and Ops needs to know how the feature works to support customers.

      It’s a whole lot of talk and documentation so that the amount of time we spend coding is as little as possible. That’s a good thing. If you’re spending the majority of your time writing code, you’re probably doing something wrong.

      • FlashMobOfOne@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        18 days ago

        It’s a whole lot of talk and documentation so that the amount of time we spend coding is as little as possible.

        10000000000000%

        Employers should be psyched, not critical, when the time spent in executing is minimal.

      • Alexstarfire@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        18 days ago

        I love starting a project that involves multiple groups and none of the other groups are even ready to start. It’s fucking great.

  • BearOfaTime@lemm.ee
    link
    fedilink
    arrow-up
    6
    ·
    18 days ago

    Sigh.

    It’s the old “knowing which button to push”.

    I’ve spent days having discussions about a change that I understood incredibly well, and “just knew” wouldn’t cause issues… And fortunately we discovered through all these discussion, an edge case where the change would’ve caused a major outage.

    The reason business has extensive meetings and discussions is to uncover this stuff.

    The actual change is nothing more than clicking a button. But clicking the right one, at the right time.