Oh, but that's the problem: because their tenure at this "hedge fund" was so short, and the job market is so lousy, they've effectively been blackballed from finance.
I thought the same thing. Either he means that he learned the very finer parts of Rust on the job but knew it well to begin with. OR. He was really doing 40 hours of work and 40 hours of Rust learning per week. Which is fine too, as he delivered.
Have you tried it? I don't see any rust code in your github profile.
Personally, I don't think it's that bad. I did it in 2020, and thought it was (mostly) easy. A few weeks of wrestling with the borrow checker until I finally "got it". I now work in Rust full-time.
Starting with knowledge of another statically typed language, Rust really isn't that hard. Borrow checker gymnastics take a few days to get over after which one can get relatively productive. There's plenty of code samples on GitHub and mature crates to get going on the db and web layers.
As a primarily Python programmer, I did not feel over-burdened by learning Rust. Sure, I never learned how to deal with lifetimes, never wrote a macro, and probably used clone a few places where I did not have the need. I was almost certainly leaving performance on the table. Yet the language gives you so many guardrails that I always felt like my code was doing the correct thing.
Why are you pitching yourself as a junior in the job market after you delivered so much? You should only be considering senior roles or, better, contract/consulting. Just imagine if you'd value-priced what you created. Second thoughts, don't or you'll never get a decent night's sleep again.
OP will take that experience with them forever (technical, tactical, emotional perhaps). It’s a huge learning experience, many would suffer for.
OTOH, the hedge fund will probably fail to profit from the project soon enough: A. they fired their most productive engineer in a changing competitive business B. they run a v0.9 with many bugs without the author-maintainer C. hate the saying but they seem penny-wise pound-foolish.
OTOH, it smells like there was also a quiet conflict between OP and their manager, and OP was unaware of that.
I suspect a very large percentage of HN readers are probably idiots, by that measure. (Me included, for at least 4 or 5 different "someone else's companies" over the last 30 odd years.)
I've worked for software company which sold products to hedge funds. And I've also done consulting work for big private equity firm. Both experiences taught me never to actually be employed by such companies. You will be disrespected.
There are people out there who see the entire world as "fuck you, I'll get mine". They are socialized into such circumstances and so tolerate or even seek them out as some kind of validation of their social-Darwinist ideology.
It sounds like they were never given written confirmation for the bonuses. How likely are you to face penalties if you put a "time bomb" in a codebase like this? Something with plausible deniability like let's say like an authentication script that you have to run every 30 days or the program stops working for "security reasons". Also you're the only one who knows where the script is and how to run it.
This won't get you the bonus, it'll just get you possibly sued and/or prison time.
I think a better fix is to just not give to a company what you would regret giving. Don't put in 80 hours a week for months unless you have good reason to think it's going to be worth it and do it with the full knowledge that you might be gambling on the company's generosity.
I mean, you could come back as a contractor and have them pay your rate to show them how to get the authentication script authenticating again. Obviously this isn't ethical.
> Don't put in 80 hours a week for months unless you have good reason to think it's going to be worth it and do it with the full knowledge that you might be gambling on the company's generosity.
I agree. I'm also not 100% convinced the original story is even true.
To play devils advocate, what we don't know from the story is how effective the playform was. 48 hours after release he was fired, possibly because it was terrible.
Count yourself lucky that you got out with your liberty. It's not unheard of for quants that try to leave to be criminally prosecuted and placed in isolated incarceration.
i keep saying it to people at work who work extra hard or spit some positive corporate propagada --- as an employee you are just a fucking number,,,and nobody gives two fucks about u
I just do not believe this story. Nobody in the right mind will fire key software engineer 48 hours after system goes live. This is where all the bugs/problems show up and you need all hands on deck to fix them.
Six months after launch when all problems are solved - absolutely, you can fire engineer. 48 hours after launch? absolutely not.
Lack of empathy is what causes the hubris (stupidity?) that would lead one to believe the person who built the system is expendable.
I have also been in a job where once the project reached a certian point I was fired. They gave me a song and dance about building a tech culture and sustainable development.
It was all lies. They knew when they were going to fire me the day they hired me. Once their demo worked, everything went off the rails. There was no real business plan just hype and bullshit. No wonder they had no idea what to do next.
Sometimes it's a blessing in disguise when you get shit canned at these jobs but you can't pay the bills with moral victories
We definitely don't know enough to make informed opinions. The manager may be new and had not anticipated how many bugs there would be on a version 1.0, the system may not have worked, or many other possibilities.
And how long would it take for the person to get up to speed on the code for such software that in production and may have critical bugs that need fixing now?
> And how long would it take for the person to get up to speed on the code for such software
If only this is more understood. I've been on both ends and as the newcomer you rarely get any ramp up time and management assume you'd know what you're doing in 5 minutes.
Business managers don't like to think that way because they know they're already screwed if business continuity relies heavily on "bus factor 1" individuals
I built a system at an old job that as far as I know has been in operation for over 10 years, completely untouched. I left the company that long ago, interviewed about three years ago for another position in the same department, where someone disclosed it was still up and running, without modification. I’m sure someone had to read the code at some point, but they could have fired me right after it was built and suffered no great loss because of it. I guess I should’ve spent some more time overengineering the whole thing or introducing subtle bugs if I wanted job security, as I have seen others do.
Well, Netflix was famous for firing when the business need had passed. You have a seat in company for what you will do, not what you have done.
These high speed trading platforms do a ton of transactions in 48 hours. They assume nothing material will change in 6 months vs 48 hours; and anyways if it breaks why keep paying the dude who built it so flimsy?
> You have a seat in company for what you will do, not what you have done.
that's fine, but netflix pays for this privilege by high salary from the get go.
If you worked for a startup, i assume the salary isn't going to be as high. Instead, you'd expect to be paid in equity.
So by firing someone as soon as they're done (meaning their future equity vesting is lost now), they lose a lot of what would've been theirs had the company's long term potential been great as a result of their work.
> Nobody in the right mind will fire key software engineer 48 hours after system goes live.
Lots of companies and people treat software as physical goods (where it's done it's done) and that everyone is easily replaceable. I've seen many managers not consider uniqueness or the situation but simply we have an engineer with x years of experience so a similar 1 will work just the same.
Is this cope or are you basing it on something? Because it's actually somewhat of a problem that high finance sucks in so many extremely bright and intelligent people.
I'm sure there are chuds in the HF industry just like any other sector but by and large most people working in those firms are some of the most capable society has to offer.
To be fair you can be a 'chud' and be very capable still. Especially in finance. Based on my (very short) experience in the field, "competent yet apathetic/morally blank" was the norm.
If you really want to fire someone, you're willing to bleed a little (or a lot) to do it. I've seen key personnel be let go, followed by a scramble to figure out what only they know.
In this case it sounds like a "junior quant" who built an application in "months of hard work" while working 12hrs x 7days, and using technologies they learned on the fly. Sounds like me in my 20s, but I wasn't as indispensable as I thought I was.
In any case, that's not as hard to replace as the sysadmin who's been there for 10 years.
From a different perspective, it's kind of like paying a contractor or offshore. You don't usually keep them on board after the deliverable, you hand it over to the in-house team to maintain it.
I would agree: while not impossible, it seems like some key information is missing.
On the one hand I would definitely expect zero empathy from a hedge fund. They should pay big bucks (pounds in this case), but if they consider an employee no longer useful it is an instant goodbye.
But firing a key engineer of a successful production system that they plan to operate -- no way!! Neither 48 hours after going live, nor 6 (or 12, 18 or 24) months later. Trading strategies always get refined, changed and tuned and an oops in that process can be very expensive. A hedge fund would fight to keep the key engineer who built the system.
One case where this is possible is if a bigger fund wants to snuff out a new entrant (for example because the smaller fund is messing up the larger fund's strategy). Then the owners get $$ and everyone else gets the boot. My 2c.
It’s plausible it got to a point where it was done well enough to not allow too much dependency on one person.
The answer seems pretty obvious from the author. They had promised him a cut of the profits and now they don’t have to.
After relying on someone to use their talents to get things done quicker.
Internal politics could also be at play, now that a foundation is built other self interested parties or departments could be angling in to maintain whatever they’re after
I worked for a storage startup in the South Bay in the late 00s which did something like this. After staff crunched to deliver the base operating system and kernel controllers, management gave across-the-board poor reviews to all IC staff to justify no raise. Those with the ability quickly left for greener pastures; Google hired some of the best. Only those who had to (work visas, lack of experience, etc.) remained.
The product, being a v0.1 release implemented in C, was of course plagued with data corruption and poor performance. It read /etc/password from disk on every file access. An uninitialized int caused indirect inode corruption every ~millionth write. And so on.
Because of the poor product quality, they lost multiple opportunities, including a bid for early Facebook photo storage. The company never had more than 250 customers and ended up being sold to a Valley stalwart. The CEO and VP Eng were paid out handsomely, of course; preferred converted stock tranches or whatever. My options from 4 years of employment ended up worth $500.
Sounds like the Igneous playbook, from what I've heard. Immediately after launch they laid off a majority of the dev team, as they'd outlived their usefulness after completing the crunch. I interviewed there but fortunately declined the offer - I felt like I dodged a bullet when my friend (who survived the layoffs, only to be conscripted as a sales grunt) told me about it. I also gather that the CEO had pulled similar shenanigans with Isilon in the past.
If it's any consolation, Igneous died and the execs didn't make out like bandits this time.
”The product, being a v0.1 release implemented in C, was of course plagued with data corruption and poor performance. It read /etc/password from disk on every file access. An uninitialized int caused indirect inode corruption every ~millionth write. And so on. Because of the poor product quality, they lost multiple opportunities, …”
It sounds like the poor reviews for the ICs was warranted, wouldn’t you say?
Not necessarily. Big codebase in something like C, written in a rush, pretty much is guaranteed to have such things. We still are finding high-grade security issues in glibc (if you want some library to be clean, it's the one practically everybody is using), and it has been around for 37 years. v0.1 prototype is often plagued with various issues and often doesn't have best performance. You either spend years on polishing it and never release, of you start with v0.1 and fix the issues. Or, having fired all the dev team, don't fix the issues.
> It sounds like the poor reviews for the ICs was warranted, wouldn’t you say
How many crunches have you survived that resulted in a high-quality initial product? If there is enough time to get things right, it wouldn't be a crunch, by definition.
You would be pleased to know that Whiptail exceeded whatever low bar you might have had. I like to see people achieve the things they set out to do, and I am assuming that was their goal.
Rare to see a product completely canceled and removed from the market as soon as customers started reporting minor things like total data loss due to corruption..
I think you give the whiteboard far too much credit. In the succeeding two decades I have worked at many companies filled with past, present, and future FAANG engineers, and I can definitely say knowledge of algorithms isn’t a defense against writing silly bugs when implementing a complex, novel project from scratch. Just a dumb oversight that would have been caught quickly by user reports—had all the engineers who cared not quit from misanthropic management. There were many such issues, and I only remember these two because I found them myself.
I was in support and only had two good resources for tracking this kind of stuff down, a burnt out but kind SCSI specialist and a brilliant, massively overworked Russian kernel dev on visa. They both lasted an extra year. Bless them both for answering my pestering questions, I learned a lot.
Good times, but all this was about a year too late to make a difference, then the Great Recession hit and it was done.
This is the U.K. - technology is seen by businesspeople as dirty and bad, as are the people who work with it. Maintenance is unheard of, sustainability is a dirty word.
For instance, I know of a large U.K. medical data processor who wanted ISO270001 compliance, so they got in a contractor to write an ISMS, had it audited, and then immediately fired the contractor upon successful pass of the audit.
What happens next year? Who cares! I’ll be in Marbella with my bag of swag by then. Someone else can figure it out.
There are many possibilities (and I can't really tell from skimming this writeup), but the possibilities absolutely include someone thinking "We got what we needed, now let's drop this person, and free the salary and bonus obligations".
Or they might've decided they didn't want that employee for some reason, maybe even dudebro culture fit mismatch when he showed up looking fatigued, and were "sux2bu" about how they got rid of the person, firing fast. Or that project got scrapped. Or some other person had a look at the code and decided they didn't like it (or didn't like the partner whose pet project it was). Etc.
A factor to keep in mind is that many, many shops nowadays really don't know how to build software that works sufficiently well, or they have low standards for what "sufficiently" means. For example, a few years ago, if your experience was only when the top priority was the appearance of growth, and then the next funding rounds and then exit, and there were all sorts of memes about moving fast and breaking things, etc., and you have no idea how to build systems that work, even if you wanted to... you might well think that developers are disposable and interchangeable commodities. (Someone else here noted the practice of a startup using offshoring contractors for key tech early on, which I think is strong evidence of this kind of thinking.)
People who say no get respect, those who say yes to impossible deadlines, work insane hours, maybe miss an impossible deadline by a few hours-or not, get fired.
Nobody in the right mind will fire key software engineer 48 hours after system goes live.
Perhaps there was a backstory of sorts we're not aware of. But there is absolutely nothing surprising about companies firing people right after handing over huge and/or critical projects. They do it all the time, for both good reasons and bad. Managers in finance are known to be especially "bold" in making decisions like these.
Good sir / madam - I was in the middle of fixing a production bug on what was at the time one of the busiest sites on the net when the layoffs came. Like literally was typing out a fix when I got called to the conference room, computer locked when I returned to my desk. Corporate American don’t care.
A friend of mine recently related cleaning up a mess at work where the devops staff was let go 48 hours before the new site deployment - not a tech company - but another case of the left hand doesn't know what the right hand is doing.
It sounds like they are in the UK. You can't just fire someone out of the blue like that in the UK (assuming they are a FTE), unless they have done something obviously "bad" (proper misconduct etc). If they don't need you anymore there is a defined redundancy process.
If they were not a FTE and were in fact on a temporary contract, then this is totally normal and expected, and the author should have known that as a contractor. Contractors are easy-come-easy-go - that's the whole point of them, and why the pay is higher than FTEs.
That’s not true. There’s basically no employment protections in the UK for your first two years of employment. There are pretty good norms in the UK including finance about this, but your statutory protections are pretty weak even after the two years are up.
Or maybe they fired him precisely because of the type of bugs that showed up. You wouldn't want a "move fast and break things" guy to manage billions in cash flow ;)
How did you figure this out? I used to work at ExodusPoint (left about 3 years ago).
It wouldn’t surprise me if it was ExodusPoint, but I’m not sure how one could make that connection from the article.
ExodusPoint had an OMS 3 years ago, so the part in the story about starting trading makes me suspect it’s either an OMS for a new asset class, or a replacement of an earlier system.
Unless the OP joined a portfolio team, and the OMS he’s talking about was to connect that teams strategy to the internal firm wide OMS. I did that for my pod, and I can see a Portfolio Manager making a decision like this.
If you worked at EP then you should also know that they [I've heard] are very litigious. If I were the anonymous writer or op I wouldn't site any sources.
Most likely it was a quant in a pod. OMS could be loosely defined here as well or obscured to not dox themself too much. However EVE trade sounds very specific, I don't know what this means, EVE online trading?
I agree that it sounds unlikely. Although if you really invested in someone to develop a platform, you might not want to fire them. Compared to the price of any other software maintenance cost, this is very likely the most bang for the buck you could ever get. Firing someone after 48h seems stupid if they in any way want to use the product that was delivered. Maybe they don't.
While I don't know the specifics about financial software, the job market also is pretty good internationally, so finding something new, as a freelancer or not, shouldn't be too hard.
Just keep in mind that a business's role in society is to deliver something and bring in a profit. So if you don't bring revenue directly to the bottom line you are in line for layoffs. Don't fall in love with your job. The business is not in love with you.
I suspect the fund's trading strategy was less than great so they had to cut expenses ASAP. I can't imagine why they would get rid of the person who would have to maintain the code, if they didn't need to do it. There is no such thing as a no need for maintenance code. If I was the CEO, I would have been terrified if the code was running without someone to make sure it was running correctly.
You overstate their role when you say it includes 'delivering something'.
The people who run most businesses would be perfectly happy delivering nothing at all and bringing in a profit. That's why businesses in the western economic system all end up turning purely into investment funds if left unchecked.
> The people who run most businesses would be perfectly happy delivering nothing at all and bringing in a profit.
To be fair, to the degree that your statement is true, then I think most people who are employed by businesses would be perfectly happy delivering nothing at all and bringing home a paycheck.
As someone who worked in pricing for a SAAS company I often explained what I called the “greed-charity” scale with 0 being “full greed, take in money but provide nothing” and 10 being “full charity, provide everything for free” and ask “what does a 5 look like for this product/feature”?
We need to teach this as the type of relationship early but frankly society starts off very young teaching people to be “rockstars” and work 80hrs to be better than the “lazy” and the “poors” and in some circles “the immigrants.”
> Just keep in mind that a business's role in society is to deliver something and bring in a profit.
No, that’s just another lie you’ve been made to believe. Corporations exist to serve the public good. The freedom they have been granted by the laws passed by nations is to facilitate that end. All it takes to change the rights of corporations is a change in law (not a Constitutional change as it would to change the rights of people).
Nobody deserves to be treated like this, but unless it’s in a contract in actual cash terms, treat all compensatory promises from your employer as Monopoly money. This goes for bonuses as well as equity payouts.
192 comments
[ 2.6 ms ] story [ 253 ms ] threadOh and I hope OP didn't get the time to pick all bugs for the ex company so maybe that's on his contracting list too.
Personally, I don't think it's that bad. I did it in 2020, and thought it was (mostly) easy. A few weeks of wrestling with the borrow checker until I finally "got it". I now work in Rust full-time.
OTOH, the hedge fund will probably fail to profit from the project soon enough: A. they fired their most productive engineer in a changing competitive business B. they run a v0.9 with many bugs without the author-maintainer C. hate the saying but they seem penny-wise pound-foolish.
OTOH, it smells like there was also a quiet conflict between OP and their manager, and OP was unaware of that.
Nobody actually pays for software development in the U.K. - just the taxpayer.
It’s like skipping life because all one does is work. Thats basically 12 hour workdays with sat and sunday 10 hour each.
Lets pray you were exaggerating a bit. :)
True.
But in capitalism greed is a fetish
Survival of the fittest and the most powerful.
Completely laid back cultures advance very slowly.
Its the same idea from the opposite direction.
I think a better fix is to just not give to a company what you would regret giving. Don't put in 80 hours a week for months unless you have good reason to think it's going to be worth it and do it with the full knowledge that you might be gambling on the company's generosity.
> Don't put in 80 hours a week for months unless you have good reason to think it's going to be worth it and do it with the full knowledge that you might be gambling on the company's generosity.
I agree. I'm also not 100% convinced the original story is even true.
Getting fired sounds pretty good, no?
UBS had similar? Perhaps.
Try searching for these.
I think the coder was arrested but it didn’t go much further than that… I don’t think it has happened again since the early 2010.
Six months after launch when all problems are solved - absolutely, you can fire engineer. 48 hours after launch? absolutely not.
You need one or two more release to iron out the bugs, right?
...and this is a trading platform. The market changes, you need program changes for unforseen market changes.
I have also been in a job where once the project reached a certian point I was fired. They gave me a song and dance about building a tech culture and sustainable development.
It was all lies. They knew when they were going to fire me the day they hired me. Once their demo worked, everything went off the rails. There was no real business plan just hype and bullshit. No wonder they had no idea what to do next.
Sometimes it's a blessing in disguise when you get shit canned at these jobs but you can't pay the bills with moral victories
In large enough company, outside of engineering department end product quality or even business long term sustainability is often no one's concern.
If only this is more understood. I've been on both ends and as the newcomer you rarely get any ramp up time and management assume you'd know what you're doing in 5 minutes.
These high speed trading platforms do a ton of transactions in 48 hours. They assume nothing material will change in 6 months vs 48 hours; and anyways if it breaks why keep paying the dude who built it so flimsy?
Not my way of doing things of all, to be clear, just my interpretation of the “we are a team not a family” implementation. https://www.fastcompany.com/3056662/she-created-netflixs-cul...
that's fine, but netflix pays for this privilege by high salary from the get go.
If you worked for a startup, i assume the salary isn't going to be as high. Instead, you'd expect to be paid in equity.
So by firing someone as soon as they're done (meaning their future equity vesting is lost now), they lose a lot of what would've been theirs had the company's long term potential been great as a result of their work.
Lots of companies and people treat software as physical goods (where it's done it's done) and that everyone is easily replaceable. I've seen many managers not consider uniqueness or the situation but simply we have an engineer with x years of experience so a similar 1 will work just the same.
Thats the thing. Hedge funds are not managed by people in their right minds
I'm sure there are chuds in the HF industry just like any other sector but by and large most people working in those firms are some of the most capable society has to offer.
In this case it sounds like a "junior quant" who built an application in "months of hard work" while working 12hrs x 7days, and using technologies they learned on the fly. Sounds like me in my 20s, but I wasn't as indispensable as I thought I was. In any case, that's not as hard to replace as the sysadmin who's been there for 10 years.
From a different perspective, it's kind of like paying a contractor or offshore. You don't usually keep them on board after the deliverable, you hand it over to the in-house team to maintain it.
That relationship is much better defined to both parties. It sounds like this person was surprised.
On the one hand I would definitely expect zero empathy from a hedge fund. They should pay big bucks (pounds in this case), but if they consider an employee no longer useful it is an instant goodbye.
But firing a key engineer of a successful production system that they plan to operate -- no way!! Neither 48 hours after going live, nor 6 (or 12, 18 or 24) months later. Trading strategies always get refined, changed and tuned and an oops in that process can be very expensive. A hedge fund would fight to keep the key engineer who built the system.
One case where this is possible is if a bigger fund wants to snuff out a new entrant (for example because the smaller fund is messing up the larger fund's strategy). Then the owners get $$ and everyone else gets the boot. My 2c.
The answer seems pretty obvious from the author. They had promised him a cut of the profits and now they don’t have to.
After relying on someone to use their talents to get things done quicker.
Internal politics could also be at play, now that a foundation is built other self interested parties or departments could be angling in to maintain whatever they’re after
I think it is too easy for an outsider to treat software the same.
The product, being a v0.1 release implemented in C, was of course plagued with data corruption and poor performance. It read /etc/password from disk on every file access. An uninitialized int caused indirect inode corruption every ~millionth write. And so on.
Because of the poor product quality, they lost multiple opportunities, including a bid for early Facebook photo storage. The company never had more than 250 customers and ended up being sold to a Valley stalwart. The CEO and VP Eng were paid out handsomely, of course; preferred converted stock tranches or whatever. My options from 4 years of employment ended up worth $500.
If it's any consolation, Igneous died and the execs didn't make out like bandits this time.
It sounds like the poor reviews for the ICs was warranted, wouldn’t you say?
How many crunches have you survived that resulted in a high-quality initial product? If there is enough time to get things right, it wouldn't be a crunch, by definition.
Story shows too much competence for Springpath or Whiptail.
Storage is particularly rife with stuff like this for some reason.
Rare to see a product completely canceled and removed from the market as soon as customers started reporting minor things like total data loss due to corruption..
How did people who "read /etc/password from disk on every file access." get hired by Google?
Or perhaps the right question is for which roles, because with that level of DS&A they shouldn't have passed Google's DS&A whiteboard interview.
I was in support and only had two good resources for tracking this kind of stuff down, a burnt out but kind SCSI specialist and a brilliant, massively overworked Russian kernel dev on visa. They both lasted an extra year. Bless them both for answering my pestering questions, I learned a lot.
Good times, but all this was about a year too late to make a difference, then the Great Recession hit and it was done.
Do you honestly think all 27k devs are 10x certified geniuses?
It's the prevalence of scenarios like this that makes me hate the MBA caste with a pasison
This is just standard profit over people capitalism.
This is the U.K. - technology is seen by businesspeople as dirty and bad, as are the people who work with it. Maintenance is unheard of, sustainability is a dirty word.
For instance, I know of a large U.K. medical data processor who wanted ISO270001 compliance, so they got in a contractor to write an ISMS, had it audited, and then immediately fired the contractor upon successful pass of the audit.
What happens next year? Who cares! I’ll be in Marbella with my bag of swag by then. Someone else can figure it out.
Or they might've decided they didn't want that employee for some reason, maybe even dudebro culture fit mismatch when he showed up looking fatigued, and were "sux2bu" about how they got rid of the person, firing fast. Or that project got scrapped. Or some other person had a look at the code and decided they didn't like it (or didn't like the partner whose pet project it was). Etc.
A factor to keep in mind is that many, many shops nowadays really don't know how to build software that works sufficiently well, or they have low standards for what "sufficiently" means. For example, a few years ago, if your experience was only when the top priority was the appearance of growth, and then the next funding rounds and then exit, and there were all sorts of memes about moving fast and breaking things, etc., and you have no idea how to build systems that work, even if you wanted to... you might well think that developers are disposable and interchangeable commodities. (Someone else here noted the practice of a startup using offshoring contractors for key tech early on, which I think is strong evidence of this kind of thinking.)
Perhaps there was a backstory of sorts we're not aware of. But there is absolutely nothing surprising about companies firing people right after handing over huge and/or critical projects. They do it all the time, for both good reasons and bad. Managers in finance are known to be especially "bold" in making decisions like these.
It sounds like they are in the UK. You can't just fire someone out of the blue like that in the UK (assuming they are a FTE), unless they have done something obviously "bad" (proper misconduct etc). If they don't need you anymore there is a defined redundancy process.
If they were not a FTE and were in fact on a temporary contract, then this is totally normal and expected, and the author should have known that as a contractor. Contractors are easy-come-easy-go - that's the whole point of them, and why the pay is higher than FTEs.
Ah yes, the absolute preposterous idea that nobody, especially not companies, would ever make an irrational choice.
It wouldn’t surprise me if it was ExodusPoint, but I’m not sure how one could make that connection from the article.
ExodusPoint had an OMS 3 years ago, so the part in the story about starting trading makes me suspect it’s either an OMS for a new asset class, or a replacement of an earlier system.
Unless the OP joined a portfolio team, and the OMS he’s talking about was to connect that teams strategy to the internal firm wide OMS. I did that for my pod, and I can see a Portfolio Manager making a decision like this.
Most likely it was a quant in a pod. OMS could be loosely defined here as well or obscured to not dox themself too much. However EVE trade sounds very specific, I don't know what this means, EVE online trading?
While I don't know the specifics about financial software, the job market also is pretty good internationally, so finding something new, as a freelancer or not, shouldn't be too hard.
Many CEOs are just playing a video game and don't care if they lose because they have extra lives.
On the other hand. I had places that people didn't like me because I did things too well and they looked bad because of that.
I suspect the fund's trading strategy was less than great so they had to cut expenses ASAP. I can't imagine why they would get rid of the person who would have to maintain the code, if they didn't need to do it. There is no such thing as a no need for maintenance code. If I was the CEO, I would have been terrified if the code was running without someone to make sure it was running correctly.
The people who run most businesses would be perfectly happy delivering nothing at all and bringing in a profit. That's why businesses in the western economic system all end up turning purely into investment funds if left unchecked.
All profit, no product.
To be fair, to the degree that your statement is true, then I think most people who are employed by businesses would be perfectly happy delivering nothing at all and bringing home a paycheck.
Hallelujah brother - well said.
This is by (capitalist) design.
https://en.m.wikipedia.org/wiki/Shareholder_value
And it's been profoundly destructive.
No, that’s just another lie you’ve been made to believe. Corporations exist to serve the public good. The freedom they have been granted by the laws passed by nations is to facilitate that end. All it takes to change the rights of corporations is a change in law (not a Constitutional change as it would to change the rights of people).
https://www.jstor.org/stable/1322201?seq=3
For example, when you hire a plumber to fix something, do you pay him what he deserves, or do you pay him the amount agreed upon in advance?