• @[email protected]
    link
    fedilink
    3920 days ago

    I was a full time test engineer / QA person for a while. My motto quickly became “nothing ever works”.

    Pretty much any ticket behind a static copy change would have some problem or oversight. Sometimes even those would (did you account for very narrow view ports?)

    Good developers would take this feedback gracefully. “Shit, you’re right, I need to account for mobile users.”

    Bad developers would get defensive and upset. “We barely have any mobile users (me: did you check?). Alan already approved so I’m merging. I don’t want to waste time on this”

    • @[email protected]
      link
      fedilink
      1620 days ago

      As a dev I’ve been on both sides to be honest. Especially when there is pressure to finish the next task. I think it needs good planning to create enough time for these things.

      In the end bad devs will still shut you up about things they are not interested in fixing…

      • @[email protected]
        link
        fedilink
        2120 days ago

        I’ve done a lot of “then go get approval from the stakeholder to go ahead with this bug/problem”.

        If product wants it out now now now they can sign off on it not working on mobile, so when their boss has a fit about it I can point to the conversation where Ryan said it was fine.

        I’ve mostly worked at smaller companies though.

        • @[email protected]
          link
          fedilink
          318 days ago

          I’ve caught problems in code review and had to do this even.

          Often it’s reading it and realizing there’s a complicated edge case or they missed something entirely.

          Sure we can make a different ticket for that to move this along, but we’re getting product to agree first.

          • @[email protected]
            link
            fedilink
            -2
            edit-2
            18 days ago

            Sure we can make a different ticket for that to move this along, but we’re getting product to agree first.

            Ooof, I’m glad I never worked there.

            QA’s job should be to make sure the bugs are known/documented/prioritised. It should never be a roadblock that interrupts work while several departments argue over what to do with a ticket.

            Seriously who cares if the current ticket is left open with a “still need to do XYZ” or it gets closed and a new one is open “need to do XYZ”. Both are perfectly valid, do whichever one you think is appropriate and don’t waste anyone’s time discussing it.

            • @[email protected]
              link
              fedilink
              1
              edit-2
              17 days ago

              No one cares if you leave a ticket open due to a bug or incomplete feature

              Product sure as hell cares if you’re going to ship a bug or incomplete feature.

              Never worked at company that wasn’t the case in over 15 years.

              Product owns the work they ask us to do. We do their bidding.

              And we certainly aren’t allowed to just change the scope of tickets at our own discretion without checking in

  • @[email protected]
    link
    fedilink
    3320 days ago

    Me neither buddy, me neither…

    Falsehoods About Time: … Time always moves forwards.

    I had to learn this the hard way… I was working at a platform that pulled measurements from sensors. The sensors did not declare the timezone for the timestamps of the measurement and the platform broke down twice after daylight saving. The first time there were duplicated records which caused conflicts and the second one we weren’t handling impossible timestamps.

    • AggressivelyPassive
      link
      fedilink
      2320 days ago

      I had a client whose clock was just a few milliseconds behind the server’s, but due to timezone crap one hour in the past. And the signature was valid for one hour.

      If the network just happened to be too congested, the validation failed. The next request went through just fine. Took us forever to find out.

      • @[email protected]
        link
        fedilink
        English
        418 days ago

        I don’t really get why people use any time other than ms/seconds since the epoch for anything other than displaying that time to the end user. Having time just be a single number with no time zone shenanigans makes writing logic like that so much easier.

        • AggressivelyPassive
          link
          fedilink
          318 days ago

          Epochs aren’t that simple either.

          First of all, local time can be relevant, so you have to store timezone information somewhere anyway.

          Epochs are also somewhat iffy in regards to leap years or seconds.

          And finally: write me an SQL to retrieve all entries submitted in 2022 using just epochs.

          Timezones are annoying as fuck, don’t get me wrong, but simply ignoring them isn’t a solution either.

          • @[email protected]
            link
            fedilink
            English
            116 days ago

            I don’t really remember SQL, does it prevent you from using a range of values? I can understand why leap seconds would be an issue.

  • @[email protected]
    link
    fedilink
    2720 days ago

    Something I find helpful is to PR review my own code before I create the actual PR. It’s surprising how giving it a once over in a different setting to the comfort zone of your code editor can save you a bit of unnecessary back and forth.

    • magic_lobster_party
      link
      fedilink
      1019 days ago

      I do that all the time. Sometimes I even realize I missed an even more obvious solution to the problem or how to better communicate the intent of the code.

    • @[email protected]
      link
      fedilink
      English
      819 days ago

      Yep. This is the way. Also, you’d be surprised how many devs don’t run through their own QA steps before asking other people to verify.

    • @[email protected]
      link
      fedilink
      520 days ago

      I like to take any text and copy / paste it into a different editor. Inevitably, this changes the layout because of different font settings or window size or whatever else. Reading it in a slightly altered layout helps me catch a lot of tiny errors that my eyes otherwise glide past.

    • @[email protected]
      link
      fedilink
      5
      edit-2
      19 days ago

      It’s so fucking goddamn sad how rare this is. Personally I review changes when I push commits and review all changes personally before publishing the PR and requesting reviews. I’m a senior dev so I guess it’s just something that comes with time (if you care about the code you produce)

      I swear to fucking god every PR review I do for younger devs and contractors we have to use (guess what country they’re from), I swear they don’t even look at their own fucking code once they’ve written it, let alone perform any sort of critical analysis. thoughts about any missed use-cases/optimization/future application and evolution? Nah!! That’s what the PR is for right? 🤬

      As you said even just a quick once over make a big difference and somehow it’s not even close to common.

      Damn I need to quit

      • @[email protected]
        link
        fedilink
        4
        edit-2
        18 days ago

        This is my typical experience as well, too many people don’t do a code review of their own PR first.

        When I was a junior, I had this coworker who did all my reviews. I was doing my absolute best and wanted to show that I was learning, so I would review all my work before submitting it and think, how would he review and respond to this code.

        That just stuck with me and it’s my normal practice now.

        I eventually learned that’s not as normal as I thought. I also tend to give better code reviews than others.

        Edit: the other thing I do is check in with who will be reviewing my code well before I submit anything someone might think is weird and have a discussion about it before the reveiw. If it’s weird, there might be a better way unless were stuck due to technical debt or something, and doing that early vs at the end usually saves time.

    • @[email protected]
      link
      fedilink
      -320 days ago

      I wouldn’t do that, too much tunnel vision and biases. I just skim through and make sure everything makes sense. Especially naming and comments.

      • @Kissaki
        link
        English
        8
        edit-2
        19 days ago

        I wouldn’t do that, too much tunnel vision and biases.

        Absolutely not. Self-reviews are very productive. I can confirm this from my own work and my colleagues, who also find it so.

        You’re of course free to vary the degree and depth of self-review, but tunnel vision and bias is definitely not overbearing and diminishing in those situations for us.

        Someone else will of course see more, what you may not see due to tunnel vision. But that’s besides the point.

        • @[email protected]
          link
          fedilink
          -219 days ago

          Weird, never heard of anyone doing this. Aren’t your team self reviewing the code while writing it?

          • @[email protected]
            link
            fedilink
            819 days ago

            When you finish the final sentence of an essay or a report do you just submit it straight away? You don’t read it through?

          • @Kissaki
            link
            English
            519 days ago

            How do you self-review while writing? What do you mean by that?

            I see it as different phases of development, mindset, and focus. You inherently can’t be in multiple at the same time.

            1. Problem space and solution exploration - an iterative and at times experimental process to find and weigh solutions
            2. Cleanup and self-review - document your findings, decision-making, exclusions, and weighing, verify your solution/changeset makes sense and is complete (to intended scope)
            3. Reviews

            It makes no sense to be thorough during experimental and iterative exploration. That’d be wasted effort.

            After finding a solution, and writing it out, a self-review will make you take a systematic, verifying review mindset.

      • @[email protected]
        link
        fedilink
        419 days ago

        I just skim through and make sure everything makes sense. Especially naming and comments.

        What do you think a self review is?

      • @[email protected]
        link
        fedilink
        120 days ago

        I think it makes sense, but only after logging out for the day and coming back to it a bit either the next day, or after a weekend in the case of code completion late Thursday or early Friday.

  • @[email protected]
    link
    fedilink
    1220 days ago

    Falsehoods About Time

    Having a background in astronomy, I knew going into programming that time would be an absolute bitch.

    Most recently, I thought I could code a script that could project when Easter would land every year to mark it on office timesheets. After spending an embarrassing amount of…er…time on it, I gave up and downloaded a table of pre-calculated dates. I suppose at some point, assuming the code survives that long, it will have a Y2K-style moment, but I didn’t trust my own algorithm over the table. I do think it is healthy, if not essential, to not trust your own code.

    Falsehoods About Text

    I’d like to add “Splitting at code-point boundary is safe” to your list. Man, was I ever naive!

    • @[email protected]
      link
      fedilink
      520 days ago

      Rocket programmer (and engineer) here. Can confirm that time programming is hell. Don’t even start on DST.

    • @[email protected]
      link
      fedilink
      2
      edit-2
      18 days ago

      I’m sure many smaller companies had their own internal Y2K moment as they scaled and became a big hit, and realized they used a wrong datatype like int instead of long or something and shit was gonna break by XYZ date if they did nothing heh.

  • @[email protected]
    link
    fedilink
    419 days ago

    Hey I know this place! I filmed there it’s in northern Ireland, behind the camera there’s an Observatory kind of building (round thing).