Short version: he’s the lead dev (and lead designer, and project leader, created fallout, and much more).
There is a showstopper bug that is hard to reproduce they effectively bisect the code until they find it.
They fix the bug. He is asked whose error it was by his boss, and to protect the person, he says it’s not important. His bonus - keep in mind he created a new successful IP from scratch - is drastically reduced as a result.
Wow. Insane that he lost his bonus for being a good lead dev.
Some dev had put the classic `<=` instead of `<` in a for loop check and the for loop body promptly corrupted some memory leading to heisencrashes. It took weeks to narrow down with 10+ hour days. Once they did and fixed it the boss asked for a name who had written the offending code. Timothy did not bend. Boss was salty and cut his bonus.
This form is basically always used for enumeration.
Might as well just do (x != y); unless you're specifically looking to guard against erroneous bitflips that would be caught by the prior (x < y), but not the former. But at that point -- it's likely your result is going to be garbage.
In essence they're the same; but one you never have to think about whether you're using it correctly.
Can anyone find a reason not to swap out (x < y) for (x != y)?
`<` communicates the intent way better. It also more readable
Example: The loop should run as long as the counter is smaller than 10. `i /= 10` achieves the same thing but communicates something very different. It implies `i` may be changed inside the loop to become larger than 10. The condition itself implies a larger valid state space.
It's a moot point anyway. Modern languages have much better looping constructs.
(If I'm understanding correctly) one example is if have two places where you x++ in the loop, so if you make an error in there you might end up hitting both of them and incrementing from y-1 to y+1.
whenever i see '<=' in code, my bug detectors start twitching. to begin with, doing effectively two tests in one always seems to over-complicate things.
How exactly? Well there is an extreme case where x and y are volatile but even then the order is implementation defined so I can't see a world where it matters.
Nothing wrong with a do...while loop, but I've learned to look twice when crossing that particular street. Most loops that don't have bugs tend to support zero iterations seamlessly and inherently.
I was trying to say that the difference between a for loop with < and a for loop with <= is roughly the same as the difference between a while loop and a do-while loop, and to whatever degree that's true they might be due suspicion for the same reason.
I agree with parent. do-while communicates that a thing will always execute once, and maybe more, and a while or for loop (even in the higher level for-each/for-in case) may never execute at all.
Being able to choose the right control structure (and data structures) can provide additional information to the correctness of the code than arbitrary choices which may perform the same function. Choosing the
Most expressive options may or may not conflict with performance, in which case, comments are helpful to describe why more obvious approaches weren’t taken.
zabzonk is obviously correct about the behavior of the control structures - that's not something I ever meant to disagree about.
The thread had had one poster state they find <= suspicious in a for loop, and another about any do-while loop. I don't think these are literally the same thing (hence "if you squint") but I think they share a meaningful similarity of adding an extra pass through the loop compared to the other form and I thought that was interesting.
The title has been changed from first person to third person, making it sound like it's a piece from some video game history vlogger. In fact, it's actually a first-hand account from the man himself.
"Timothy Cain: Why I Left Fallout 2" would be a better title.
They lost BioWare to similar reasons. They cheated on the sales metrics (underreporting sales to Bioware ) on Baldurs Gate and other titles to scam them out their royalties but got caught.
The resulting situation involving lawyers with Bioware walking with the in progress game and IP, the D&D 3.0 title Neverwinter Nights to Atari leaving Interplay without its even more successful innovator and dooming Black Isle.
Fun fact - The master server design for neverwinter multiplayer was to large parts put in place to detect publisher royalty cheating not because of piracy concerns. And sure as hell Atari once tried to sell a large bunch of NWN expansion pack in Germany with copied keys, not understanding that the master server design meant uniquely issued keys rather than the 90s algorithmic ones.
To this day Interplay lives as a zombified parasitic scam organism trying to attach itself to new opportunities every once in a while.
Is it? As the tech lead, it is his responsibility or fault either way that such errors do not make it the code or find them if that happens. If the project is delayed and you miss some big sale day or something, it does not sound so unfair that his bonus is cut.
I am not fully sold on the idea of him losing a bonus is 100% because he defended the person who did it.
> If the project is delayed and you miss some big sale day or something, it does not sound so unfair that his bonus is cut.
If the Goose needs a few more days to lay the golden egg should you reduce it's food budget?
Seems kind of short sighted to punish your high performers. I can think of multiple times this happened in my career.
> I am not fully sold on the idea of him losing a bonus is 100% because he defended the person who did it.
He seems to say in the video that part of it was not fingering who did the bug and the other was that his boss wanted someone else's bonus to be higher so he removed some of Tim's bonus.
Another post here says "it took weeks 10+ hours day to fins it", which sounds like a major fuck up if that results with you are missing a deadline or cutting features
Any experienced programmer knows off-by-one errors are very common. There’s even a joke about it:
> There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
The real fuck up is the common sin of games industry ownership and management that applies unrealistic timelines to AAA games development which, especially in the days of in-house built render engines, were some of the most complicated software engineering endeavours around.
It absolutely is. Timothy brought the company a whole new profitable franchise. Based on that alone it would have been fair to compensate him well. That he was also in the middle of building the sequel under duress made it also the sensible thing to do. Late 90s and 00s games companies were toxic places to work, and getting demoted or fired due to a simple off-by-one error in a memory unsafe language is not reasonable, it’s extreme. But it was still the norm for the unhinged management of these games companies that couldn’t grasp the huge risks involved with games development, and were also unwilling to appropriately budget or compensate their staff for it.
> But it was still the norm for the unhinged management of these games companies
The oddest thing to me is that he claims he heard about this when opening the check. I don't know how I would have reacted to that but it would not be well. Definitely not with enough grace to go home before writing a resignation.
The point of a bonus is to motivate worker to give their best.
But if they are already doing that (say, they are making a video game and it is their passion), work extra hours, and on top of that get their bonus cut coz of nothing they can reasonably affect, that just kills morale
Forgive me for saying this, but you don’t seem to know how programming works. Requiring that a program doesn’t have bugs, or that the bugs are found immediately, is like asking the wind not to blow.
Sounds like a better outcome would be firing his boss for the stupid idea that someone's bonus should depend on a largely unpredictable process working predictably.
I think you can read your boss - if they look pissed that you don't disclose the name or they keep asking - that's pretty plain.
Is Cain responsible for the quality? Yes. But IMO the boss should have delegated handling of the issue to him instead of retaliating for apparent insubordination.
He could legitimately complain that Cain provided insufficient process and controls to prevent junior devs from making critical errors. But looking for a scapegoat is indicative of bad management.
And Valve rewrote Half-Life almost from scratch when they finished it and realized that it sucked.
I don't think anybody lost any bonuses over that decision. Not in the long run. Sure, running late on a project is a Bad Thing, but nobody will remember it if you eventually get a quality product out the door.
its a text-and-terminal style UX at moment. so we have some Infocom/IF like-modes, but also have true Rogue-like-looking UI elements where those fit. (I should revise the project page to make clear. But Itch.io forced me to pick a category)
There is a showstopper bug that is hard to reproduce they effectively bisect the code until they find it.
They fix the bug. He is asked whose error it was by his boss, and to protect the person, he says it’s not important. His bonus - keep in mind he created a new successful IP from scratch - is drastically reduced as a result.