• 0 Posts
  • 22 Comments
Joined 11 months ago
cake
Cake day: August 18th, 2023

help-circle

  • I think we generally agree, but I worry that a new platform couldn’t do more than GoG+Lutris already do. Perhaps, though, it could be done with a reputable foundation.

    And the lawsuit is more or less what I was radio referring to with Steam’s price rules. I would definitely be on board with striking the requirement for publishers to offer the same price on all platforms at the same time.

    On that note, though, I wouldn’t take the whole case at face value, as I think parts of it are pretty frivolous (unless they prove that Steam is actually actively stifling competition and, you know, not just a decent platform that entered the space first.) I also think it’s silly to point out Epic’s lower commission rate since they’ve been giving out free games like candy and actually making third party games exclusive to their platform in a very clear attempt to compete with Stream. There’s absolutely no guarantee that they won’t raise their commission once they have a foothold in the market (though I do concede that their licensing terms for Unreal Engine have remained fairly reasonable).


  • On the one hand, yeah it’s absolutely important not to idolize any company, because they have no sense of loyalty or generosity. Telling yourself otherwise is a guaranteed path to disappointment.

    On the other hand, of all the shit sandwiches we’ve been served, Steam is one of the fresher ones. Though they developed Proton for their own benefit, it’s pretty undeniable that it has made gaming on Linux way more viable than it has ever been, and it’s open source. I mean no shade to FOSS solutions like Lutris, but having paid developers work on a project full-time certainly has its advantages.

    I do think that the concerns about Steam’s pricing rules are valid, as are gripes with its DRM for first party games. But, overall, they’ve brought a lot of convenience to PC gaming that is hard to find elsewhere in the gaming world.


  • I definitely agree, but that’s true of any system. The particulars of the pitfalls may vary, but a good system can’t overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don’t always know what will be complex and what will be trivial, so they accept the effort we assign to items.


  • Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it’s a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I’ve been exposed to. No days or weeks of design meetings, just “hey we want this feature” and it’s in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.

    Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

    I’m not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.

    A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

    Again, not sure how shipping with bugs is an agile issue. My understanding of “fail fast” is “try out individual features to quickly see if they work instead of including them in a large update”, not “release features as fast as possible even if they’re poorly tested and full of bugs.” Our team got itself into a “quality crisis” while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.

    The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book “Impact Engineering,” conveniently available on Engprax’s site. Not to say this necessarily invalidates the study, or that agile hasn’t had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he’s no hack when it comes to engineering.






  • I had such high hopes for HBO Max as a bastion for animation before they got completely fucked. They nuked Summer Camp Island (a very wholesome, charming, and slightly weird show) right before its final season came out, delaying the premiere more than a year and with zero notice to its creator, Julia Pott. Pott implied as legally as she could that the season would get out there one way or another, so either someone at CN has a heart or her threat worked.

    And to this day they deny that Summer Camp Island, OK KO, Infinity Train (one of CN’s top performing shows!), and others even existed, while cutting funding for even more shows. I’m still devastated, we had a beautiful revival in the 2010s, but now there’s barely anything new on at all. So many up and coming creators utterly shafted no matter what network they work with.

    All we really have left is Prime and Netflix, and god knows those aren’t reliable. What a mess…







  • I base my opinion here on my experience with the Python discord, which is probably one of my favorite haunts these days. It excels at helping newbies, of which there are many each day, because their questions are quick to answer and can be handled almost instantly by any decently experienced active user. It’s the more specific or advanced questions that languish there, because it’s less likely that someone experienced with that particular domain will happen to be online. It doesn’t need to concern itself with archival quality because no one expects answers to be referenced later.

    So I think both types of communities can play to their strengths without diminishing their quality. The chat rooms can answer the simple, open ended questions that don’t bring value to SO’s database of knowledge, and the more complex and advanced questions can have a better chance of being seen and answered with valuable insight on SO.


  • I think the issue is that, as a new dev, you also have no idea where to go for the type of help you need, and SO is always at the top of the search results. I’ve found that discord servers are better for helping newbies because it allows more experienced users to interactively teach them how to ask questions and how to read documentation. Handing someone a URL and saying “look it up” is pretty helpful for a newbie, but that’s discouraged on SO since answers are much more permanent and links degrade over time.

    Maybe SO needs some way to direct those who “don’t get the site” to a more chat-room like community where they can get their very common questions answered quickly rather than posting a duplicate question that no one wants to take the time to fully explain in a single answer.



  • I don’t think the length of program matters so much, especially with type hints making it easier to maintain larger projects.

    That being said, it’s pretty well known in the community that distributing any kind of end user software is a nightmare with python (though there’s a small group of people who insist that it’s not that hard to get people to install python to run their program. Those people are nuts).

    The biggest reason I use python for as many projects as is practical, though, is because it has an incredible community that I love to interact with. Unless I truly need something to be scalable, python is always going to be my hammer of choice.


  • I’ve learned to be very judicious about using libraries only if they’re well established (unless I’m working on a personal project and don’t mind taking a chance with a smaller library). I do think one should think very carefully before adding a dependency, especially in webdev where you have a million bloated frameworks that have a handful of things you actually need. That being said, a trusted dependency is better than trying to reinvent (and maintain) the wheel.