Six months after launch when all problems are solved - absolutely, you can fire engineer. 48 hours after launch? absolutely not.
Six months after launch when all problems are solved - absolutely, you can fire engineer. 48 hours after launch? absolutely not.
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
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.
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.)
Many CEOs are just playing a video game and don't care if they lose because they have extra lives.
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.
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.
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.
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.
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.
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
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.
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?
I think it is too easy for an outsider to treat software the same.
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.
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.
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.
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.
This is just standard profit over people capitalism.
Ah yes, the absolute preposterous idea that nobody, especially not companies, would ever make an irrational choice.