• 4 Posts
  • 180 Comments
Joined 3 years ago
cake
Cake day: June 13th, 2023

help-circle





  • What’s funny is their attempts to rebrand Office have just fallen completely flat. Kind of reminds me of when Willis Group bought the naming rights to Sears Tower and all the Chicagoan’s were just collectively like, “Yeah, No. We’re still going to call it ‘Sears Tower’.” Hell, nobody that I know of calls it “Willis Tower.” Nobody calls Microsoft Office “Office 365”. Nobody is going to call it “Microsoft 365 Copilot.” This is just a huge waste of effort by a tech firm that has long since run out of ways to be innovative.




  • /*
    By all accounts, the logic in this method shouldn't work. And yet it does. We do not know why. It makes no sense whatsoever. It took three weeks and numerous offerings to the programming gods, including using one of the junior devs as a human sacrifice, to unlock this knowledge. DO NOT LET HIS VIOLENT AND UNTIMELY DEATH BE IN VAIN! Touch this at your own peril.
    --jubilationtcornpone 12/17/25
    */
    public async Task<IResult> CalculateResultAsync()
    {
         // Some ass backwards yet miraculously functional logic.
    }
    




  • First One:

    Big ASP.Net Core Web API that passed through several different contract developer teams before being finally brought in house.

    The first team created this janky repository pattern on top of Entity Framework Core. Why? I have no idea. My guess is that they just didn’t know how to use it even though it’s a reasonably well documented ORM.

    The next team abandoned EFCore entirely, switched to Dapper, left the old stuff in place, and managed to cram 80% of the new business logic into stored procedures. There were things being done in sprocs that had absolutely no business being done there, much less being offloaded to the database.

    By the time it got to me, the data layer was a nightmarish disaster of unecesary repo classes, duplicates entities, and untestable SQL procedures, some of which were hundreds of lines long.

    “Why are all our queries running so slow?”

    We’ll see guys, it’s like this. When your shoving a bunch of telemetry into a stored procedure to run calculations on it, and none of that data is even stored in this database, it’s going to consume resources on the database server, thereby slowing down all the other queries running on it.

    Second One:

    Web app that generates PDF reports. Problem was it generated them on-the-fly, every time the PDF was requested instead of generating it once and storing it in blob storage and it was sllloowwwww. 30 seconds to generate a 5 page document. There were a list of poor decisions that led to that, but I digress.

    Product owner wants the PDF’s to be publicly available to users can share links to them. One of the other teams implements the feature and it’s slated for release. One day, my curiosity gets the best of me and I wonder, “what happens if I send a bunch of document requests at once?” I made it to 20 before the application ground to a halt.

    I send a quick write up to the scrum Master who schedules a meeting to go over my findings. All the managers keep trying to blow it off like it’s not a big deal cause “who would do something like that?” Meanwhile, I’m trying to explain to them that it’s not even malicious actors that we have to be concerned about. Literally 20 users can’t request reports at the same time without crashing the app. That’s a big problem.

    They never did fix it properly. Ended up killing the product off which was fine because it was a pile of garbage.