ta_1138
There's also all kinds of not necessarily intended communicaton from the guessers in the fact that you can listen to which words they were considering and didn't pick. Nothing in the game attempt to say that you should not consider, say, whether they were going in the right or wrong direction in their guessing, but it sure can make a difference in how to approach later clues. If they were being very wrong, there might be a need to double up on words that you intended, and that your guessers missed.
In the same fashion, nothing in the game saying that I cannot listen to those guesses as a member of the other team, whether guesser or spymaster, and then change behaviors to make sure we don't hit words they considered as candidate words without very good reasons. Let them double dip on mistakes, or not make their difficult decisions easier. It's not as if the game demands that everyone that isn't currenly guessing should wear headphones to be sure they disregard what the other team says or does.
Even in less obvious cases that don't involve old age, we often call something growth, when we should just say change. Sometimes we are all just more set our ways. Others, our "learning" is just abandoning principles so that we can follow random emotional fancies. Knowing when we are actually seeing the world more accurately, instead of being wrong in a different way, is quite challenging. We all want to think we are getting better, which is precisely whi we are blind to the ways in which we aren't. The convenient story often defeats what is actually true, but inconvenient.
Insurance, in a vacuum, detached from an industry is a perfectly sensible way to try to spread risk. And as you say, this fair, reasonable insurance isn't about getting extremely rich, but about being the best at identifying where the risks are, and using market power to lower costs. But with healthcare, and especially with the US peculiarities, we manage to get minimal value out of it.
People getting care don't know their options, and how different the pricing can be. Insurers are capped by a percentage of services paid, so they really are happy if everything is very expensive. Providers band together into conglomerates that make sure it's hard for insurers to lower reimbursement rates. Pharmacy benefit managers build complicated schemes that let them take a bigger piece of the pie. They even purchase pharmacies, and restrict the expensive purchases for themselves, while the local pharmacy is squeezed. All in all, it gets very expensive, with minimal control of spiraling prices, and nobody that can lower costs is incentivized to do so.
We blame insurers because that's the people that get paid first, but yes, it's not really a matter of just insurers. It's a kafkaesque system that is basically impervious to significant reform. And for good reason: Every dollar we overpay is someone else's salary. A decrease in costs per person for the same care to match, say, Spain would involve a whole lot of people making a lot less money, including many losing their jobs. Not exactly a political winner, even though the country would be better off with more efficiency
I was also told that there were attempts to make the economic simulation far more dynamic, simulating that the cargo could leave by other transport methods, as you'd find in a more serious economic simulation. That just made the game worse: The more efficient the market gets, the harder it is to find the profit, and the more likely that an old 'good' route suddenly stops making money, which is just annoying in a single player game.
It's a common problem with market-centric games: Good simulations make everything unfun, as most of the enjoyment comes from easily finding opportunities or getting away with misbehavior that would make real-life barons very difficult. This is IMO why you don't find many spiritual successors: Most steps forward would be steps back when it comes to making the game fun. So you'll find games focusing just on the tracks, but as puzzles (like the Train Valley Series). Optimizing routes trading items (spaceways), or outright market manipulation (Offworld Trading Company). Doing it all at once basically demands copying the game with newer graphics.
What you describe is ultimately just a principal-agent problem. In a world where the banks have no government protection, it can still be positive for people working at the bank to do things that are very risky for the bank. We see companies do crazy things that hurt them, but help people that work for them all the time.
Saying it's the government's fault is like blaming greed, or capitalism, or the banks. It's just principal-agent problems all the way down.
If you know you were getting all your social needs met at work, and now you don't, the companies that have moved back to the office should be a godsend for you. So why don't you just change jobs?
See the situation in modern indie videogames: Today a small team does what used to take a huge team a couple of decades ago, but you still have projects that have so much budget you cannot touch them with a small team, and difficulties getting good, small games to find audiences, as they need to deal with a different set of gatekeepers. You'll need some influencer, a blogger, or some social network algo, which can be gamed, to give you exposure. Success without paying is not impossible, but the easy route is through paying. And how much will people pay? More than you want.
Even in a world without physical scarcity, if you want eyeballs and clout, scarcity will still exist because real fame and success is limited. And based on who are the most popular organic-ish influencers, you might not like the kind of person who wins.
Which gets us back to the most important rule of a software engineer's career: make sure that the person writing your reviews really likes you.
Often the end result is having just enough red tape to turn a 2 week project into an 8 month project, and yet not enough as to make sure it's impossible for someone to, say, build a data lake into a new cloud for some reports that just happen to have names, addresses and emails. Too big to manage.
Now, if on interview you pass rate is low, it's hard to say what you are doing wrong.
If you bought a house 15 years ago large parts of north St Louis, chances are you lost money, even without accounting for said home maintenance. They one I live in didn't go up 50% in 15 years. A lot of commercial investments? Ravaged.
So while it's true that it's possible to leverage yourself more in real estate, and that said leverage is even tax advantaged, assuming that the line will go up faster than anything else in a risk-adjusted way is a very risky position to take.
If the road from H-1B to permanent residency was shorter and more reliable, the advantages of the consulting companies would shrink.
The same as if we didn't end up having to rely on lotteries. Hiring a candidate and hoping for an H-1B is quite annoying if you don't have them on staff in another country, or they are working for you in the US from an F-1. Those consulting companies that have large offices in India can happily submit large amounts of applications of people they already have in India, and be OK with 2/3rds of them not winning said lottery. A smaller company just can't play that numbers' game
So you arent' overestimating how long it takes to memorize words, but how useful having a good, normal vocabulary in the language actually is for being good at scrabble. Go look at guides for English scrabble, and see the words you are trying to memorize.
Many of the crypto services believe that no, there's no way they'll do what the bank tells them and still remain useful to their clients. They'd have to compete with the truly off-the-regulatory-world competitors, and probably lose a lot of business there. So they get unbanked, in the same way that I'd get un-bared if I decided to keep showing up at said bar with the same clothes as Donald Duck.
There are areas at the edges where the mocking/stubbing required to really follow TDD cause make changes harder but never find bugs. There are entire families of bugs that are far better handled via strong types than by building tests. In the right languages, there's functionality where some kinds of tests are just testing the library, but hard red-green-refactor mandates tests with negative value. We all have been in situations where a small code change requires 6 hours of changing tests for reasons that weren't tied to the real reason the test was there, but ancillary reasons. There are tradeoffs.
When someone asks me whether we should use TDD on a project, the right answer depends on what it is, which language it's written, and whether we are mandating it across the entire codebase, or there are specific things where we will ignore the worst cases. Are we writing payment software in Ruby? a data pipeline in Haskell? Making a bunch of API calls in Clojure? It's not all the same.
When it comes to old pixel art games though (as opposed to the new ones), it's a matter of accuracy. There's plenty of articles and videos showing how different it is to try to use a naive emulator on a modern, upscaled OLED vs how the very same game looks in a surviving old Trinitron with a SCART cable. If you are looking at, say, old Atari 2600 games, there's no reason to try to pretend to be a Trinitron. But for SNES? Sonic in the Genesis? Reproducing the screen with square, perfect pixels often looks worse.
Still, flash games are getting emulated, and so do Quake-era FPSes. Sometimes we rediscover older gameplay, or more readable art. Other times it's only nostalgia. But pixel art in itself? It's just effective. Modern games just throw away some of the limitations that didn't make the games better: Go look at Sea of Stars. We couldn't have made that game work in a SNES: Too much memory, too wide a palette, more animation we could ever fit in that hardware. And yet, it's a descendent of the old RPGs stylystically, and it looks absolutely fantastic by any standard.
A company making money off of this kind of scheme would be happy to pay $200 a seat for an unlimited license. And I would not be surprised if there were many other very profitable use cases that make $200 per month seem like a bargain.
The modern, kickstarter heavy 3 hour monstrosity just can't assume that the buyer has played all the games that have the same mechanics they are basically lifting from elsewhere, while only explaining the 2 or 3 places where they are doing anything interesting. But when you go through lives rules explanations among people in industry, half of the rules are really handled by reference, because you know what is going on. With some designers, the rules are almost unnecessary, as the played aids and the graphic design do 90% of the work. I've played that game with a certain designer: He sat there to answer questions, but he didn't even hand us a rulebook, or provide an explanation. Just the components in front of us and 'figure it out', as an experiment on the game's learnability
If you talk to people in industry, they realize that this is making the games worse, but it's making them sell better. Just like today, just like with a movie, high sales don't come from great mechanics, but franchises or licensing. Your superhero coop game is going to do much worse if it doesn't have a license. Why do we have so many boardgames with video game licenses? Because it sells. There's way too many games in the market right now for even industry insiders to good track of most offerings. Buyers working for large internet game stores are overwhelmed.
So no, game designers are 100% understanding their task, which is to make a game that gets backed and is profitable. Cutting half the game after you told backers what you were doing is a disaster, and it's all those extra rules and extra boards that sold the game in the first place. The fact that the game is shelved after 3 plays is not a problem for them.
There's good documentation in the software world, but it's always for systems shaped as to have all the incentives align to having good, current documentation. Stripe has good docs, because that's part of being able to onboard people: Bad docs cost money. Postgres has good docs because it doesn't change that much, so the good documentation stays useful, and they have a quick loop between finding errors and fixing them.
Your typical internal project has awful documentation because it's nobody's real job, the requirements change constantly, and not enough people would use the documentation in the best of times to make good documents a worthwhile investment.
And if you ask me, the SPI wargames aren't exactly pinnacles of good rulebook writing. If anything, the similar shape came from the games themselves having similar bones, more than because the system was good, or because standardization helped.
The fact that functor is a concept, and follows specific laws, allows us to have other abstractions that work across all functors without having to repeat ourselves over and over again. See, for instance, Scala's for comprehension. it offers different iterating capabilities over basically anything, and it will give you more capabilities if instead of just functor, you pass a monad, or something that supports .filter.
Also see the possibilities of generic transformations. Every language that supports Promise needs some way to turn a list of Promises into a Promise holding a list, and vice versa. We can do this with options, or Eithers, or some home-made thing that is holding on to any other property we like... but it's so much easier to do so without having to write every possible combination of two things, and rely on the fact that one might be a monoid, or a monad, and not have to write all the boilerplate.
In languages that take this very seriously, you can do things like, say, apply a tracing library to an http request, or a logger, or manage creation of resources, all throught category theory concepts, and have all the wiring basically disappear, instead of havign to either pass a million parameters, or relying on some dubious Aspect-oriented-programming instrumentation that might or might not work. All visible, and checkable at compile time. And you get there by making all your abstractions are functors, monoids, monads and such.
It's not unlike what happened to soccer as television got cheaper and cheaper: You can go watch your town's third division team, or you can watch Real Madrid play on TV. In 3rd division nobody can be professional, in 2nd division you make less money accounting for inflation than 30 years ago, but the top players in the top teams are even bigger stars, now that the entire world can watch them play every game.
And on theater, let's not forget that many parts of the spectacle are almost impossible to take on the road. You aren't going to feed a production of Phantom of the Opera in a small town for 3 months: National tours rely on 2 weeks per large-ish metro. And when you are only going to stay there for 2 weeks, there are things you just can't get away with, economically speaking. The equity Hadestown tour would need to remodel way too much to accoout for the lift on broadway. The non-equity tour, which plays even shorter windows, can't even rely on the turntable on the floor. The car in Back to the future isn't going to fly over the audience, do half as much movement, or get fire effects on the scenario.
And even if you look in Broadway itself, many don't recoup their own costs. For every Hamilton or Lion king there are many shows that don't last 6 months.
Eventually you learn that one of your middle managers managed to fire someone for some reason that is illegal, or is related to some kind of crime, and guess what? It seeps upward, and your company is in the wrong.
A process doesn't just protect the employee, it protects you from the iffy middle management that, without exception, gets in. And the more freedom you give them, the worse the behavior.
It's also bad for the high performers, as working in the same team is bad: Having 3 great performers in a team means at least one, if not two are going to get a middling review. Everyone's behavior gets warped in ways that don't align well with what would be good for the company
It was always a pretty competitive place, with a lot of smart people working a lot of hours, and a culture of attention to detail that left many people with impostor syndrome. There were pretty good expectations of being nice to each other: No infrastructure team giving your request the cold shoulder, because that was just not OK. So people working really hard and burning out to try to meet every growing expectations was common.
The post also had the other weakness of the culture: A lot of management changes, along with a culture of performance among managers that would be fit for Amazon. So a manager might change teams, and the person that used to get exceed expectations would end up with a PIP with the next manager, often by surprise. You can imagine what it does to morale to tell someone how they are the most helpful person they've worked with, and then see them gone two weeks later. It was a great place to work in many ways, but the negative parts took their toll.
So, if anything, the story showed me that even though it's been many years, a lot of Stripe is still recognizable.