• morgunkorn@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    Don't look up has a pretty accurate depiction of what the billionaires will be able to achieve when the end of the world comes.

    And the series Mr. Robot did very well by showing realistic software and hardware all along.

  • Thebeardedsinglemalt@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    4 days ago

    The person in charge trying to coordinate the whole thing, who’s asking for status updates on a daily basis and jumps down your throat if you don’t respond in a timely fashion, takes weeks to respond when asked for critical input. Also…

    Leader: The world is going to end in 5 days, we need that product now!!!

    Programming team delivers a functional product.

    4 days later…

    Programming team: did our item save the world

    Leader: I haven’t gotten to it yet, I’ll take a look by EoD.

  • Wizzard@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    3 days ago

    The opening scene to Mission Impossible: Rogue Nation gives me work anxiety, with the Jeremy Renner as the manager who is shouting at the two people doing the work to work faster (repeatedly) and giving them directions but has no understanding of what they are doing. Then Cruise sweeps in with a new directive and it takes a few tries to get right, under an absurd deadline.

    • ramirezmike@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      5 days ago

      WHY DID THIS 3 POINTER TAKE FIVE DAYS

      YES YES, IT’S NOT TIME BUT WE ARE TRACKING IT THAT WAY BUT IT’S IMPORTANT FOR YOU TO NOT THINK OF IT THAT WAY WHEN YOU ESTIMATE BUT WHY DID YOU GO OVER THREE DAYS

      • jubilationtcornpone@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        3
        ·
        3 days ago

        Don’t look at me. I voted five. And then when the scrum master was like, “jubilationtcornpone, are you ok with it being a three?” I said “No.” But someone who thought they knew better decided it was going to be a three anyways.

      • normalexit@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        5 days ago

        Let’s all head to the conference room, so we can discuss the definition of a story point for an hour. I’d also like to talk about why we are behind schedule and our velocity is dipping. Let’s make it two hours.

        • vithigar@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          5 days ago

          Management where I work finally unbent and admitted that story points were time.

          …but also want to continue raising velocity in each sprint.

          • chilicheeselies@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            4 days ago

            Dont worry, they are unserious about actual results; they just care about the appearance of results that they can report up. Just start padding extra… Fucking story points…jesus… To each ticket. Now everyones charts look like their velocity increased. Dont worry, noone is actually measuring results.

            • vithigar@lemmy.ca
              link
              fedilink
              arrow-up
              1
              ·
              4 days ago

              That’s exactly what we ended up doing. Every story has now become one Fibonacci step higher than it would have been before.

  • 🔍🦘🛎@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 days ago

    Not programming, but the plot of Shin Godzilla was about bureaucratic red tape holding back the actual solutions.

  • Affidavit@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    5 days ago

    “Quick! Hurry! Scrum! 5 minute stand up team! We need to sort this crisis out NOW!”

    “Joe! The building is on fire! Move! RUN!”

    “No! We need to have a meeting first! SCRUM! STAND UP! AGILE! SILICON VALLEY!!!1!!!1!! When is the next sprint!?”


    Looking for a passionate, motivated team member to be part of a newly refreshed team created to replace an unsuccessful team (RIP) promoting our incredibly competitive product!

    • You must have at least 40 years experience working with Windows 11.
    • GENEROUS remuneration package!*
    • You need to be able to work 26 hours a day 9 days per week.
    • You will need to bring PASSION! ENTHUSIASM! EXCITEMENT! [synonym not found]!, and GRIT!

    *as we are a small start up, we can’t afford to pay wages, but when we are successful, we promise to write your name somewhere on an archived version of our website.

  • OhStopYellingAtMe@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    5 days ago

    Proj. Mgr: “We’re tracking our development work in this Excel spreadsheet on Teams. Be sure to update it regularly…”

    15 mins later.

    Proj. Mgr: “We’re tracking our development work in Azure DevOps. Be sure to update it regularly…”

    15 mins later.

    Proj. Mgr: “We’re tracking our development work in Smartsheet. Be sure to update it regularly…”

    15 mins later.

    Proj. Mgr: “We’re tracking our development work in ServiceNow Virtual Taskboard. Be sure to update it regularly…”

  • peoplebeproblems@midwest.social
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 days ago

    The project manager keeps asking for an update every 15 minutes.

    Not only do I feel this in my soul, I’ve been working for almost 13 years, and to this day, I’m still not sure what a project manager contributes.

    The only thing I can tell is that their job is to be the designated impatient person.

    • thefartographer@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      5 days ago

      I have a friend who was a project manager. He took the time to learn every platform used by his team, but held no pretenses that he could actually develop anything without the team. His main goal was filter all the horseshit from the stakeholders and higher-ups so that they wouldn’t overwhelm the team with minutia. By learning the platforms and observing the team developing, he could make accurate predictions on timeliness based on whatever arbitrary feature was being requested and he’d always answer “let me ask my team” before discussing deliverables if he wasn’t sure.

      The number of times that he explained in meetings that’s the team’s timeline didn’t change, but that the stakeholders’ expectations did and that introduced a new additional timeline was incredible. It’s unsurprising that he only lasted a year or two before his bosses started pushing for a promotion. Seeing him work made mean bit jealous that I couldn’t be on his team, but we work at different companies and I don’t want to join the private sector if I can be of benefit to public education.

    • xmunk@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      5 days ago

      Good project managers are invaluable. I’d much rather explain status to a sympathetic ear and have them reword it for diplomacy than try and directly advocate with executives - and I celebrate any customer communications I don’t have to be a party to.

      When PMs act like part of the dev team and handle the communication side of the project it lets devs focus on the important shit… and if your PM is asking for daily updates then they’re too green (or you’re too unreliable) to have built up a good level of trust. Nobody fucking cares if a project is delivered at 3PM or 4PM, so who the fuck cares about daily or hourly project updates - the status won’t be materially different.

      It’s like managers or fellow developers - good ones are invaluable and shitty ones make everyone’s lives harder… the difference is that PM seems to be a position that attracts do-nothing folks so it’s more likely you’ll get a shitty roll.

      • Clent@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        5 days ago

        They are the ones that talk to the customers so the engineers don’t have to.

        Often those customers are others in the same company.

      • bitchkat@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        5 days ago

        The really good ones understand they are in administration and leave technical things to the technical people.

  • IzzyScissor@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    The sequel is when the original programmers die and a new team has to come in and figure out WTF their code is doing or even supposed to be doing.

    • SneakyWeasel@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      4 days ago

      I am currently doing this right now, pharma code team gave me a whole program and now i need to find out how everything works…

        • SneakyWeasel@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          ·
          3 days ago

          Found a couple infinite loops that were causing systems to crash. Slowly coming along. Going to take a bunch of time to allow it to become operational again

        • naught101@lemmy.world
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          3 days ago

          17 bugs detected including 4 security threats, and we still don’t even know what the programming is supposed to do

  • UnderpantsWeevil@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    4 days ago

    Do I really need to open a ticket for this

    Yes

    UNIRONICALLY, ASSHOLE! IT’S THE FIRST THING YOU SHOULD HAVE DONE!!!

    Fucking “hey guys, we are bringing in someone from another department and they need to catch up. What’s the project looking like?”

    “I don’t know. Nobody wrote anything down and now it’s scattered across six didn’t PCs in various states of dysfunction.”

    IT guys think they’re all Michael Jordan right until they get the ball.

    • Kissaki@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      4 days ago

      There’s an alternative to creating too many tickets that only add overhead and then make it harder to get into the project. Creating a good amount of tickets.

      I took the OP reference as demand for ticket creation when they don’t make sense and only hinder development through unnecessary overhead. E.g. creating a ticket before a quick analysis, or creating individual tickets when one story/feature ticket would be enough. Or more specifically in this case, having to create one before fixing a critical blocker.

    • chilicheeselies@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      4 days ago

      I get the message here for sure, but imo tickets (while important) take a back seat to a rich commit history. Ifbthe commit messages and history are high quality enough, one can tell whats up with the code sinply by looking at the log.

      Tickets on the otherhand are in a secondary system. Of course, they can bind the work of multiple projects together. But honestly, has anyone ever been able to just reach the ticket history and know everything about a project without asking someone?

      • UnderpantsWeevil@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 days ago

        tickets (while important) take a back seat to a rich commit history

        I’ve found people who do one will manage the other with ease. But “oops! No ticket” is a canary telling me their commit log is going to be shit.

        But honestly, has anyone ever been able to just reach the ticket history and know everything about a project without asking someone?

        I’ve been able to find out the status of individual half-finished bugs off a ticket log and work/reassign it quickly. Without a ticket in queue, I’ll either discover the issue has been completely ignored or that multiple people pioneered their own boutique fix without talking to one another.

        • jj4211@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          4 days ago

          Problem in some teams are the respective audiences for the commit activity v. the ticket activity.

          The people who will engage on commit activity tend to have a greater common ground and sensibilities. Likely have to document your work and do code reviews as the code gets into the codebase and other such activity.

          However, on the ticket side you are likely to get people involved that are really obnoxious to contend with. Things like:

          • Getting caught up in arguments over sizing where the argument takes more of your time than doing the request
          • Having to explain to someone who shouldn’t care why the ticket was opened in the first place despite all the real stakeholders knowing immediately that it makes sense.
          • Work getting prioritized or descoped due to some political infighting rather than actual business need
          • Putting extra work to unwind completed work due to some miscommunication on planning and a project manager wanting to punish a marketing person for failing to properly get their request through the process
          • Walking an issue through the process to completion involves having to iterate through 7 states, with about 16 mandatory fields that are editable/not editable depending on which state and sometimes the process is stuck due to not having permission because of some bureaucratic nonsense that runs counter to everyone’s real world understanding.

          In a company with armies of project managers the ticket side is the side of dread even if the technical code side is relatively sane.

          • oo1@lemmings.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            4 days ago

            Haha, i’d write a thousand pages of documentation before entering ticket hell. I fact I do put a lot of information into the ticket - they still won’t read it though and i’ll have to repeat myself 15 times to 5 different people.

            The solution to this problem. . . I have no idea, but I’m sure they’ll appoint another delivery manager who will get hired by the ones who already know fuck-all to know less than them.

            I’ve found that the few managers who want documentation, get documentation, and the others who want tickets and “story points”, get tickets and fictional bullshit - in general.___

            • jj4211@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              4 days ago

              Don’t know about solving, but at least can see the signs:

              • If there’s a lot of layers of middle management between you and the head of the company
              • There are people with oddly narrow scope of responsibilities, a scope that doesn’t make any sense to be a dedicated full time job
              • Excessive numbers of “cute” acronyms to apply to everything and everyone
            • Kissaki@programming.dev
              link
              fedilink
              English
              arrow-up
              1
              ·
              4 days ago

              The solution to this problem. . .

              is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)

  • Phoenix3875@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    5 days ago

    An app that will save the world…and other fantasies that software developers tell themselves to feel important

    • chiliedogg@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      5 days ago

      The most important part of developing hacking tools is to have a UI that includes text scrolling really quickly with little beep, blip, and bloop noises.