• azertyfun@sh.itjust.works
    link
    fedilink
    arrow-up
    81
    ·
    edit-2
    8 months ago

    Real back-end requirements: when x, y goes in (in JSON-as-an-XML-CDATA-block because historical reasons), I want you to output x+y+z+æ+the proof to P=NP.

    æ will require you yo compile x+y in CSV, email it to Jenny, who will email back the answer. She doesn’t quite know how to export excel sheets though so you’d better build a robust validator. No, we don’t know what æ is supposed to look like, Rob from Frontend knows but he’s on vacation for the next 8 months.

    The request must be processed under 100 ms as the frontend team won’t be able to prioritize asynchronous loading for another 10 sprints and we don’t want the webpage to freeze.

    And why does your API return a 400 when I send a picture of my feet? Please fix urgently, these errors are polluting my monitoring dashboard and we have KPIs on monitoring alerts.

    • soggy_kitty@sopuli.xyz
      link
      fedilink
      arrow-up
      21
      ·
      8 months ago

      Clearly fake. No task ever includes anything but the happy path. Loading or failure states are a myth

    • evatronic@lemm.ee
      link
      fedilink
      English
      arrow-up
      16
      ·
      8 months ago

      output x+y+z+æ+the proof to P=NP.

      I’m sure there’s an npm module for that.

    • RonSijm@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      8 months ago

      Yea, fair enough. My point was mostly: backend requirements are usually at least objective. “Json xml comes in”, “CSV goes out by email”, “The request must be processed under 100 ms”, “API should not return 400 on feetpics” - these are still mostly objective requirements.

      Frontend requirements can be very subjective “The user should have a great user experience with the frontend”

      • azertyfun@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        8 months ago

        Hahaha that’s what frontend devs think, but the backend requirements are just as vague: “Just make this button work”. In my example all the requirements would actually be figured out bit by bit over months, nevermind the prescience required to foresee future architecture-breaking features or scaling requirements. At least you can make a mockup and get instant feedback, flawed as it is.

        On either side it takes experienced engineers to suss out actual requirements from customers/PMs. The main difference is that the backend (especially on the infra/devops side) is only accountable to itself if everything goes well, but ironically that means no-one knows or cares about the amount of engineering that goes into keeping PMs blissfully ignorant of the risks and complexity.

        • RonSijm@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          8 months ago

          Hahaha that’s what frontend devs think

          Hahah, well as a primarily backend developer, that’s what I think as well.

          “Just make this button work”

          If that button doesn’t work, that sounds like a frontend problem to me… ;)

          But yea, as you mentioned, it probably comes down to experience. As the meme from this post depicts. When I dabble in frontend and make a WinForm for my devtool, people just look at me and are like “Uhhh, can you make it better?”

          No sir, clearly I can not. And I have no idea what you mean with “better”.