• 2 Posts
  • 47 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle







  • Yeah that’s actually funny. Calling it FRAGS is just the icing.

    Now that it’s less broken, I’ve been playing Cyberpunk a lot and it feels like edgy shit done correctly. All the big tough guys are actually just weirdos enamored with the sound of their own voice, the ads are ludicrously over the top, it’s bloody, and everyone’s a human being. I haven’t felt gross with any of the content in it so far and it has at least as many strippers as Duke 3D had. I think the loud edgelords keep trying to paint it as free speech vs censorship but it’s really about not making players complicit in whatever infantile world view the director has.



  • Nah this is still corpo bullshit. It’s also one of the tamer specimens of that era. The only difference is, the corpos in charge of advertising at that time were all sentient hardons who heard stories about how drugs are and peaked at 14. None of them lived in the real world and they just churned out knee-jerk sexist bullshit because they wanted to appeal to boys going through puberty and men that never left that headspace.

    <rant> A lot of the ads from that era are uncomfortable. Hell, a lot of the games were. It was rare to see a female character that wasn’t ditzy and helpless, a thinly-veiled copy of the writer’s mom, or exactly like a dude but hot. Those were the options. I’m not saying I needed every game to be a work of great literature with complex and tormented characters and copious backstory; I just wanted female characters in games that didn’t like someone doing a ventriloquism act with their fleshlight.

    I ended up chasing gameplay and trying to ignore how fucking awkward and immature most of the shooters were in that era and I don’t think I was alone. I think a lot of gamers grew up and drove the market in a slightly more mature direction. Some people blame woke bullshit, but for me it was just being utterly sick of how fucking juvenile everything was and voting with my money. There’s still a vocal minority out there that wants the good old days back, but I’d stop playing if the industry went back to exclusively 3xtr33m l33t 4ct10n d00d bullshit.

    Sidenote: I played the demo for some Cliffy B game a decade ago on my XBox and hard-quit and deleted when the guy on my comms told me to “fire a rocket directly up the bad guy’s poop chute.” I was in my 30s and Cliff was probably pushing 40 at the time. What the hell? Are we nine years old again? Then again, he was the guy that threw his cat into his scanner and posted a picture of it every day until the internet told him to stop. Ugh. Let’s never go back there. </rant>


  • As someone whose employer is strongly pushing them to use AI assistants in coding: no. At best, it’s like being tied to a shitty intern that copies code off stack overflow and then blows me up on slack when it magically doesn’t work. I still don’t understand why everyone is so excited about them. The only tasks they can handle competently are tasks I can easily do on my own (and with a lot less re-typing.)

    Sure, they’ll grow over the years, but Altman et al are complaining that they’re running out of training data. And even with an unlimited body of training data for future models, we’ll still end up with something about as intelligent as a kid that’s been locked in a windowless room with books their whole life and can either parrot opinions they’ve read or make shit up and hope you believe it. I’ll think we’ll get a series of incompetent products with increasing ability to make wrong shit up on the fly until C-suite moves on to the next shiny bullshit.

    That’s not to say we’re not capable of creating a generally-intelligent system on par with or exceeding human intelligence, but I really don’t think LLMs will allow for that.

    tl;dr: a lot of woo in the tech community that the linux community isn’t as on board with







  • If you’re trying to pull your weight, and it sounds like you are, the problem is either with the tasks, the codebase, or the teammates:

    Potential problems with the tasks:

    • they’re not researched sufficiently
      • is this doable?
      • should we we even be doing this?
      • have we actually thought about how hard this will be, or did someone say “well that should be trivial” a bunch?
    • there’s not enough info on the tickets
      • inexperienced leads tend to just shit out tickets with zero info and underpoint them
    • they’re not broken down into small enough pieces
      • are you working “implement X” tickets while everyone else is working a series of “implement X: step N” tickets?

    A ticket needs: clear repro documents (if necessary), screenshots, and clear steps to reproduce. It needs more than “Title: Add X to Y. Description: We need Y in X. Implement it.” unless you’re intimately familiar with the codebase. And even if you are, you still need a paper trail to back up what you’re doing. If you’re not closing tickets, be very chatty in the comments. Share where you are, problems you’re running into, and who you’re waiting on for help. If there’s a consistent theme to the things you’re fighting, keep a list of them and bring them to your manager. Be your own advocate and be very transparent about all the research you’re doing because other people didn’t.

    Potential problems with the codebase:

    • someone preemptively optimized it
    • it’s not documented well
    • it’s spidery bullshit code that someone has deep emotional attachment to

    Hey, it works. But it’s not documented, someone decided to be clever instead of elegant, the local story sucks, or it’s optimized to such a degree that you have to refactor just to add a simple option ("lol why would we ever need that data here? It’s inefficient!)

    Potential problems with teammates:

    • they’re not supporting you
    • they’re grabbing easy tasks because you’re the “code whisperer”
    • they didn’t know what they were doing either so they’re vague when you ask them questions

    Everyone pulls their weight. Everyone communicates in clear, declarative sentences and provides examples if necessary. “I don’t know” is an acceptable answer. Evasiveness, vagueness, specialized jargon, or acronyms point to the dev being insecure about their knowledge in that area. Be very suspicious of the word “should”: “that should work”, “that shouldn’t be hard”, “you should be able to…”

    And, as an aside, I’ve seen this happen a lot. A new dev or contractor comes on, blows through tickets, gets good marks, and an existing dev or two get called out for not contributing with the same frequency. One of two things are happening here: the new devs are getting softballs, or they’re creating a lot of subtle tech debt that someone else will have to fix because they don’t have a full picture of the codebase. Eventually, those devs will be where everyone else is, but it’s still frustrating.

    Hang in there.