'jamin is a game development enthusiast, mixed technophile / technophobe, English mutt without any discernible relatives from Caucasus, and Los Angeles native.
@SebAaltonen My current pet theory is that modern LLMs are massively overfit to the data they're trained on. We just underestimate the scope of literal questions and answers that have been fed into training, and we lack the tools to properly measure overlap in the training and test data sets.
Reminder that all those hex colors (#ffffff) are compressed as sRGB, and doing math on them directly has awful results. Even just squaring the values before doing math and taking a square root of the result produces significantly better results (gamma 2.0).
Two small things that would make a big difference in life today. If you want to make content about the prisoner's delimma, don't... instead, make content about literally any other aspect of game theory. And if you want to implement any form of gamification, study game theory.
@tsoding So you write this function, but then you're like "damnit, this actually needs to be somewhere else", so you decide to set up a standard RPC and install a web server, but then you're like "man, this would be so much better if the database was here", so you install a database.
@thingskatedid We all use JSON documents, but I don't know many people who are good at _describing_ JSON documents. Any document with more than two layers of nesting is word soup.
@thingskatedid Baby steps at this point. Example inputs, expected outputs, and compare literal text. Document generation with constraint testing would be better. Writing effective documentation seems like a bigger problem.
Scrum is a cancer.
I've been writing software for 25 years, and nothing renders a software team useless like Scrum does.
Some anecdotes:
1. They tried to convince me that Poker is a planning tool, not a game.
2. If you want to be more efficient, you must add process, not remove it. They had us attending the "ceremonies," a fancy name for a buttload of meetings: stand-ups, groomings, planning, retrospectives, and Scrum of Scrums. We spent more time talking than doing.
3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
4. We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
5. I had to use t-shirt sizes to estimate software.
6. We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
7. Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
8. Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.
9. We paid people who told us whether we were "burning down points" fast enough. Weren't story points about complexity instead of time? Never mind.
I believe in Agile, but this ain't agile.
We brought professional Scrum trainers. We paid people from our team to get certified. We tried Scrum this way and that other way. We spent years doing it.
The result was always the same: It didn't work.
Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control.
But the best about Scrum are those who look you in the eye and tell you: "If it doesn't work for you, you are doing it wrong. Scrum is anything that works for your team."
Sure it is.
I hear you suggesting that we throw more computers at the problem, and hey, I even agree with you. It would be incredibly easy; you're right here and I have my laptop. But I don't see how I'll keep my job after this is reported to HR.