DefinitelyNotAPhone [he/him]

  • 0 Posts
  • 9 Comments
Joined 4 years ago
cake
Cake day: July 29th, 2020

help-circle

  • Well, I’d rather the day be sooner than later.

    Agreed, but we’re not the ones making the decision. And the people who are have two options: move forward with a risky, expensive, and potentially career-ending move with no benefits other than the system being a little more maintainable, or continuing on with business-as-usual and earning massive sums of money they can use to buy a bigger yacht next year. It’s a pretty obvious decision, and the consequences will probably fall on whoever takes over after they move on or retire, so who cares about the long term consequences?

    You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

    The stakes in financial services is so much higher than typical software. If some API has 0.01% downtime or errors, nobody gives a shit. If your bank drops 1 out of every 1000 transactions, people lose their life savings. Even the most stringent of testing and staging environments don’t guarantee the level of accuracy required without truly monstrous sums of money being thrown at it, which leads us back to my point above about risk vs yachts.

    There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them.

    Contrary to popular belief, most mainframes are pretty new machines. IBM is basically afloat purely because giant banks and government institutions would rather just shell out a few hundred thousand every few years for a new, better Z-frame than going through the nightmare that is a migration.

    If you’re starting to think “wow, this system is doomed to collapse under its own weight and the people in charge are actively incentivized to not do anything about it,” then you’re paying attention and should probably start extending that thought process to everything else around you on a daily basis.




  • Games have to talk to your operating system to have it tell your GPU to draw lots of funny pictures that come together to make up the graphical portions of the game. Game developers do not want to do this directly, because talking directly to the OS is hard. As such, games talk to graphical APIs like Vulkan or DirectX to do the hard bit for them.

    For years almost all games used DirectX, which is made by Microsoft. This gave Windows a virtual monopoly on PC gaming because they weren’t about to let their competitors use their API. Then Vulkan came out, which was designed from the beginning to be OS-agnostic, sending us to the promised land of games that could (with some other efforts) run on any machine, anywhere.


  • Feudalism never ended, it just transitioned from a bunch of failsons inheriting land titles to a bunch of failsons getting middle management jobs through nepotism. Every company larger than 50 people is a vast internal labyrinth of lords-in-everything-but-name jockeying for promotions, accolades, and raises by inflating their roles, and the best thing you can do for yourself is find a position that isolates you as hard as possible from having to deal with that yourself lest you end up spending 50 hours a week working to get one over some petty rival of your boss.



  • There’s the other half of this problem, which is that the kind of code that LLMs are relatively good at pumping out with some degree of correctness are almost always the bits of code that aren’t difficult to begin with. A sorting algorithm on command is nice, but if you’re working on any kind of novel implementation then the hard bits are the business logic which in all likelihood has never been written before and is either sensitive information or just convoluted enough to make turning into a prompt difficult. You still have to have coders who understand architecture and converting requirements into raw logic to do that even with the LLMs.