• 0 Posts
  • 118 Comments
Joined 1 year ago
cake
Cake day: August 18th, 2023

help-circle

  • I think that’s a little too simplistic. I definitely agree that “we can’t show you the evidence of why we made this decision but trust us” isn’t going to instill confidence in the community, but it’s not like the steering council is some unrelated board of executives. They’re all core developers, theoretically chosen for their dedication and contributions to Python as a whole, and it seems their granted power has made them anxious about showing favoritism among the most seasoned at the expense of upholding the community guidelines that keep the Python community a positive and welcoming place.

    I think a flawed decision was made, or at least the way it was presented was flawed, and that should be considered for the next election. Maybe the council does need to be totally overhauled, that’s a valid position. But this is their work, too, and imply they have no skin in the game is disingenuous.




  • Part of the problem is that we have relatively little insight into or control over what the machine has actually “learned”. Once it has learned itself into a dead end with bad data, you can’t correct it, only work around it. Your only real shot at a better model is to start over.

    When the first models were created, we had a whole internet of “pure” training data made by humans and developers could basically blindly firehose all that content into a model. Additional tuning could be done by seeing what responses humans tended to reject or accept, and what language they used to refine their results. The latter still works, and better heuristics (the criteria that grades the quality of AI output) can be developed, but with how much AI content is out there, they will never have a better training set than what they started with. The whole of the internet now contains the result of every dead end AI has worked itself into with no way to determine what is AI generated on a large scale.






  • To be fair, it’s a pretty common play. Company makes unpopular decision, walks it back, tries again a little later once the novelty has worn off and the MSM doesn’t care to pick it up again.

    I think this particular move is pretty ballsy with how egregious it is (especially considering that starfield didn’t do anything particularly outstanding to overshadow it), but I don’t doubt they’ll try it again. If people keep buying their games, where’s the risk? At worst they’ll still get a few dollars from those who, for whatever reason, buy it, and then it’s forgotten by the next time a game comes out.





  • 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.



  • Moderators will never be able to fully eliminate this problem because it is an inherent part of the behavior of a subset of humanity and humans are involved in the activities where this harassment takes place

    I’m not suggesting they can, I don’t think anyone is.

    If you expect every person you meet, online or in person, to respect the rules you are going to be disappointed

    I don’t, but I expect if someone starts yelling rape threats at a restaurant that they’ll be kicked out, rather than the waiter saying “well why didn’t you just move to another table?” The rules are there for a reason, there should be consequences if they are broken.