There are plenty of talented C++ programmers. They just don't want to be abused by trading firms or work in that culture. Even paying them more won't work, because no amount of money is worth that abuse.
I interviewed at a trading firm once, while I was working at Netflix (because Netflix encouraged us to interview for outside jobs at least once a year). The comp would have been double my Netflix salary.
But I would have had to work in their office in Manhattan, be in by 8:30am every day and not leave until after 5 at a miniumum. But that wasn't the part that scared me off. It was the fact that I would not be allowed to share my work internally. I would not even be allowed to brainstorm with people doing the same job in other areas of the business. I wouldn't be allowed to take my laptop home, so if I had a hard problem to solve, I'd have to stay in the office the whole time. So basically they expected us to never see our family nor collaborate with anyone.
Basically, they were so worried about secrecy of their trading algorithms and people sharing them with other companies, they didn't even let people share internally for fear that one person would learn too much about their business.
I decided to stick with my FAANG job because even the ridiculous money wasn't enough to make it worth the stress and isolation.
Basically, they were so worried about secrecy of their trading algorithms and people sharing them with other companies
Which means if you took the job they probably would have had you sign some obscene non-complete/non-solicit/non-disparage/non-roll-your-eyes-at-them agreement. Despite the dubious enforceability of these, especially in some jurisdictions, you would still likely experience a lot of stress and expense (i.e. lawyer-up) if your departure rubbed someone the wrong way. Your exit from the trading world could involve:
- demands to keep them informed of what you were doing
- private investigators checking in on what you are doing
- threatening legal letters
- or actually being sued
And that's if you did your very best to follow the non-compete agreement. If you were actually taking employment in a field remotely related to finance, you could have the DOJ/FBI knocking on your door to investigate trade-secrete theft.
EDIT: And another point about "double the comp". The comp structured so that 75% is a discretionary annual bonus payout (with claw backs), and your base salary is 25%. So you could actually end up making less money, depending on the whims of the markets and/or internal politics.
I feel like some people responding to you have been nowhere close to a finance role.
First, those 8-5 hrs are only stated by your contract. Everybody on HN complains that "unlimited" PTO obviously does not mean "unlimited". Same as your "strictly " 8-5 working hours. There is a high level of peer pressure to get things done immediately.
Working in a mid office role, I frequently had front office at moment's notice ask to implement complex deals while trying to understand their vague descriptions of said deal. Now I have to spend an hour with them to parse out what they want. Good luck trying to have a mutual conversation with the front office in a high stress situation. I had to once implement a completely new computational feature to the code base in two days just to accommodate a single deal. And don't dare think that you can get into flow...
So not only can some of these deals have long compute times, but then you have front office analysts pinging you every hour to see "how are things shaping up" and if you have something ready.
Not only do you have your own tasks set by your direct manager, but you have several analysts on your ass that could drop a complaint at any second. In the end, you have multiple bosses. If they are unhappy with how fast you are delivering, you can bet your direct report will one day hear about it. There goes your performance review and year end bonus.
Now not only do I have multiple people at work on my ass, my family is pissed that Dad has to work late this evening because he was given something to work on that needs to be delivered asap.
Don't get me started on the snark by the back office. Not only can get shit on by front office, but the level of unhelpfulness by the back office made shit roll down from all sides.
Just to clarify, you used the word "abuse" several times to describe a job where you would have to work in office between 8:30 to 5 and pull (I'm safely assuming) half a million dollars a year?
8:30 to 5 was required, but also never working at home was required, so what I was trying to (poorly) say is that they basically expected you to live in the office and never see your family. I'll update accordingly.
And the comp package I turned down was about $700k at the time, which was 10 years ago. Nowadays it would be a $1M+ job easy.
But not seeing my family is not worth any amount of money to me, since there are other jobs for a lot less that let me see my family and live plenty comfortably.
That's not abusive. That's a rational security posture. Defense contractor employees can't take their work home either. It's nice when you can't be pressured to work off hours.
This isn't true by the way. A lot of defense contractors employ WFH or full remote procedures because 99% of your work will be on things that are unclassified. Most modern development practices separate out the classified material from the actual day to day work because not only is it better for security but also because forcing everyone into a SCIF wastes a lot of time and money.
Let me get this straight... you turned down a nearly seven-figure income because you would be required to not work at home and you were asked to stick to the same office hours as cubible farm workers making a tenth of that income?
Income has logarithmic value. His options were to make 350k and be happy day to day or make twice that and be in an activity hostile environment. Lifestyle wise there is little meaningful difference between 350k and 700k when you don’t have much free time to spend it.
Sure in theory he would be able to retire sooner etc, but retirement isn’t such a big deal if you don’t hate your job. Also, savings compounds so saving 3x as much doesn’t mean working 1/3 as long especially when you consider social security benefits etc.
I work on a software used (not exclusively) by the USA armed forces.
I work from home for the most part. I can do that while travelling as well but I have some limitations on which countries I can do that from. But I'm not sure of the entire list.
Yeah, for that compensation? No question. I'd maybe try and stay a little while past 5. Not sure how many months (years?) I'd last there though, not knowing how 'intensive' the work culture is.
The comp he mentioned is almost 11x of what I make yearly. Of course I lack the skills for a c++ job, but if I worked there for a year I could go on a vacation for the next couple of years. insane.
> But not seeing my family is not worth any amount of money to me, since there are other jobs for a lot less that let me see my family and live plenty comfortably.
That is fine and, tbh, a very healthy attitude. But it is not abusive in any meaningful sense of the word because it is not a worthwhile tradeoff for you personally.
Most HFT shops aren’t pulling crazy hours like that. That’s a wild exaggeration. I worked far longer hours at a FAANG than I ever did as a dev on a low-latency trading desk. Nobody at the latter ever got in my face and screamed at me, either. And guess at which of the two I got an unnerving call from HR asking if I could comment as a witness about some sort of harassment/bullying complaint two coworkers were entangled in during my second week on the job.
Yeah for real, I there is so many tech people are sheltered now days that if anything difficult comes there way they can't handle it. 700k for an 8 hour a day job and claiming to be abused is ridiculous.
It's fine for someone to say they don't want the job but claiming abused is something else. People work months away from there families to provide for them and make 10% of that wage.
It's not an eight hour job, you're completely misreading it. It's eight hours required plus another eight each day of overtime. Which is abusive for a software engineer.
And those people that work months away from their families -- they're being abused too. You'll notice that the owners of oil rigs aren't out there with them, for example.
16h a day is more like m&a hours. I don't believe a second that a quant, let alone a dev, in a hedge fund does anywhere near that time. Having to work late on rare occasions is a completely different thing though, and is not "never seeing one's family". M&A guys never see their family, they do those hours consistently.
> I wouldn't be allowed to take my laptop home, so if I had a hard problem to solve, I'd have to stay in the office the whole time. So basically they expected us to never see our family nor collaborate with anyone.
I did. Myself and multiple other commenters all seem to be on the same page, that your original comment says the job required being in the office 8.5 hours per day, and does not allow work from home. Your follow up comments imply the expectations were an order of magnitude higher.
The part you highlighted says you cannot work from home. That’s unrelated to the number of hours they expected you to work.
I think it’s fairly obvious to anyone who has worked in or around finance that while the contractual hours are X, the work requires 2X hours, thus being unable to take your laptop home requires 2X hours in the office.
Perhaps it would have been helpful to actually say that given that this is not a forum aimed at or primarily populated by people who work in or around finance. In a general context, "8:30 to 5 and you can't work from home" sounds like a description of the standard 20th century business schedule.
Are you really, truly not familiar with the idea that the finance industry stereotypically requires long hours and values work over all else, at an institutional level?
OP could have spelled it out, but in any communication there is a level of shared knowledge.
When you read a comment that you understand to be complaining about making nearly a million dollars whilst working 9/5 in the office, a more charitable path would be to examine your own context and shared knowledge, rather than exclaim loudly that OP is a bad person.
When OP wrote they were required to work in the office 8.5 per day, I assumed that they were required to work in the office 8.5 hours per day. I agree with the other guy, if OP meant to claim they were required to work 16 hours in the office per day, they should've spelled that out and not relied on people to guess.
I understand that, yes. But that's not what the original comment says. If the complaint is that ~16 hours is expected, the comment shouldn't focus exclusively on the fact that 8.5 hours is required.
> Are you really, truly not familiar with the idea that the finance industry stereotypically requires long hours and values work over all else, at an institutional level?
Not the person you're replying to, but I was not aware. I guess we have a different cultural backgrounds and some things that are obvious for most of this website are not for me.
Also this makes me even more confused. So OP actually expects being pressured into working overtime (irrelevant where - at home or in the office)? And that's not even their main issue?
What's the point of getting a double salary if you have to work twice as much? Can't they (as a great software developer with a strong work ethics and a good work-life balance they clearly have) just... refuse the overtime?
I do know that finance people tend to be insane workaholics, but I was not aware that "software engineer who happens to work for a finance company" is a fundamentally different kind of job from "software engineer in the tech industry", with a different culture and harsher expectations.
A blind spot, I suppose; I have spent my whole working life in the West Coast tech industry - though discussions on this site generally seem to share that cultural context.
Before covid, working from home wasn't really a thing at the company I work for. That meant I arrived at the office some time before 10, was there for around 8 hours, then left. That's what "not being allowed to work from home" means to most people.
Yes but I think you're missing the point. It's not the eight hours, it was the specific eight hours regardless of any other work you did plus all the overtime that couldn't be done at home. ie. The complete lack of seeing one's family.
how do you know for certain you'd be required to do overtime consistently? you've never worked in the field. I haven't either but I'm not assuming crazy stuff like being required to work 16h a day. your stance is completely unreasonable. There are other commenters who have worked in the field and said no one was expected to be in the office after normal working hours
I met a banking C++ engineer years ago who was the only one left locally and spent his time teaching C++ to fresh offshore engineers in the form of code reviews. He was kind of a manager, though also his manager was probably rational.
1. It makes no correction in how an irrational institution is run that first level managers are rational. It just means they are stressed.
2. I met him at a language meetup for another language, he wanted out but would have trouble making half his salary.
(If you wanted me to trust code written by interns and reviewed across distance and language barriers, C++ wouldn't be my first choice, assuming I got a job in banking management, how likely would it be that I could change anything about that?)
I think it's safe to say that software development drains the brain fairly quickly. We've all slept under our desks a couple times and worked crazy hours for a few weeks, but anything beyond that doesn't sound humane or even possible. I straight up have difficulty conversing with people after those stints. Brain just shuts off. Stare at wall. Then again, there's astronauts and brain surgeons. Apparently trading desks need freaks.
I read that as perhaps having to stay in the office unreasonably long at times when there's crunch towards some deadline, as opposed to going home and working remotely?
I feel like software development is one of the activities that are difficult to estimate. There's scope creep and sometimes all sorts of deadlines for compliance or feature rollouts and so on, so the actual workload can vary a lot.
Not saying that's okay and shouldn't be considered a planning issue, of course.
No, I'm talking about right now. Or as soon as possible. There is no need, in 2023 AD, to work as hard as in the 1900 just to survive. Absolutely no need. Food and shelter could be easily provided for everyone. And if we can't "easily" provided it, then we should strive to do so. We have to shift from old patterns of thinking to new ways, we have to realize that the only thing holding us down is an outdated view of the world, more and more obsolete.
You are only saying that because you come from a position of privilege, where your work is loosely correlated with your actual survival. I don't understand how you could think food and shelter could be provided for everyone, easily, withiur ignoring all the people who work super hard to provide you just that. Unless you just mean that it could be provided easily for some people, as long as the lower stratas keep working to produce what's needed.
1 to 10% of population works in agriculture. This can be lowered even further with robotics and AI (sure, not in 2023, but in 2030, if efforts are made). They will then give us food and society in exchange gives them everything: schooling, medical care, holidays in nice places, maybe even housing in nice places (near a beach or a mountain). But I think at that point most people would work in agriculture for fun and for wanting to do something, and I honestly believe ag-jobs will be subjected to lottery, for there would be too many applicants.
Once food is taken care of, a great pressure would ease off and people would find themselves with more money, which then might be exchanged to less work.
Same reasoning can be apply to housing or even to medical care. The people who build houses would get the best spots for new houses, or the rarest food, or social recognition and status. And so the medics, teachers, etc.
This can't and won't happen in a day. There are many gotchas and unforeseen problems. But we can start working on it and planning and taking small steps towards this goal. It doesn't have to be all or nothing: it can be, for example, 1 hour off the working day every 5 years, for example.
On the planet I live on 30% of global population works in agriculture. Automation is inevitable and is happening for decades. More often than not it does't mean smaller farmers are given nice houses on the beach for exchange of doing nothing, it works more like huge benefits go to single megacorporation, smaller farmers are pushed out of the market to poverty.
The parent comment's wording was funny, but I think the point was that 9-5 was just the start of the commitment. They would have been expected to stay late and work weekends in the office, alone, isolated on their work until it was done.
Any engineering job paying double Netflix comp is going to have very high expectations about hours worked and rate of delivery.
I've worked on a trading floor before, a very nice one (by repute) but it is still a dreadful place to work. Imagine you are expected to do intensive knowledge work with high stakes and executive / management board oversight in the middle of a kindergarten which includes broadcast/loudspeaker announcements every 30 minutes. People shout, people run about, people stand on desks... Bedlam.
Brings back bad memories of my time as a developer in finance (big bond shop on the west coast). Walls covered in TV screens showing CNBC on mute until some bigshot was on (Fed decision imminent!) and then some intern walked around turning up the volume on all the TVs until the bigshot had finished giving his opinion. Ticker displays running non-stop causing more visual noise. Traders and quants running around. Analysts chatting with their buddies at other firms on the phone. Impossible to get in the zone, very long hours and, worst of all, having to do it all wearing a dress shirt and tie.
It was certainly a memorable experience, but one I never wish to repeat.
So....basically my previous work environment as a military officer in a high-level operations center, except with MASSIVELY better compensation? How do I get one these jobs if my C++ skills are "meh" at best and I haven't done finance/economics stuff since I was an undergrad? The stress and scope of responsibilities are almost a non-issue.
Hit the C++ books; pay for some training (there's plenty online). Then study hard for the interview. It's not rocket science to get some of these jobs.
Historically Netflix only had one level of engineer (this changed last year) with a starting salary of $400k, so I'm guessing it was substantially more than half a million.
I've not seen double, but I've seen a 50% increase, at assuredly a much lower comp level than Netflix, so, far higher marginal-utility for that income, and still wished I hadn't done it about 2 months in.
Like, if you'd put a button in front of me and pressing it would undo it like it'd never happened, I'd have pressed it without hesitation. And they weren't even working me long hours or being outright mean to me or anything, the place and the work were just dreary as fuck and it was making me feel like shit even in my off hours.
I had another job by month 4, and took a pay hit (though not all the way down to my prior level) to get out fast.
Avoiding more bad is more heavily weighted than seeking more good in the brain generally but this heavily differs between people. For many, adding more bad is only offset by an rougly an order of magnitude more good.
This is me. There are lots of jobs that you literally could not pay me enough to do, because they'll make my life miserable. I'd rather be underpaid and enjoy working than make millions and hate life.
Abuse comes in many forms. Just because they're paying "well" doesn't mean it's not an abusive environment. In fact, they are paying so well precisely because it'd abusive.
I worked in a high frequency trading company before. They had similar concerns about secrecy but I loved it. Even today I think it was the best job ever. Now I moved to the States and thinking of going back down the high frequency trading route again. I learned so much about computers - probably more then in any uni. By the way, work life balance was way better then in any FAANG company (I worked for two FAANG companies afterwards). Nobody ever expected me to be in before 930am and nobody ever expected me after 6pm.
> Now I moved to the States and thinking of going back down the high frequency trading route again.... Nobody ever expected me to be in before 930am and nobody ever expected me after 6pm.
That's probably because you worked somewhere with decent employee protections, since it sounds like you worked outside of the USA.
I also worked in the space, with Morgan Stanley’s options market making desk. It was all very sane. I’ve heard some of the prop shops and hedge funds can be crazy but not all are like that.
You keep making these sort of statements on this thread while showing an obvious lack of knowledge about what is actually like working in the industry.
I kind of agree with you. Having worked at HFT and now FAANG, I found HFT more satisfying and challenging overall - although it did have its issues, which is why I left.
It's like a start up / small company culture with great compensation - you have a direct impact very easily and it's obvious when others aren't pulling their weight. The one I joined had 10 hours a day (8-6) in the contract, but no one worked more than 8 hours in the office and they actually had very flexible hours as long as you delivered.
FAANG pays well but it is plagued with big company issues which can be very frustrating to talented engineers who just want to get stuff done.
It's also a big problem that trading firms absolutely hate remote work because of their secrecy/security demands. I've been working remote for the past seven years. Sorry not sorry, but I'm never again going to work in a cube farm or an open office bullpen.
It's a pretty drastic assertion (and quite HN worthy) that a whole industry is abusing their developers, based on not even one job, but your impression of a job based on an interview. And assertions like "they expected us never to see our family", because you couldn't take your laptop home? Maybe if you had taken that job, you would have left the office at 5 pm, 95% of the time. Maybe not, of course, but you don't actually know.
I've been working in HFT for nearly ten years, in multiple different roles. I've met well over a hundred developers in the business, have at least a dozen I'd call friends, who are spread over nearly as many companies at this point in time. Most folks have had overwhelmingly positive experiences in the industry. Like anything there are exceptions, but I've seen no evidence of a systemic problem in the field. I know a few people who left my firm to go to Facebook and found it more stressful there, for instance. Certainly, I've worked with very very experienced ex-gamedevs, who would say unequivocally that developer abuse is a far bigger systemic issue in game dev than in finance.
Obviously it's fine to post your take but it should be tempered by the relative amount of experience you have.
The pay & the taxes, mainly. It is more fun owning one of those German cars than helping write their software.
> Maybe it's because I'm looking for fresh graduate jobs...
If you are just starting out, observe that the point of a job is to make money. Give serious thought to finding a job that pays well. Most people you see are working solely because that makes them money, although optimising $/hr is usually not something people regret.
I'm not American. I think almost all European cities are a lot smaller and a lot less dense than Singapore is. And they have equivalent public transport, amenities, etc.
Make no mistakes, I don't have any illusions about cultural differences and am perfectly aware of grass-greener-on-other-side syndrome. I just don't want to be stuck in a 700 km^2 island all my life.
> It was the fact that I would not be allowed to share my work internally. I would not even be allowed to brainstorm with people doing the same job in other areas of the business.
This is what Apple does as well. So not all FAANGs are equal here.
My understanding is that Apple will let you collaborate after what you're working on is public. They just don't want people accidentally sharing unreleased stuff with people who aren't cleared to know about it.
I've been told by folks who work on infra there that they need to file requests to even talk to the previous owners of code if that person has moved to a diff role. So I don't think it's just for unannounced products.
Once something is released, there's general access given for that particular software/hw but it still needs to be requested. In a weird way, it creates some internal excitement on "secret" releases but obviously makes development much more difficult.
You didn't take a job because it's 8.30 to 5 and because of some undefined 'abuse'? That's what you've written?
Maybe it really isn't for you. On the other hand I've worked in this industry for 30 years, and done those hours, and longer, for 30 years, and enjoyed more or less every minute of it. I've flown all over the world, and been to various events and conferences that I would not have had a chance to do in another career.
I'm not clear what 'abuse' you think you're going to get. We are in a fortunate position in life actually, that we're developers that can change jobs on a whim and there's a large marketplace for our skills.
My advice to you is that you should actually have taken the role, gained some experience of a different industry (the first 6 months will be low responsibility), and if it's not for you, leave.
> It was the fact that I would not be allowed to share my work internally
I've only heard of one company that's as mad as that and they start with 'G'.
I worked for the G company I'm assuming you're referring to :) I left because of the insane paranoid culture.
I do however share the same sentiment as the parent poster - I interviewed for XTX for a c++ role when I quit and during one of the interviews I asked about on-call rota and out of hours work.
The answer I got: "oh, it's not too bad. We have a weekly rota, you can expect to get called maybe 3 or 4 times... a night".
I noped the fuck out of that.
Others like Citadel and Jump were similar stories. Many have made offers but a combination of insane out of hours requirements and non compete clauses means I've told them all to shove it, and took an "underpaying" role to achieve some kind of balance in my life.
That was 6 years ago and it was indeed tough back then, we were rewriting a huge trading system from Java -> C++ while trying to keep our edge. However, we succeeded and things have changed considerably since. We also have a dev working in Singapore now which makes support significantly better.
We were at least honest in the interview process regarding hours, there are companies where you would only find that out after starting. There were people who were willing to go through that pain and I think they would agree they were well rewarded but I understand some people want different things from their careers.
Indeed, I was very grateful for the honesty, because the roles otherwise seemed very exciting.
However, the moment someone would've announced that this was the reality of the situation I'd have walked out the door, because that is NOT normal under any circumstance.
Parent poster explained this very poorly, but it's not as simple as "office hours are x to y".
You are responsible for a trading system that's turning over hundreds of millions a day. If you're not in the office by 8am or whatever, that's not a "hey you were a bit late this morning" - it's a major "wake up the CEO the engineer on call is not present and we're not trading"! It's BAD. your train ran late? Doesn't matter, you're responsible. Your boiler exploded? Leave your house flooded, work comes first.
It's EXTREME pressure all around. I've done overnight support for a fairly infamous quant fund and I'm still on medication 5 years later because of the anxiety disorder I developed whilst working there. To this date the Blackberry ringtone triggers a PTSD response and I get physically sick if I hear it.
I'm sorry to hear about your experience, that sounds rough. I do know that support roles in the finance industry hit _hard_ and the difference between one person's work environment can be the complete opposite of someone else in the same position in a different company, or even in the same company but a different team.
I spoke with someone recently who is in sales for a large finance behemoth we've all heard about and even that person was like "Goldman is the worst, I'd never go there."
But, most developers in quant roles, or close to quant roles (trading infrastructure, research support, etc) do not experience anything like this. On call is rare for these positions and they have regular work schedules with normal hours. Plus the compensation is multiples of what someone in an overnight support role will get paid. You probably know all this.
I'm a developer in a quant role, and basically every job I've looked at in this market has similar requirements. See my other comment in this thread about the absurd support burden at XTX markets.
I was at Man AHL for 5 years after leaving GR and that is a pretty laid back company in comparison. I was not on a trade critical team per se, but some of our system were used for pre-flight checks. As such, if there was an issue the on call person got called at 5 am to sort it out. If not resolved within an hour or so, the cio/cro got called and had to decide whether to trade regardless or not. Thankfully not a common issue but definitely at least a call or two every time you did support.
>Basically, they were so worried about secrecy of their trading algorithms and people sharing them with other companies, they didn't even let people share internally for fear that one person would learn too much about their business.
That's probably actually required though.
There's a book called 73 Rules of Spycraft by Allens Dulles and these are obviously relevant for financial trading:
Rule 2, 3 and 4, are I think, the relevant ones in this case. Especially 4:
>No matter how brilliant a given individual, no matter how great his goodwill, if he is lacking in security, he will eventually prove more of a liability than asset.
These firms are in the business of finding and exploiting opportunities in the markets, before too many people know about them and the opportunity disappears. One person who knows too much could be an existential threat to the firm.
As someone who is a huge proponent of Free Software an an open culture and also who now runs a trading firm now, I completely agree with you. The industry is incredibly frustrating, especially to engineers and scientists. Because, by our very nature, we want to share our ideas and collaborate, because the best work is done together. There are no secrets internally at my company. Because I believe, in the long run, and open culture will win.
But you aren't wrong about the industry in general. It's crazy frustrating.
Netflix separated pay and performance. Your performance was evaluated all year, and if you weren't a top performer, you were let go. In the spring we would do 360 reviews, where anyone could write a review of anyone else, to give candid feedback (although giving candid feedback was encouraged all year, but this gave you a formal outlet to do it).
In the fall, your pay was evaluated (and kicked in at the new year). You were paid on the assumption that you were a top performer (otherwise you would have already been let go), so they would adjust you to "how much would we have to pay them to get them in the door today". They needed data for that calculation.
One source of data was how much they had to offer new hires to get in the door. A second source was industry salary surveys. And a third source was your offer letters from other companies, if you chose to share them. If you get a huge offer elsewhere, they would maybe match it, or maybe tell you that you're better off going to that other offer.
It also served another purpose. It gave you a chance to look at that other offer (assuming you could get one) and really thing about whether you still liked your job at Netflix enough to stay. They wanted people to be happy about continuing to work there, and were supportive of you leaving if you weren't happy, because they know you do your best work when you enjoy it.
FWIW, my raises at Netflix were typically 20%+, and so were a lot of people, because they economy was on fire at the time.
No, not at all. You didn't have to be a top performer at Netflix, you had to be a top performer industrywide. Netflix basically tried to keep only people who would be rated as top performers at other companies.
Think of it like a sports team (which is how Netflix always described it). They wanted the best people in the league.
Didn't it make you feel as though there was a target on your back constantly? What happens if something in your personal life results in you having a bad quarter?
Yeah that sounds like a nightmare. Then again, I'm only a solid B+ (grading scale, not language) engineer and I'm happy with that. I'll let the gunners take the target-on-back jobs.
Btw, can Netflix please put some of that capital in to better programming, or at least in to adding a "Delete + never show me this or anything like this every again" button. Platform is a pile at this point. No offense
Did you use that 700K offer for increasing the salary at Netflix?
I've heard about the culture of fear at Netflix - was this your experience as well? Who decides whether you are a top performer or not - only the manager, or the peers as well? Do they use stack ranking? How is the performance deduced, e.g. by nbr of commits? Thanks!
I took the offer to them and got a nice raise, but not to $700k. :) In part because the offers weren't comparable. Finance is usually a modest base and a huge bonus, Netflix is straight cash.
> I've heard about the culture of fear at Netflix - was this your experience as well?
At first yes. But you quickly realize that in most cases only the underperformers were let go. In cases where good performers were let go, it was usually by a bad manager, and then that manager would get let go and they would sometimes even offer the other person their job back (but they usually already had another one).
> Who decides whether you are a top performer or not - only the manager, or the peers as well?
You manager has final and single say on both hiring and firing. But they always ask for input from others as a matter of course.
> Do they use stack ranking?
Absolutely not. Stack ranking is the opposite of what Netflix believes. They operate on the assumption that if everyone were stacked ranked, everyone would be in top rank. Stack ranking is evil and a terrible way to run a company if you use it for determining compensation or firing.
> How is the performance deduced, e.g. by nbr of commits? Thanks!
Haha no, no metrics like that. It's much more holistic. Are you getting good work done, are you making a positive difference. Managers are pretty in tune with the work getting done. Most come from engineering backgrounds and at least understand the work being done by those that report to them. They also can see all the feedback in the annual feedback session. It becomes pretty obvious who is not performing.
> In cases where good performers were let go, it was usually by a bad manager, and then that manager would get let go
I guess this is rare - the detection of such cases, since the bad manager's manager has to be aware. Also, the holistic evaluation makes things hard to argue - subjective opinions prevail.
Netflix would increase the salary of employees if they had higher offers. This idea is supported by Reed Hastings and IIRC was mentioned in https://www.norulesrules.com/. To get a raise, you are encouraged to get a job offer with that salary to prove you're worth it.
I know people here have a lot of issues with the word "abuse", but that is true. I only had a few days in my life where I was productive in the office for that long. Just after three days in a row of 8:30AM to 6PM would burn me out and I would be sleep-deprived and useless for the rest of the week, so why am I forced to suffer? They are paying one lemon a year so I HAVE to be in the office? It's just amazingly stupid, but that's American school of management for you.
I did crazy things when I was younger, and I would NOT subject myself to those now, so yeah - abuse.
It's a bit melodramatic.I work on a trading floor in Hong Kong from 9 to 7 which is less than most colleagues and allows me to take my kid to school in the morning and see her plenty in the evening (my dad had a small store and he'd do 8 to 8... 8:30 to 5 is really not normal neither in France or Hong Kong where I worked).
I can remote work, or remote connect to solve a hard problem, there's ofc a way to change these. As for sharing code internally, yeah, I fight for it and I get it (I m a Java dev and we need to reverse a lot of old C++ that the OGs gatekeep, takes lots of escalation to breach the "need to know" BS).
I think you can largely lower your salary to get a more junior position with no stress: I was a team lead working 6 to 11 in a startup jungling with timezone between mexico and Indonesia, and I joined the investment bank as a junior idiot for a cool 20% increase. And I refuse promotion, why do you think you d be forced to take the money and the pressure ?
I wouldn't really call it abuse, as long as all those expectations are clear up front. If they cannot function without those expectations being met by their developers, and are willing to pay a significantly higher salary to compensate for the inconvinence in comparison to other jobs, it just is what it is.
You forget the abuse. In most jobs software engineers are the revenue generators. In the trading industry software engineers are just something that stands between the traders and their bonus. And the traders can get really rude.
That is _not_ what he said at all, and many others have said as much. He said he was going to be _abused_. Really? Abused? Only someone with an extreme level of privilege and disconnect could use that word in that context.
And he complaints about abuse while working for... AMAZON. Seriously? The irony is palpable here.
I have yet to hear the stories about Citadel firing workers because they took a bathroom break.
when i interviewed for netflix i had to study their ridiculous culture document and found out it was a cult. i heard terrible stories of people being insulted openly. and you have to deal with endless leetcode bullshit interviews at FAANG which have nothing to do with your job and which disregards the years of experience you’ve built up all in the name of interviewing efficiency.
FAANG people don’t understand performance or latency anyway. they are focused on other things typically.
> There are plenty of talented C++ programmers. They just don't want to be abused by trading firms or work in that culture. Even paying them more won't work, because no amount of money is worth that abuse.
With all due respect you don't know what you are talking about. This doesn't represent my 15+ year experience in that domain.
> But I would have had to work in their office in Manhattan, be in by 8:30am every day and not leave until after 5 at a miniumum.
Must have been a back office job because that's not early enough for trading hours.
> They just don't want to be abused by trading firms or work in that culture.
Tell that to the hippie pinko commies. I love trading firms and their culture. What I don't like is IBM style artificial pushing of "company values" and the kind of dystopian "sensitivity training" right out of an orwell novel.
I feel like I am in a decently unique situation where I learned C++ throughout my preteens and teens, and got a job straight out of high school writing C++ for Unreal Engine applications. Most of the C++ jobs I see when I look are things that I just honestly do not want to do.
I don't really mind working with the language and wouldn't mind sticking with it. But I don't want to work on financial software, as I don't want to mess with people's money. I work in a game development context right now, and may for the foreseeable future, but I also know that I get paid less than others at my same level in a different context. That part hurts with the way inflation has been lately.
I think in the end, those factors drive me away from trying to further my career in C++ and instead move toward something that would at least pay the bills in the future. I didn't start with C++ and could pivot to other languages and stacks as needed. But it would be a bit painful to know that I put a lot of time into this language to just not use it and let the experience rot.
This also doesn't factor in the numerous jobs that I have seen postings for that I am not qualified for, according to their description. It's hard to become a Senior C++ Engineer when no one is hiring a Junior to Mid C++ Engineer. Probably part of the lack of "talent" is not wanting to invest in cultivating that talent.
FWIW most of the folks who work with C++ in the financial industry are not really "messing with people's money" except in the sense of trying to exploit market inefficiencies to take it. In a typical quant hedge fund no actual money changes hands; instead, the C++ parts are there to perform analytics extremely quickly, which then feeds into an execution engine (usually also in C++, or sometimes Rust or assembly) that's sending trades to the exchange. And they're usually trading their own capital or a small set of very wealthy limited partners.
The retail financial industry, the folks like Fidelity and Vanguard that manage money for ordinary people or folks like Bloomberg that supply data for this, largely runs on Java. There are fewer foot-guns here, and you really don't want a security vulnerability that loses your customer's funds or creates an inaccurate statement.
Well yes, but the gaming industry is all about exploiting psychological efficiencies to take your money. Big Tech (in its advertising/retail/OS forms) is all about exploiting psychological inefficiencies to help other people take your money, and then taking a cut of it.
If you mean "gaming industry" meaning gambling machines, then yes. If you mean "games industry" as in video games then it's just not true that it's "all about exploiting psychological inefficiencies". There are many monetization strategies that are not exploitative that are common and even dominate in the market. Ubisoft, DLC, or Candy Crush freemium models are not representative of the whole industry.
AAA games with one-time payments are still exploiting psychological inefficiencies; there is a reason why we are evolutionarily hard-wired to pay attention to fast-moving visual settings where action is required from us.
For those who say "but I like to play video games" - yes, that's the point. Day traders like to speculate, and gamblers like to go to the casino. Your downside is capped with one-time payments, but a gambler who goes into the casino with a $20 and no other money also has a capped downside.
Arguing that one-time payments with up-front pricing are exploitative is pretty silly. That's the basis for the entire economy since we invented money thousands of years ago. If it's exploitative then you're basically lumping all economic transactions into the same bucket, which makes it fairly meaningless.
Unless you're selling me living in a cave foraging for nuts and berries, you're trying to exploit some psychological inefficiencies.
I do get what you're saying, but if you take it this far then literally everything sold is considered exploiting inefficacies, psychological or biological, and it's kind of a useless statement in the context of comparing markets, only useful as part of an overall critique of capitalism.
All I meant was the games industry gets a very bad rap for being dopamine driven skinner box design and it simply isn't true, and being in the industry for 15+ years I have met very few people who are comfortable exploiting psychological effects for gain. If I was in a different part of the industry I probably would have met a lot of people who ARE comfortable with that. It is there. But it is far from "running solely on" that attitude.
Of course they take money, but they hopefully also create real value.
Providing liquidity a fraction of a microsecond faster than a competitor doesn't seem like real value to me, more like a cover story so that politics doesn't outright forbid high-speed quantitative trading.
Ahh classic. Obviously only these financial firms are the only ones not creating value.
Those social media companies, start-ups people do for venture capital cash grabs, Web3, and addictive mobile games all create such value.
EDIT: Okay, as the replies mentioned, OP did not make this argument. I still feel it’s valid, as a lot of big tech is neutral/worse for society, yet they are some of the loudest critics of low latency liquidity.
If you ask most financial institutions they would say the service they provide is "liquidity" - they let you put your money in or take your money out at any time (in exchange for securities), as well as make decisions about where you want to allocate your capital based on your personal view of the world.
This always fell a little flat to me (hence why I left the financial industry early in my career), but it's pretty analogous to merchants or retail. What service does a storefront provide, other than marking up the wholesale price of a good by 3x? They offer convenience - you can buy anything you want at the time you want it just by picking it up and swiping a credit card, vs. having to contract with a wholesaler for delivery, which might be months in the future, at a place that's convenient for the wholesaler, and needing to buy in quantities that no individual really needs. So it is with brokerages & exchanges - they let you buy any security with a couple clicks of a button, vs. needing to get an ISDA and pay a lawyer to write a contract, plus find someone else that wants to trade with you, plus take on the risk that your counterparty goes insolvent. And so it is with market-makers like Citadel or Jane Street: they ensure that you can always find a buyer for your securities (for a price), and that you don't have to worry that about simply not being able to sell stocks at any price.
> If you ask most financial institutions they would say the service they provide is "liquidity".
I've honestly never understood this. Economics 101 teaches us that artificially manipulating supply (liquidity) is at direct odds with a free market's ability to do price discovery. If there is effectively infinite supply of any security (because all these high frequency firms are instantly hedging out the risk against their entire portfolio), why should anyone believe the NBBO? It's just a made up fantasy number at that point. It doesn't represent what the real security is worth because there are an infinite number of buyers and sellers willing to transact at any moment.
HFTs and other market makers are time- and risk-shifting supply & demand. In a functioning market, you can always find someone else to take the other side of the trade if you wait long enough, but you may not be able to find them now. Particularly in market panics, where all the buyers tend to disappear at once.
What a market maker does is say "Sure, I'll take the other side of the trade - right now, at this price, even though I don't actually need or want the security. And I'll take on the risk that I might not be able to find a counterparty later. I trust my knowledge of the market enough to believe that the price I've offered you is one where I can profitably unload it later." And if they're wrong about gauging future supply & demand, they go bankrupt. Markets function on survivorship bias; repeat this cycle for long enough and the only market makers left are those that are extremely good at gauging future supply & demand and using it to set spot prices.
On some level, they're arbitraging risk & rationality. A retail investor makes a trade that is locally rational - perhaps they need to sell stocks to pay taxes, or purchase a home, or they've lost their job and need a savings cushion. And many of these events affect multiple people all at once (eg. everyone paying taxes on Apr 15, home sales peaking in the spring and declining in December, a recession causing people to lose their jobs all at once), which leads to temporary declines in demand that don't at all reflect the discounted value of all future cash flows of the stock market. Market makers smooth out these fluctuations, buying & selling stocks when it's globally rational based on the fundamentals of the companies and holding inventory when short-term supply does not match long-term supply.
> HFTs and other market makers are time- and risk-shifting supply & demand. In a functioning market, you can always find someone else to take the other side of the trade if you wait long enough, but you may not be able to find them now. Particularly in market panics, where all the buyers tend to disappear at once.
Time shifting risk would be perfectly fine if market makers had to play by the same rules as everyone else in the market, but they don't. They get to ignore certain rules, which results in distorted prices because they can effectively accept infinite risk over an infinite length of time.
Let's say there's suddenly a run-up of $WEN and I, as a retail investor, want to short it because I think the price will surely come back down eventually. If it continues to go up, ultimately I get margin called and have a very short period of time to produce a lot of money to keep that trade open, otherwise I'm liquidated. There is a (risk * time) maximum before I, the retail investor, ultimately go out of business.
Market makers are exempt from this. They are legally permitted to short stock by conjuring phantom shares from thin air without having to locate borrows to satiate the buying demand during the run-up and wait effectively an infinite amount of time to repurchase the shares. There is no limit to their (risk * time) budget. Better yet, when the underlying company ultimately goes bankrupt from the stock being cellar boxed into the ground, the market maker can just wrap up all the worthless, sub-penny shares into a zombie holding company which lives forever, so they have never close the trade and actually pay taxes on the ill-gotten gains. Meanwhile, nobody seems to bat an eye at tens of billions of "securities sold, not yet purchased" on the market maker's balance sheet, because hey, as long as the SEC remains a wet noodle thanks to regulatory capture, they'll never get charged with fraud and the music keeps playing.
It's a system that has been deliberately structured to screw over average retail investors and concentrate wealth behind a few large market making firms, which incredulously all have their own hedge funds (which is somehow not seen as a hilariously brazen conflict of interest). Whenever anyone asks why all this complexity is necessary, the "We provide liquidity, so you can trade right now, for free!" line is trotted out and they hope you go away so they can continue running their shell game. Our markets have become addicted to this fake liquidity, which is ultimately backed by an infinitely expanding risk balloon. As long as the balloon never pops, the game is still on.
> artificially manipulating supply (liquidity) is at direct odds with a free market's ability to do price discovery. [...] there are an infinite number of buyers and sellers willing to transact at any moment.
No, there are not. There is a limited (and not really that large) number of active participants in any given market segment, and the 80/20 rule holds among them pretty well too. Thanks to Money Stuff it dawned on me recently that market makers are not really providing liquidity. They provide immediacy. Buyers and sellers have to meet not just in price, but in time too.
The spread paid by market participants should be seen as their baked in commission for providing a very specific service: reduced wait time. We can certainly disagree about the societal value of what that service has morphed into, but the reality is that for other than the most liquid[ß] assets, participants are willing to pay extra for the ability to transact NOW, and not in some unspecified time in the future.
My personal opinion is that NBBO is an imperfect mechanism to set upper bounds to these commissions. In other words, it limits how much retail transactions can be fleeced for.
I am without a doubt a retail investor: I generate maybe three transactions a year, and I'm happy to pay something like 0.15% to 0.25% transaction fee each time, in the knowledge that I am getting a fair price at the time. To me that is a reasonable cost of convenience. My transactions are so small compared to the trading volume that they have zero price impact: in purely financial terms I could be paying a smaller commission if I set up the limit order thresholds myself - but that would take more time and be less convenient.
[ß] Read: continuously traded in very large quantities
The average retail investor just does not need that much liquidity, especially if they're not buying individual stocks (which by and large they shouldn't be).
And the average retail investor pays pennies to market-makers - if a typical spread is 1-2 cents and you make 5 trades a year, you've paid between a nickel and a dime.
As with advertising, when you sum up dimes across hundreds of millions of people, it becomes an appreciable amount. Particularly when you also include trades made by institutions on behalf of retail investors. Your 0.5-1.5% management fee on an actively-managed mutual fund is partially going to pay salaries for the fund manager, and partially toward brokerage commissions, spreads, etc. for the trading itself. And mutual funds care a great deal about getting liquidity when they need it, since they're in breach of contract if a flood of redemptions come in and they can't liquidate assets to pay them.
(Market makers are also analogous to the credit card industry in that a small fraction of dumb people subsidize a large number of fiscally responsible people. If you get a rewards card with no annual fee and always pay it off on time, you turn a profit, paid for partially by merchant fees and partially by idiots who carry a huge balance at 25% interest rates. Similarly, if you buy-and-hold a good stock or index fund, you're making profits far in excess off what the financial industry can skim off you. The suckers are largely made up of day traders, wage slaves who can't save anything, and underfunded pension funds with principal agent problems.)
> Your 0.5-1.5% management fee on an actively-managed mutual fund is partially going to pay salaries for the fund manager, and partially toward brokerage commissions, spreads, etc. for the trading itself.
Good post but your management fee isn't generally paying for crossing the spread. That's extra slippage.
It may show up as tracking error in the fund (the price was 10.25/10.26, the fund had to buy, it bought at 10.26 and the index trackers said the price was 10.255, it had 0.5c of slippage). But more likely the fund traded in the closing auction, there was only one price so it officially had zero tracking error, but the price was silently a little higher than it would have been if the fund wasn't buying.
Levelling prices between markets is a useful service. Eventually the amount being skimmed is tiny and regular consumers are much more likely to be getting a fair price without having to shop around.
Exploiting information asymmetries to funnel other people's money into your pocket before or without them knowing it. No value had been generated, it's just extraction.
Yeah but then you go in to interview at these places and someone who only programs javascript or python will ask you to answer a contrived whiteboard question by hand that involves manually writing out verbose C++-isms like "std::unordered_map<uint64_t, std::string_view> hashmap;".
I went through a day of interviews at Facebook once where not even a single person interviewing me worked in C++. A lot of the interview cycle consisted of me answering basic syntax and STL questions or clarifying my handwriting which made it extremely difficult to finish the problem in the allotted time.
I interviewed at Facebook using C++ and didn't have any issues. I guess maybe you were just unlucky. There are thousands of interviews so it happens that some are bad and you might get them.
And if you think C++ is too verbose I guess you've never interviewed in Java?
Personally when I interview people I don't care about specific syntax details. I do have at least a passing familiarity with 99% of common languages though, I think only once (out of ~500 interviews) did someone use something I had never seen before.
Google interviewers sign up for particular languages and are expected to have proficiency in the language. As an interviewer, I also allow a lot of abbreviations (so long as we agree during the interview what they are) and I expand them in the digital writeup. That makes large generic types in Java/C++ a lot easier to interview with.
Only finance and game dev was a little bit of hyperbole. I do see other jobs for like aerospace or GIS, at least looking at job postings on LinkedIn. Though I most assuredly do not have the requisite skills outside of just C++ to work in those fields.
I think big tech has the same issue where they don’t want to cultivate talent. I doubt Google or Microsoft would consider me at this stage in my career because I lack a college degree.
I will say that I do get recruitment emails from Amazon, though I’m sure those are just shotgun blasted to anyone with a pulse and a LinkedIn.
> I doubt Google or Microsoft would consider me at this stage in my career because I lack a college degree.
Don't know for sure about Microsoft - but if you can get a referral at Google, they will definitely consider you. A college degree definitely helps you get to the interview stage, but doesn't do much more than that. A solid referral pretty much guarantees you an interview.
I wonder what percentage of devs would still want to take a job for Elon Musk on normal competitive terms, though. I would demand getting the severance pay up front for example.
yeah im starting to get into the mindset of "fuck doing what you love, just get hobbies"
Ultimately, working in these high paying jobs lets you have a lot of great hobbies and enjoy life. Get a job with a decent work-life balance, and use the rarity of your skillset to make the crazy cash, retire early, make your own game company if you want.
I think both ends of that spectrum are fine. If you really do mostly love your work, and you can afford necessities, then that is just as good as getting paid oodles to do a job you don't hate that gives you time and money to do exactly what you love.
The traps are convincing yourself you love your job more than you actually do, or that you don't hate your golden handcuff job and the hours won't always be this crazy...
And paying the opportunity costs. "Oh man I love working on this game, surely someone will recognize me" all the while putting major life things on hold, like having a kid, or securing your future.
I know a guy who LOVES his job/company and knows he's underpaid. But he's set. Has zero plans on having kids. Has his own place. 100% secure. So he can afford to do whatever. But many who have bigger goals in this economy have to follow the money.
Tip: Amazon Games pays above game industry standard, hires for Unreal skill, and has options for good work/life balance. (Like any large company, it can depend on the particular game team. Moving to other teams is generally supported, if the needs and skills match up.) And answering one of the other sibling replies: if you apply for one of the games reqs, you'll be interviewed by members of the game team that posted the req. If it's a C++ role, you'll be interviewed by someone who uses C++ on the job.
You will benefit from doing your interview homework first. Make sure you know the Amazon Leadership Principles by heart, try to have 2-3 solid examples at the ready of how you exemplified each one (some matter more than others), and be comfortable solving little programming challenges (I'm sure it's happened but I've never seen some of these Google-esque obscure tree challenges get asked). Lots of good Amazon interview material out there, I recommend reviewing it. Also, I hear some recruiters can help you prep.
The problem is that all the titles Amazon Games has developed were either flops on release or were cancelled, and the reason it’s still alive is probably because of its parent company having too much money to spend. Maybe it’s the “corporate” Amazon culture having a bad influence to the studio’s creativity… But really they seem to have no idea on how to make a game that people would like.
Yep, we have a lot to accomplish. I can only speak for my own experience but I've enjoyed the ride so far. And if Games gets old for you, broader Amazon is also supportive of transfers. Amazon's got a zillion interesting projects going, so there is a lot of opportunity to scratch whatever random itch you get. (Many use C++!)
How's your work-life balance? I worked in the games industry a couple times, at Activision in the 1990s and later at Rockstar, and like almost the entire industry, everybody was in crunch mode almost all the time. I remember when the list of holidays came around one year, Christmas was on a Saturday so they gave us Friday off. Someone asked if we were also going to have the Saturday, Christmas day, off.
Programming is essentially solving puzzles, so you can find the work interesting even if the topic area isn't interesting. No seven year old says "when I grow up, I want to write a memory allocator!" but doing it well, with as few CPU cycles as possible, without fragmenting memory too much, is an interesting challenge.
I wouldn't worry about what people have in their job descriptions. There's a quote from John Carmack about an ad for a Oculus dev that he technically wouldn't qualify for, and DHH who invented Ruby on Rails, was called by a recruiter asking whether he had 10 years of Rails experience when Rails was only 9 years old. A "Senior C++" engineer might just mean more than 2 years of experience with C++, who knows.
Heh. I'm pretty proficient in modern C++, and it is my favorite tool for a lot of things, but my PHP job pays way more than any C++ position available. Did an interview once for Senior C++ Engineer, embedded software in the medical device space. All went good, until the offer: $100k.
Articles like this are nothing more than a desperate attempt at getting younger generations to learn said topic, so companies can pay them crappy salaries.
It's not the C++, it's the embedded. Embedded is paid miserably, everywhere, no matter how complex or interesting. Simply put, having to manufacture things, with its supply chain, warehousing, manufacturing, ... is never gonna have the margins of a purely software or financial product. Since the employees' salaries depend on the profit from that physical thing, it can never compete w/ software / finance.
The only well paid embedded jobs involve producing weapons ('defence') or gambling ('gaming'), and I'd rather sell crack to kindergartners while also prostituting myself than do that. I did get a bunch of those offers and still do get them every now and again, even though I'm happily employed.
Moved to finance, never looked back. People should plain refuse to work in embedded, maybe then thing will get better.
Also, C++ is the differentiator. People hire for other languages (C# and Rust, in my experience) based on your deep C++ knowledge. And this does make sense, this is a great proxy for your development skills and potential.
Do you think the many embedded engineers working at Apple, TI, AMD, Intel, etc are paid significantly worse than their higher level software counterparts?
I do, in fact. The reason is that most embedded people are recruited from the ranks of EEs. At least around here (Europe), 1.5-2x more EEs graduate each year compared to CS people, and EEs doing EE stuff are paid even worse than embedded, it's a step up for them. They don't and likely can't ask for more. Surely, some EEs learn CS stuff on their own and start working dev jobs, but they're the exception.
I've worked with a lot of EEs, and their general programming knowledge (especially knowledge of best practices, tooling, software architecture) is way worse than CS people, in general, across companies and countries. Every time, the best devs were CS, even when it was 100% embedded or even FPGAs (which are not taught to any CS students, yet are taught to every EE student). I personally know maybe a couple of EEs that are great devs (through their own effort and interest), compared to at least a dozen of CS people. However, CS people generally know almost nothing about analog design and at hundreds of MHz (table stakes for serious stuff since 2010) things start getting pretty analog whether you like it or not, so you have to hire EEs anyway.
I interviewed for Amazon for an embedded/mixed role because that was my forte at the time, and the compensation offered was nothing special, worse than even a mediocre finance sector offer, much better than automotive or general embedded (medical, industry / robots). Could never get an Apple interview (they passed on me twice), though, and I never even thought about the rest (that would require relocation to to places I don't care about).
But since I never actually worked for those companies or have any concrete data I could be completely mistaken. I only have friends working in FANGs in non-embedded roles and embedded friends only working for shit-paying companies, plus some of them are not willing to discuss salaries (suckers). Also, I get the feeling that AMD / Intel / Nvidia operate a bit different than the rest.
For reasons I can only speculate on, EE programs enlist way more people.
It may be because EE is older and more entrenched, or because of ties with the industry. Engineering of any kind has centuries of prestige, historic industrial support, historic large buildings and grants, etc. I would bet on the comparative ease of hiring staff for EE, though. It does make some kind of sense for some academy-prone people to go the academia route in EE. Especially if you sprinkle in some industry side-jobs, because the industry side is not that cushy by itself. This likely makes it easier to staff EE faculties. For CS, academia only makes sense if you have direct industry support (like doing machine learning w/ direct support from a FAANG), and you can expect something like that in very few places in Europe (Zurich, London, maybe Amsterdam?). Otherwise, you really have to hate making money and being respected to get into CS academia. There's a distinct lack of staff for CS, and they let anyone be assistants (at least they did half a decade ago). I remember there being some competition for math positions, and a free for all in CS. Some smart CS people do get fooled into joining, and last around a year until they see it's a waste of time. No amount of academic benefits in later life can offset the accumulated difference in pay.
As an actual failed EE student (moved to CS after 1 year of EE an eternity ago), I definitely agree that it's way harder. I even think that it's not just my affinities, but it objectively requires more effort and is more dense with difficult stuff. What's ironic is that the (officialy!) best EE student of that generation is now a Rust dev for some crypto company (last time I saw him on LinkedIn).
One of my high school teachers, who I respect a lot, argued that what a CS grad can do, an EE grad could as weel, and more. Therefore he recommended the EE career.
I wanted to get away from physics so I ignored that, and in hindsight it was 100% the right choice. But the advice was well intentioned and I considered it.
Labor supply stories never talk about salaries. I can also see lots of references to embedded and close-to-hardware jobs, which means low salaries, unsexy code, and flawed/buggy toolchains compared to mainstream platforms.
It's right there in the article: "demand". Why do business people pretend basic supply and demand first day microeconomics 101 doesn't exist as soon as you say "labor"?
I suppose this is more fuel for Rust adoption. Rustaceans, is the war won?
Btw, it is INSANE that we pay engineering positions (you know, real ones like electrical/hardware/materials) so poorly compared to software devs. Engineering has professional organizations which, like the AMA, should be able to enforce some degree of good pay.
Big companies don't post profits for tax avoidance reasons. They use various strategies to minimise profits - or ideally operating at a loss, so that they don't pay tax or very little. They also use this as an argument "look we don't make any money so we can't pay you any more", while at the same time you hear CEO buying themselves another supercar or a beach house.
It’s the growth, not the profit. Software engineering is a lever for growth for businesses designed that way. If you can grow revenue by $100M by spending $10M on engineer salaries, it usually makes sense.
On the other hand companies with steady profits and little growth have no such expectations and try to pay as little as possible for the software engineers they do need.
I had a large group of devs I used to hang out with. It was about 50/50 front-end and C, C++ guys. Over the last decade or so, every single C developer either transitioned to PHP like yourself, or went the full-stack JS route and have never looked back.
And it was all over the issues around dealing with legacy systems and the poor pay. One guy told me flat out he can make close to twice as much being a very in demand JS developer with great benefits and reasonable hours compared to the horror show of working in government (military) or finance.
I used to work for an industrial company in the defense sector. We were working on very complex problems with difficult requirements in term of resilience and performance. It was extremely interesting: complex algorithms, redondant architecture, hard real time development, most of it in C++ or Ada. Deadlines were tight. It was quite stressful and the pay was miserable.
I left the field entirely but most of my former colleagues now work as fullstack developers for companies building SaaS solutions. They all complain about how boring it is but they all have doubled their total comp.
Meanwhile, I heard from my former boss that the company still complain that the part of the org doing software is more expensive on average per employee that the ones doing production (apparently no one has realised we don’t hire blue collar workers in this part of the company) and keeps grumbling about how talent is too hard to retain in my city.
Knowing people who work in the defense/military sector, this is what I gather as well. Pay is lower, sometimes much lower, compared to other jobs. I know some people stay in it out of ideology, or because they're natural lifers, drifted there, it was ok, and they stayed, not bothered by the low pay very much (no hard feelings, I'm a natural born lifer too!). It can be stressful but I gather that those companies slowly start to realize they're losing their old workforce and try to attract younger crowds by making the work environment "modern, young and dynamic" like startups (except for the actual pay, of course). I don't know if it works. Probably not.
Hmm, what is the highest paying JS job you have seen/heard of? I am not particularly good and by far the highest quote I've ever gotten was ~100k euro after taxes. Not bad at all but required relocation.
I've a frontend-only friend at $big_tech_co who's on $200k TC post-tax with a half decade of experience. Lives in a major metro area in the US, not sure what their rates are abroad.
In general, the big cos hire maybe 1 JS dev for every 2 or 3 backend devs. But they're on the same payscale. From what I've heard, it's more challenging to climb the level ladder, but if you come in at a terminal level and aren't particularly interested in that stuff, it's pretty comfortable.
Midwestern state, large health care company - between $150-$200K (this is FTE status with benefits)
You can also be a contractor (hourly, no benefits) and squeeze a bit more out and just jump around from company to company. Senior JS devs are in seriously high demand right now. I get around 5-6 emails a day from recruiters looking for Senior JS devs.
Think about how web companies can have very low up-front costs, use a cloud provider and some high-level frameworks for python or JS etc, make a stupid social-media connected app, and start making big money (or get investments assuming they will after capturing many users).
Then think about hardware companies - it's a very competitive space, it's mostly a commodity, the high-level software doesn't care so much about the specific chips providing those cores of cpu and gigs of ram, and what's available on the market is really amazingly powerful at a really amazingly reasonable price, due to competition with other providers in the market, and with older hardware!
It does seem kinda perverse, but ... the closer you are working to the hardware, the cheaper the market for your work, but the further up the stack, the more potential for high pay, based on the higher monetary efficiency of those companies, by running very in-efficiently on super-competitive hardware, and differentiating with features and services etc.
Yep, I'm in the same boat. C++ jobs always pay like shit, so I sling web apis together with C# and make 3x as much. It's way easier and less stressful. I'll only use C++ for hobby projects now, and then only if it's the right tool for that job.
Welcome to the club, here is another issue with C++ jobs, they are hardly open to the idea of remote work, unless writing C++ is a detail, e.g. main application is C# and there are some native libs there.
Pretty funny. For a hardware/robotics company, software is a cost center. For software company, hardware is a cost center. In-group are profit and out-group are cost.
Embedded roles pay less than almost any other role... I feel there should be some sort of diagram possible that explains which industries and technologies pay more or less.
> I feel there should be some sort of diagram possible that explains which industries and technologies pay more or less.
Is the entity you are selling your services to earning a large profit margin? If yes, then it is possible (but not guaranteed) for you to earn more. If not, then look elsewhere.
Generally, this situation happens in businesses that can scale with little to no marginal costs (software, media), can use governments to defend its property (intellectual property, land), and can be easily used as collateral (land) with which you can obtain leverage (money).
Not just embedded, robotics or automotive have pretty low C++ salaries while much higher for Java or even JavaScript... C++ devs are punished for being more capable.
Automotive is just embedded with some even more painful tool chains, to be fair.
I get paid very well doing embedded firmware dev, but that’s because we don’t make money on our hardware, we make money on the software that it talks to for industrial IoT analytics
Not posting to make a counterpoint but simply because related and interesting for the C++ folks around here.
> Wt is a web GUI library in modern C++. Quickly develop highly interactive web UIs with widgets, without having to write a single line of JavaScript. Wt handles all request handling and page rendering for you, so you can focus on functionality.
Thanks, but just a reminder of why we don't use C++ for web applications: creating a web app is basically a string manipulation problem. The work in most cases is just getting data from a database and returning text that represents the HTML+CSS in the web page. Not only you don't need the C++ speed to do this process, but string manipulation is also the weak spot of C++, due to the need for manual memory management.
1. A lot of the tooling is made by the hardware suppliers. Hardware suppliers tend to be very bad at writing desktop software; I have some theories as to why that is, but no direct evidence for them.
2. When tools are selected, they are rarely evaluated by software developers who will be using them. It's more like "Here's a list of boxes anything our development tools need to check" and then the final selection for anything that checks engoubh boxes is done for business reasons (cost, likely availability of support down the line &c.)
3. The same reason that embedded developers are often paid poor salaries; for a lot of hardware companies, the firmware development is treated more as a cost-center than as something that generates revenue.
Hardware is just slow and ugly. It’s not scalable and really profitable. Write C and C++ code all day for embedded devices and decided, that slowly I want to do something different and more profitable.
Not really if you know where to look and work on platforms. Pay is at par with backend devs if not full stack ones.
ML/AI is the where the money is though.
Same in video games. Many C++ engineers are learning JS in spare time to hopefully jump over to something that pays 4-5x.
My personal experience also says that you spend much less time to build something profitable in JS and PHP than in C or C++.
I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up. Hopefully as a result of moving to languages like Rust - it would work out best for all developers. But it's not looking good in the C++ land salary-wise now.
> I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up.
Maybe. I've made the jump from pure embedded (spent over 15 years in embedded) to backend (Go, with some rudimentary Java thrown into the mix). I literally doubled my salary in the space of 12 months.
In 20 years, are they going to hire my retired old ass to make their codebase live another 5 years longer, or will they simply bite the bullet and rewrite?
> Hopefully as a result of moving to languages like Rust - it would work out best for all developers.
It could happen, but I'm not that bullish on that happening:
1. No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety[1] - the end result of using Rust on a 2kb RAM/8MHz chip (atmega328, or xmega, or one of the stm32s, for example) is going to be using unsafe everywhere anyway.
2. High rampup - the majority of knowledge needed for low-level comes from EE, not CS. Already Rust has problems with adoption amongst CS people, who (in theory anyway) have all the requisite knowledge and motivation to climb the learning curve. I'd bet money that EEs won't even bother looking beyond the awful syntax.
3. Better alternatives - all those higher-level embedded projects such as RPi, Beaglebone, etc that run Linux have better alternatives for programming them than Rust. Most custom code written for the RPi is in Python, for example. Someone looking to develop on these boards is almost certainly better off using Go instead of Python, and Python instead of Rust.
So given that there's a) no benefit on low-powered devices, b) there's better alternatives on high-powered devices and c) it's a complicated language with slow ramp-up, I'm having trouble in seeing exactly where it fits in for embedded.
> But it's not looking good in the C++ land salary-wise now.
Nope, it isn't. If enough C++ devs jump ship (and, to be honest, in low-level embedded C++ as you know it isn't used much anyway), then salaries will rise again.
The problem is, as someone else pointed out, that many of the places using C++ are shooting themselves in the foot, because they want senior and experienced people who can ramp up quickly on the latest C++ standard, but without a pipeline of unskilled/juniors, there's only a few number of years before there'd be out of any C++ devs.
And because it's not an attractive language, there's no one switching from (for example) Java to C++, or C# to C++, while there are plenty switching from C++ to Java or C#.
[1] Beyond which, it is not clear if safe Rust will ever be able to interact with various embedded OSes for these chips; most of them are external kernels anyway, so there is no way to use those kernels without using C.
The only place I can see Rust (or Nim, in our case, mainly so we can easily wire in existing C libraries and vendor provided drivers) in embedded land are the “in betweeners” or “crossover” chips — ESP32-S3, some of the i.MX SOCs, that sort of thing.
Where they have enough grunt to do a lot of tasks at the same time, all driven by config over the network, with less hard real-time requirements for some tasks and stronger requirements for others.
That’s not that big a segment though, I would think. And in some ways, just chucking extra slower chips at the problem on the same board is simpler.
> No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety
The Rust embedded ecosystem has lots of benefits in addition to pure memory safety, which is basically table stakes for a modern language. It gives you a vastly improved DevX, at least if you aren't using hardware that's too exotic for which only proprietary C/C++ toolchains are available.
It's a demand side issue. Most C++ jobs are maintenance jobs. Most maintenance jobs are at low-growth companies who can't justify the TC of engineers at high-growth companies to their board.
There are pockets of the C++ ecosystem where this isn't true (e.g. HFT).
But bottom-line, it's a business thing, not a skills thing. There are also a lot more C++ devs than the zeitgeist would suggest. Far too many to cause a "COBOL effect" where supply constraints on talent dictate market price.
If I am a C++ developer, in my late 50s, close to retirement, and know C++ fairly well, don't want to learn a brand new system which I won't be coding in for much longer, and already have my financials all set...
I won't be looking for that early retirement big cash payouts. I just want my flow of cash for a good retirement, to go on my vacations, and to buy gifts for the kids / grandkids.
I'd be willing to settle for a lower pay with low stress and solid job security.
Remember the desires of people later in life and those early in life aren't the same. If you got 10 more years of work left, you don't want to be in a high stakes high intensity work environment. I worked with one such man. He'd fall asleep while coding mid day. Nobody bothered him. He just chipped away at his projects at his own pace and was happy to not be bothered.
Sounds like such a company is looking for a boomer/genx who's still got skills and willing to settle for not being bothered too much.
Related to age factors: so long as the "primary" development language for videogames remains C++ there's always going to be a multi-generational talent pool for C++. Young naive programmers get into videogames until they burn out or are laid off due to ageism then there's "always" "fresh" new C++ talent for other industries too immediately following those videogame roles (assuming the burnout isn't total, such as strokes).
COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
> Related to age factors: so long as the "primary" development language for videogames remains C++ there's always going to be a multi-generational talent pool for C++. Young naive programmers get into videogames until they burn out or are laid off due to ageism then there's "always" "fresh" new C++ talent for other industries too immediately following those videogame roles (assuming the burnout isn't total, such as strokes).
> COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
Not anymore.
I am frequenting gamedev forums, and reading gamedev chatter in general (seeing youtube videos on game conferences, presentations on games development, etc).
Maybe 1 in 10 of the people in these gamedev places actually program in C++. Mostly they'll use Unity (C#) or Unreal Engine Blueprints, with some Godot getting popular and a few statistical-noise engines being used (Love2d, etc).
What you are saying used to be true; on gamedev forums almost everyone used to be able to program in C++. Now very few do.
Yes, C# is definitely getting a leg up these days (nearly a decade later than Microsoft's and Mono/Xamarin's separate big attempts to make it happen), but it is still seen as more of a "scripting language" than source or engine language. Unity itself is still built in C/C++. Godot is written in C/C++ and its default scripting language is the odd GDScript with some unique C/C++-isms and it takes extra effort to use C# with Godot (though a lot of post-Unity devs seem to be growing happy with C# in Godot these days). Unity is semi-closed/proprietary source so doesn't get a lot of indie dev contributions, but Godot is open source and I have heard of indie devs needing to contribute C/C++ upstream.
(As an aside: I've got my eyes on FNA which just hit some milestones with using .NET 7 AOT for pure C# games on the major consoles. That's pretty exciting.)
Unreal is the truly wild one because to my understanding Unreal Engine Blueprints are a terrible half-baked not-quite-scripting language and most Unreal developers have to do most of their "proper" scripting in C/C++ directly. (With some statistical anomalies allegedly doing things like bolting in Lua interpreters.)
But yeah, outside of indies and small game companies my impression is that C/C++ is still king and there's some consternation that developers learning from the indie side are sometimes, if interviewing for AAA teams, getting shuttled to "tools" positions because that's where AAA's only C# code lives (in non-critical tools outside of the games). (Though that's mostly anecdata from reading similar gamedev forums.)
My question is what engines are the AAA companies hiring people to work with?
Yes, Unity is the default engine in the indie scene, but what are EA, Ubisoft, Embracer, Take Two, etc. hiring people to work with? Because these are the meat grinders who hire fresh college grads by the hundreds and work them like oxen until they burn out.
Good point. I've been looking almost exclusively at small teams.
I wonder how many programmers are used at the AAA publishers. Maybe someone on HN who works as a gamedev (ISTR one or two people in the past saying that they worked for AAA developers) can answer that one.
If you were to look into trading companies, mostly located in Chicago/NY, you would find positions paying competitively (or better) with FAANG salaries.
Not really. I've spent more time debugging JavaScript than debugging C++.
It used to be hard. Modern C++ is actually a quite pleasant language.
The issue is libraries. For example, one very basic functionality of any programming language is DB connection.
In particular, MySQL is very widely used. The C++ libraries (c++ connector) are older, less maintained and just plain broken in the last Ubuntu (it's Oracle's fault, and that can't be helped). They are more stable in Python, for example. The reason is trying to force SSL, reading the source code of the C++ connector it's clear it was intentional.
So, for many things that should have a well maintained library, there's actually not a good C++ one. Web servers are another example. There are only one or two libraries, very opinionated and with "proprietary" widgets, and that's it. Nothing comparable to Laravel or FastAPI.
In other words: the language is fine. C++ is a fine language with a fast runtime, and modern practices and implementations are pleasant to use. It's the disregarded ecosystem in C++ the one that needs improvements. Libraries, package management, build systems, etc. Even then, for performance, some things are only available in C++.
C++ isn't necessary in many business contexts, and can result a worse business overall outcome than alternatives. If it's a harder tool for people to use, and the use of the hard tool isn't necessary, why would you use it? Why not use an easy tool? Especially if the easy tool means more people can wield it, so there's a wider labor pool to draw from, or a reduced error rate from tool-difficulty-induced defects.
Indeed, many businesses correctly decide there's no benefit to using a difficult tool that isn't required, and choose an easier tool that produces a better business outcome.
e.g. suppose you're a non-tech enterprise (bank, utility, etc) and you need to build a bunch of backend web services to support your internal operations. If you decide to implement them in Go, which is arguably a domain specific language for building web services, then you can probably deliver the project by hiring a bunch of fresh grads and putting one intermediate to senior programmer in place to lead the effort, even if no one has any Go experience.
arguably if you try to deliver the same business outcome in a random enterprise context using C++, a project team will likely have a far more difficult time getting basic HTTP / TLS server stuff in place, and if there's lots of rookies on the team, they'll keep making foot-gun memory error mistakes.
Sure, maybe if it was built in C++ by highly senior engineers, and subjected to a thorough QA process, you could end up with a system that's much more efficient at runtime than what could be cobbled together by less experienced engineers with an easier language and a good standard library. But in most business settings efficiency isn't the bottleneck, it's delivery speed and then maintenance costs, which are driven by staffing and how expensive it is to change the code each time the requirements change.
> Writing new C++ code with all the modern approaches and tooling doesn't sound so bad.
Uh, but it still kinda sucks, if only because the nice way that looks idiomatic is usually the incorrect way for either performance (anything newly added like std::variant or std::optional) or safety (operator[]).
The correct way is usual the ugly way, because it seems like the committee puts C++ arcanum knowledge above all else, instead of developer satisfaction or maintainability
> the incorrect way for either performance (anything newly added like std::variant or std::optional) or safety
I don't know where you got that idea from, but with an up-to-date compiler variants are safer and more performant than the traditional approach (classes hierarchies), and std::optional is safer and 99.9% as performant as a nullable pointer.
> and std::optional is safer and 99.9% as performant as a nullable pointer.
Except for it taking up twice the memory as a pointer (https://godbolt.org/z/5We9zEbvh) and it not doing anything in regards to safety when using pointers. Even if you're replacing a nullable-pointer with a std::optional you're still handling landmines when using operator* or operator-> - the most convenient ways to use std::optional.
The fact that modern C++ still added more easy to hit UB in std::optional blows my mind. "But making it safe would be slow!" and "-> being safe would be inconsistent with the rest of the language".
C++ is doomed forever to have safety-third design.
C++ puts you don't pay for [at runtime!] what you don't use above all use. However that often means you have to know the arcanum bits to decide if need to pay for something. You can save a bit of CPU time if you don't check if a pointer is null - which is a great thing to do if you have knowledge that the pointer cannot be null - and also something that is very easy to screw up so most languages don't give you the option. (which is the right thing for them to do - a lot of people are writing C++ where they could write something else)
Speaking as a professional C++ developer for the past 20 years, I think this sums it up well.
A modern project should be able to use most of C++17 at least. Even if you still need to target some ancient garbage like Windows XP, you can use an MSVC toolchain that supports C++17. That's a good basis to work from.
So your real concern is the moldy old code that's written for C++03, that's still not using std::unique_ptr or anything equivalent. If you're given license to finally rewrite that code to modern standards, that can be fun if it's not a complete mess. But if you just have to live with it, and still write C++03, absolutely not, I would never do that job.
do you have a good template (pun intended) on how to best learn modern c++? coming from Go and Typescript which have very mature devX tooling, c++ is a landmine to navigate. and that's when I already have professional experience with it (the place just didn't have strong c++ culture)
Try watching the "back to basics" videos from the last 4 years' cppcons.
But that's mostly learning modern paradigms of the language.
If you also mean the tooling, then it depends: Learn CMake which is sort of an industry standard. There are books and videos, but for a concrete experience, try looking through the CMakeLists.txt of some non-trivial C++ open source project.
I have license to any one C++03 area to C++14 (and I have my own implementation of optional that I'm allowed to use when until C++17 is available). However I can only do a few of them so I need to target where. If C++03 code has been working great for years and isn't broke, why would I break it?
> If you're given license to finally rewrite that [C++03] code to modern standards
Then you aren't choosing C++20-something, you're choosing a new language altogether.
This is why the demand for C++ devs is dropping - if you're going to bite the bullet and rewrite, why not choose a better language, preferably with GC?
> It's not like C++20 is completely different. There's just a lot more utilities in the stdlib so hopefully less raw pointer magic.
What was best practice for C++03 is not the same for C++20.
Switching a codebase from C++03 to C++20 for a nontrivial codebase means changing design so radically it may as well be a new project, rewritten from scratch.
It'd certainly be easier to rewrite in C++20 for the C++03 projects I've recently worked on, than to try to squash in a C++20 design.
- Immature compiler susceptible to generating performance traps
- Build times even longer than the infamous ones in C++
- Simplistic declarative-based build system
- Inability to opt-in or to opt-out from static analysis
- Harder to scratch up quick PoCs because borrow-checker
- More complicated compilation model making it harder to understand, debug and implement workarounds when codegen goes south
- Much smaller ecosystem - libraries, toolchains, tools, ...
- False sense of security - by default it relies on the ecosystem whose runtime and its OS is implemented in "unsafe" languages
- Cannot even live to its "safety" promise because hardest problems cannot be solved without unsafe sections
I sincerely wish it was different but at this moment I am not convinced that Rust trade-offs are worth switching to it. This is the PoV coming from a system-level programming, very close to the OS, and with a lot of difficult memory and concurrency scaling issues.
My first real C++ job involved a bug in a largely technical indebted codebase, lines of code in the millions.
I spent two months asking one guy who knew about it for help. I really understood the concept of "hostage taker" in a software team. It's the guy you cannot fire and will constantly arm-wrestle everybody where there is a problem, never really helping, and continuing to write bad code that allows him to keep his job.
Just spent two years writing a medium size fresh c++ codebase in modern style with all the warnings turned to max and nearly every static analysis tool we could throw at it from day 1. It’s been an utter pleasure with no pain that can be blamed on c++ alone. It can be done :)
I personally consider C or C++ written with the best-of-breed static analysis deployed on it, preferably from day one, to essentially be a different language. Most of the criticisms of C or C++ are eliminated under this setup. You get different ones; the resulting language is even more complex than the base languages, and requires an even deeper understanding of what's going on, but at least you have the requisite support to learn it, so in the end it's probably a net positive even in terms of the ability to learn it.
This is, obviously, a very opinionated opinion.
If I was going to be forced to do it, this is how I'd want to do it.
Most of the stereotypical pain of C++ lives in legacy codebases where they're passing raw pointers all over the place, doing horrible things with array indexes, and poorly re-implementing the standard library containers. If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure!
> If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure!
I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful".
If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap.
And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
Have a gut feeling that polyglots can’t handle C++ so well because their strategies for using several languages fail: one has to know C++ well in order to be able to use it successfully.
I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero.
Polyglots truly are jacks of all trades and masters of none.
I think that's great if you're writing from scratch, but I think it misses the point that the previous poster was making.
Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C.
I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
Yeah I did a few years in finance on a c++98 code base for my sins. (My colleagues were great, but the code was not optimal to say the least. Then again I really loved making it better and faster.) My intention above was just to say experiences with c++ vary with circumstances and if you are lucky legacy isn’t part of your day to day :)
I only have a small codebase, but I mirror the sentiment.
If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain.
C++ gets underserved hate by people who don't care about doing a good job anyway.
for stuff like gaming & HFT, you are probably forced to do it in C++, it is a sad reality affecting small % of developers. for everything else, if you are still building fresh new projects in C++, you are making a big mistake.
C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ -
Simply put cpp gives you ultimate control. If you want to be absolutely economical with the CPU/memory, you need to do things likely preallocate memory and making sure you don't get cache misses and branch mispredicts.
For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
I think it gets close. Certainly close enough that if you're a small team doing similar things, use Rust. If you have time to fiddle with the little things, go with cpp.
I do precise timing with accuracy up to +/- 1ns and some of my hardware are of 10-100pt resolution.
I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink.
I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
cross-platform is no longer a bonus of a language or a toolchain. it is a must to have feature in any modern language.
to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables.
there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already.
fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
> You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
you also need to worry about which stdlib to use in C++ - too bad!
> SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
please stop such nonsense. AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
> the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process
why this is even related to the ongoing C++ discussion? once you have the package, you need to somehow distribute it, app store, http service, bittorrent you name it. but why it is even relate to any programming language since you brought it up here?
you can probably argue that golang's stw isn't going to help when building audio stuff, but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way by rust. audio plugin or not, I don't care, in the end it is just the same machine code.
> AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
Well that's nice. What about ARM SIMD? And the M2 variant? You're suggesting that every SIMD instruction set should be accessible via the same language-invariant syntax or else a language is just broken?
> but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way
the point is that it is NOT done by a legacy language known as C++, and it should not be done by the young languages that go by any other name, contrary to your claim that essentially everything should be a part of the language/compiler/toolchain itself.
"Legacy" is meaningless in the contect you've used it.
C++ has wide use, and will continue to have huge use, for both old, current, and new codebases, in tons of areas, from systems, finance, and OS, to scientific and games.
Same can be said for BASIC, my favourite childhood language.
you know people collect old cars, computers, stamps as hobby, tens of millions of people are into that. for the exact same reason, there will be people who are just into writing software using legacy tools. I totally understand & respect such decisions.
C++ is the only language I know where you can think you’ve learned it, then stumble upon a completely alien codebase. The decades-long history of the language has spawned all kinds of dialects and template-powered Lovecraftian horrors.
As someone who is a fan of Common Lisp, this state of the world kind of grinds my gears. "Lisp isn't suitable for large teams because it's too customizable" while it takes me an order of magnitude more time and effort to come up to speed on a new C++ code-base (day job) compared to doing the same on a new CL code-base (hobby).
Some of it is tooling: It's trivial to walk through expansions of Lisp macros, while the tooling for C++ is ... less ergonomic to say the least.
Some of it is a weird combination of technical/cultural. You can do a lot more in Lisp without reaching for macros as compared to C++ and templates. In addition, every CL style guide ever says "don't use a macro when a function will do." There's also the culture of "Read *Let over Lambda" (a book on Lisp macrology), now don't ever do any of that unless you absolutely have to"
Scala is worse, people tend to invent their own DSLs in it and you end up with two libraries unable to work with each other without wrappers, like in the old days of C++...
My dream is to have an AI that automatically unwraps and de-clever's a codebase to something super simple. Completely unrealistic, but even a semi-manual tool I can use on complex chunks would be amazing.
I've been writing high-performance C++ since the late '80s, and C a few years before that. I've got three choices; I can earn crap-tastic barely breaking six figures TC writing C++ for a run-of-the-mill application with reasonable work/life balance, or I can write C++ for a fintech earning $400k TC where I'm regularly pulling 70+ hour weeks and abused. Or I can get both bad pay and bad WLB making video games. Alternatively I can go earn $300k TC writing Python with occasional dips into C++ for extra juice with good WLB and my weekends off. Let me think about that.
There's also big, legacy C++ code bases with their own idiomatic way of doing things and every faddish poor practice you can imagine from the past 40 years that'll make you curl up in a ball and cry when you face them.
That's my recipe now, after decades with C++ continuously looking to dump it, the moment I find something better. Dipping into C++ is mostly a backup plan: Numba, Numpy, various GPU targeting tools make it rarely necessary.
These are financial firms griping about the lack of developers. They're some of the highest paid developers in the world. But working for these companies is also insanely stressful. Long hours, high pressure.
This speaks to the point in the article "The real problem is that C++ is neither easy nor loved," which they offset with "The language may be hard. But it's also worth it."
The problem is that there's a law of diminishing returns to compensation. If you can work with a tool you like that helps you meet milestones and general expectations for $X00k generally leading to pleasant days, or can work with a tool that makes your life harder and leads to higher stress fewer pleasant days for $2X00k... sure there's going to be people who take the extra money. But there's also going to be people who say to themselves "yeah, it turns out I'm plenty well compensated at $X00k I'll take the extra quality of life."
"Worth it" is a value judgment. How many people managing the financial firms decided it was worth it to invest in C++?
They're focused on the language. The language isn't the problem. Of the people I've met in finance, there are some really strong and offputting trends: they're uniformly dismissive of work/life balance, they're almost uniformly the worst stereotype of tech-bro, and aside from the rampant cocaine use, they're hugely socially conservative, and every single one values profit over ethics.
It's not the language, it's the extremely toxic culture. Any programmer worth their salt can march into a nasty codebase of whatever language, and make it dance. But financial folk don't want to employ humans with all their complexity, they want robots who will run themselves into the ground for cash. So they get young men who burn out quickly and retire ASAP. The problem isn't the language. The problem isn't the pay. The problem is the extractive culture. Finance folks focus on short term profits to the detriment of their future. And now they're wondering "where can we find programmers" after they've been burning them like so many trees. Go figure.
> Any programmer worth their salt can march into a nasty codebase of whatever language,
Correct, I wonder why people both technical and non-technical focus on this aspect a lot. ( my guess is that they are incompetent themselves).
Agreed, if you want someone for two or three months you probably want someone who knows the language and it's ecosystem pretty well. Any work that is more than six months should be nearly language independent.
> Any work that is more than six months should be nearly language independent.
I'm not sure this is true in finance. Speed matters. A lot. It's called high frequency trading for a reason. These firms will spend a million bucks just to make their fiber optic cables 1 foot shorter.
Just the kind of short-sighted idiocy that keeps good people out of the industry. How long does it take to get that network upgrade installed? It doesn't happen overnight. It takes me a week to get decent at a new language, a month to get good. That's, what, $10-20k on "training" assuming an output of zero in that first month? That's peanuts.
It really makes me wonder. I see so many job ads where specific-language mastery is a top-line requirement. And I know people who know that this is not justified, but keep doing it...
To further the idea, C++ can be loved if the firms invest dollars, invest marketing (open source, other ways) of it. They should support/invest in the community they want to hire from.
just a side note: long before a small part of the programming world took over this acronym, it used to mean the sound engineer (and sometimes other staff) that were in the venue, embedded in the crowd, working on live sound while the talent was up on stage. "back of house" was behind the stage, "front of house" was the room/venue itself, and the people working in it.
I’m not sure the programming world took over the acronym, I think OP just confused them. In finance at least, the terms Front Office and Back Office are used. I’ve never heard anyone use the restaurant/entertainment variants used.
I wonder (with no supporting data) if they are griping because in C++ they've created horrid technical debt that they have a hard time hiring people to maintain.
Last time I looked at the finance industry, which was admittedly a while ago, I saw a C++ job that listed the salary as being around $100k. Sounds reasonable.
In New York City. Oh.
Compare to Google salaries, on levels.fyi for example. I know they're not theoretical or inaccurate because I worked at Google for a while. If you really want to do C++ professionally, that and maybe other FAANG companies seem like they'd give you much higher quality of life.
But the truth is, if you're a C++ developer, you may as well just take up another programming language and get paid more. The data doesn't lie:
C++ was basically the first programming language I really learned, but I seldom use it in the industry, because I don't know why I would intentionally pick a pay cut to do harder work. (I consider C++ to be "harder" than many of the languages above it in pay grade even when doing the same work, for most tasks.)
Salary at an HFT doesnt tell an accurate story. I'd be shocked to learn any quality c++ dev at an HFT pulled down less than 500k last year, and I'd expect most to be well above that.
Hiring C++ isnt especially hard because our pay is opaque. Recruiters will tell you immediately what total comp you can expect and they'll let you know what you can contractually guarantee year 1.
Hiring for C++ is hard because C++ is hard and most people are quite bad at writing even somewhat reasonable code.
I was told $300K about a decade ago and I told them no. I was already making more than that at a big tech company with a much easier pace of work. $500K would have peaked my interest, why didn’t they tell me $500K if that was an option?
A quick google search is suggesting that $200K for the top end of experience, when I was told $300K they said it was as high as they go. Where is the rest of this compensation coming from? Maybe they could give stats for bonuses but when enquired it seemed that the bonus pool was being eaten up elsewhere and the C++ devs were in the back of the line for that.
200k for the salary part might be the highest salary they offer.
Often bonuses can be >100% of the salary. Bonuses vary based on firm performance. The advice is typically "Live within your salary, don't let your lifestyle creep up to demand your full total compensation". HR typically emphasizes that the bonus is not guaranteed (unless you negotiate a guaranteed bonus for some number of years [1-2] after hiring).
Also, salaries/TC have gone up in the last 10 years.
To get the aforementioned $500K it would need to be an average of 150% bonus. And that’s just to equal the FANG equivalent plus some extra for the added intensity. The firm should be able to give historical averages. And I was given the distinct impression that the developers were last in line for the bonus pool, which may have changed in the intervening 10 years, but they should advertise that.
This. I think these firms would have an easier time hiring engineers away from FAANGs, if they realised that FAANG engineers don't precisely understand how the bonus system works. (I think the vagueness is actually seen as a feature of the bonus system!)
They were quite explicit that management, traders and quants take the initial passes at the bonus pool and not to expect much out of it. 100% seemed to be the max not the minimum. They made it clear that C++ devs are support staff and hence second class citizens. And as a second class citizen in a support role it would be hard to make the case for a personal performance bonus.
I think any experienced c++ dev knows there is good money in HFT. Hiring for HFT is also hard, I imagine, because the industry is parasitical. Id like to look at my work and feel that it is contributing something net positive to society.
Same with the poker machines. Recruiters gotta recruit, but I’d just make my own meth if all I cared about was the money.
HFT can cover a wide range of diff types of firms/latencies. Bonus structure also makes it so the salary might not be as high, and bonuses can be contingent on performance. This might be true at some of the larger firms on successful desks, but I don't think it is true across the board.
I don't think I know of many buy side firms that pay any less than Google, Microsoft or Meta. Salary just tends to be relatively small compared to the bonus or return on invested capital in the fund.
That's probably why finance is having problems. I know plenty of great C++ devs out here in flyover country. A lot of shops that hire them go bust, or outsource, and they move on to something else because finance is clueless about how to scoop them up (pay a lot, do remote, or establish a branch office).
Google has basically thrown the towel in the ring when it comes to C++ considering they're building a replacement like Carbon and also using rust in and more places so they're likely pivoting to those two instead
I mean no, if you're happy at Google doing C++ then by all means you can probably keep doing it for a while. I don't think pivoting is particularly hard for experienced devs, so it's probably fine to hold it off, though I could be wrong.
The glue code is C++ still. It's also a much less glamorous job than when the C++ programmers were the "hot shit" instead of the people who specialized in accelerators.
So they are complaining that they can't find people who want to be second class citizens while still dealing with the pressure and hours using language skills they acknowledge are in high demand...
Yeah, kinda, CUDA is c++ that I can't run cppcheck or clang tidy on, and the important bits are either calls into the cu* libraries which are c style, or kernels, which are really their own thing.
Yes, kernel code is GPU style rather than CPU style.
But the CPU-drivers of CUDA are all C++. Albeit a C-like API (cudaMalloc, lol), but its a clang compiler for the CPU code nonetheless. If you have complex GPU + CPU interactions, you'll need to be a C++ expert.
Even if you aren't doing GPU work and sticking "only" with CPU-side CUDA, its all C++.
HFT, prop trading, market makers and the like are also finance firms right? They are still pretty coveted by those who are aware of their existence. Jump Trading, Citadel, Jane Street, DE Shaw etc are considered highly prestigious and competitive.
There are certainly financial firms that people are less interested in though, namely banks.
Lol, couldn't be further from the truth. Ive gotten multiple offers at FAANG and Trading firms (thinkCitadel Jump, Optiver, HRT, IMC, etc.). Trading comp blew my FAANG offers out of the water. And if you went to MIT, CMU, or Berkeley right now I would guarantee you the top students are gunning for an internship at one of those firms.
Perhaps "prestige" may be lower from an external perspective (Your parents will brag about you being at Google, but probably not Jane Street), and Id also agree with the fact that the top 0.01% probably either make their own startup or join as a founding engineer at a startup, but the top 0.1% of students are definitely going for Prop trading/hedge fund jobs.
I'd say HFT/prop trading/market making/hedge funds, since those are the only places that are hiring right now and pay good money.
The usual destinations for smart and motivated new grads are (not counting very early startups/making your own company):
1. Top tier HFT/prop firm (Jane Street, HRT, Jump, etc.)
2. Meta, larger unicorns like Stripe, Databricks, etc.
3. Google
4. Amazon, Microsoft, etc.
Obviously im leaving out a lot of places but this is generally what I've seen.
Id say for most people FAANG is still the top option, and for people that want to shoot beyond FAANG, trading firms are probably the next target.
If you were including very early startups in this list, I've noticed that the smartest people often join promising startups as an early engineer, or make their own company. I'd put them above trading firms, but the risk is way higher.
The best thing they could do to attract talent would be to offer a choice of 3, 4 or 5 days for 60%, 80% or 100% salary. Many people would probably choose 3 days at a high paying finance job over 5 days somewhere else and 60% of the money they tend to offer at those companies would still be really good money.
The key to being a developer in finance is to work in a software shop.
Working at a bank / prop firm is going to be extremely stressful. Working at the shop that all the big banks buy their trading software from is like 80-90% of the pay but none of the stress.
I love it. I get to do real, hard engineering for big pay without working on ad tech or javascript.
C++ quant jobs were already some of the highest-paying jobs in the technology market. A step above FAANG in many cases.
There's more to the story than just comp. Even increasing comp wouldn't immediately generate new developers, as it takes a very long time for the increased comp to incentivize new students and junior engineers to move in that direction in their career.
High performance C++ takes a lot of time and effort to learn, and even longer to master. Maybe the real issue is that there has been a surplus of high-paying jobs that are much easier and require a lot less effort to master.
"Already" doesn't mean it couldn't be raised further. Have you seen C-suite salaries?
Also you don't have to only incentivize grads. Getting experienced devs to jump ship is the primary goal. Which a $100k+ raise would certainly incentivize.
The company they based the story on appears to be a cryptocurrency firm, too. That'll exclude a lot of otherwise qualified candidates due to ethical or business model concerns — especially since C++ developers tend to be older, they're more likely to understand the risks of jumping into a bubble and have higher expectations for things like work/life balance.
You can't pay me enough to go back to writing c++ code.
I despise the language, 80% of my time is spent figuring out how to beat it into submission to get it to do what I want, which leaves very little brain power left over for designing well architected software.
Modern languages get easy access to a large number of powerful design tools, C++ I have the same tools but it's stuck behind an interface (headers, the build system) originally made in the 70s.
I wish. I've never received an offer that high for C or C++ job. Then again I haven't applied at any trading firms, and I wouldn't be considered Senior.
When I talk to people about careers I see a lot of people with the implicit assumption that because something is technically difficult, it should pay well. Of course, when you say it out loud, it doesn’t sound true any more. The correlation between job difficulty and pay is relatively weak.
I do think that one of the contributing factors here is that it’s hard to be as productive in C++ as you can be in other languages. People talk about how amazing C++ is all the time and how it’s got great performance and you can build great applications, libraries, and services with it… but it still seems like the amount of work and expertise it takes to build an application in C++ is usually larger than the amount of work it takes to build the same application in another language.
The same may be true of embedded programming. The embedded programmers I’ve met seem like a smart bunch, but I know that the fact that embedded programming is hard is a double-edged sword—you need to hire expertise to get it done, but it takes more work and expertise to get anything done.
A job being hard doesn't mean it'll pay well, but a job being quite easy usually means it won't pay well, because it's easy enough to replace whoever's demanding more pay.
Of course, you'll get people here insisting that web dev or whatever pays well and is easy, but try asking actual hiring managers and recruiters how easy it is to find competent experienced devs.
The reality is probably that it is indeed fairly easy for some people who have a knack for the kind of thinking required. But for most people, it's not easy at all, and demand is, of course, very high.
I agree, your comment nails it for me. As an average developer who maybe is above average in C++ I’m just more productive and can produce better results in other languages in a shorter amount of time with less pain.
From my personal experience it seems that companies looking for C++ devs are far too picky. I have a few years professional experience in C for embedded systems and have written personal projects in C++ but have been rejected from every C++ position I applied for. It seems that companies only want someone with 5+ years experience and are unwilling to take less experienced people on.
Putting 5 years of C++ in your last position on your resume will fix it. HR people have no clue about programming and they don't want to risk recommending somebody who is not a perfect fit. So you take that responsability on yourself. The time when qualified people did the hiring is long gone.
I'm guessing it might be because the years of embedded C experience (even if it's decades) don't necessarily show you're able to put aside what you learned and learn what's a wildly different language that happens to have some superficial similarities. In some respects it might be even harder to get someone with too many years in C to start writing C++-style code (or vice-versa!), given how difficult both languages are and how entrenched people are in each one. If you can show off any of your C++ code to any of the engineers interviewing you, I suspect it may go a long way—that is, assuming your C++ code looks like modern C++, and doesn't look like it used to be C code.
Yeah, this. One of C++’s biggest problems has always been the number of people who have spent years writing C and think that qualifies them to write C++.
This attitude is one of the main reasons of the C++ shortage though. You are dismissing anyone else's potential to learn and become a C++ developer. I didn't say that I'm a qualified C++ dev, just that I wanted to start learning to be one and get a foot in the door.
> C'mon. In practice the differences are hugely overblown. The fundamentals are about the same.
> Also doing "modern" Cpp [...] is just annoying.
You're basically saying "I can totally do what you're asking, but I actually think it's super annoying and I'd very much rather do things my own way, so you should hire me because I'm an excellent candidate." Do you expect this to be a good sell?
I am not trying to sell in myself as a Cpp programmer at some corp. If that were the case, I would sing praise to smart pointers and Agile processes, like everyone else.
I am not dogmatically against 'modern' Cpp. It should just be used with self control. And many people way overdo it.
When fresh out of college, I used to pride myself knowing C++. I used to revel in its complexity because it made me feel a cut above the rest. How naive & stupid I was.
I have not worked in C++ for a long time, I cannot climb the mountain of complexity again.
Some years back I was interviewing and some recruiter or HR says to me "so from your resume it looks like you're a C++ expert, right" and I was able to control myself and say something like "I definitely have C++ experience" rather than "listen buddy, does it say 'Stroustrup' or 'Sutter' on top of my resume?"
> People are seemingly scared away from the language by a terrible stigma: the notion that it is a legacy program.
Probably more like, they are turned off by how large and complex the language is, and how it's accumulating features like a giant rolling ball of mud.
The discouraging legacy lies in the code bases.
"You can just write code with new features" is a hollow sentiment, because a lot of work is maintaining legacy code, which might using all the features, from C++98 to C++17 and beyond. Old code that successive generations of workers partially modernized here and there.
There is a constant increase in how much you have to know to be a competent C++ maintainer of a legacy code base, under a modernization mandate, as long as the old parts of the code never completely go away.
Also, in the engineering disciplines we have many people with a personality that wants to know something completely. You don't know C++ if you don't know all the old parts too, and that's a turn off for someone who takes pride in being competent. You'd rather master something smaller and simpler completely, than to partially know something huge and complex.
You also don't know C++ if you don't know the new parts, and that's a turn off for long time C++ programmers who have switched to something that isn't constantly adding new unknowns.
Speaking of which, some of the C++ job ads turn away competent long-time C++ programmers by requiring proficiency in modern C++. The C++ community has harmed itself by creating a negative perception of older C++ and older C++ skills, even though those are needed in C++ work. Newcomers pick up on that and get the impression that C++ is a language that they not only cannot master, but which has parts that are frowned upon. The engineering mindset is repelled by something like that.
The top-most entry in his long-suppressed to-do list?
"Stop trying to monitor everything in the world of C++ :-)"
I.e that retirement from C++ basically was the execution of that top-most to-do entry. Being a C++ expert means constantly monitoring what is spewing from the fire hose.
By contrast, I can be a Lisp expert and improve in that by what could be described as crystalizing. Filling the interstitial spaces.
> Where are all the C++ programmers? People are seemingly scared away from the language by a terrible stigma: the notion that it is a legacy program.
I think this is because the pool of jobs for C++ programmers is so small.
I took a position as a web dev at a company whose main product was a CAD application. Most of my work was in NodeJS, but occasionally, I'd have to dip into the C/C++ layer to make some API changes to facilitate my JS development. When my project was cancelled, I was given the option to move to a team doing all C++ development for the desktop app. I gave it some thought and realized that this was probably the only company within 100 miles who needed C++ developers, and that most of the people I worked with were hired out of college.
I left immediate afterwards. I didn't want to be stuck in my 40s-50s with a unless skillset and have to start back from the beginning. I'm sure other people considering fintech work feel similarly. We live in a world where people keep their jobs for 2-5 years, meaning we live in a world where workers need to consider the needs of the entire job market, not the needs of an individual company.
> I didn't want to be stuck in my 40s-50s with a unless skillset and have to start back from the beginning.
This is absolutely nonsensical. In 20 years no one will remember about NodeJS (or it will not be the mainstream tool for web dev), but the C++ CAD application will definitely still be here, in both use and active development, and it will very likely still be in C++.
Just think about it. The last C++ CAD application I worked in was started in 1987. In 2023 it was still C++, and not only still sellable, but also incredibly profitable. They are practically a monopoly in their target market. A market which is highly likely to continue to exist for the next century or so.
How did NodeJS look like in 1987 ? A single skillset that can carry for 30years+ in computing is _nothing_ to scoff at.
You're conflating runtime and language. I doubt JS or TS will go away anytime soon, seeing as they power the Web. Sure, there will be ways to augment them and the languages evolved since what they used to be, but I don't think they'll "die"
> I doubt JS or TS will go away anytime soon, seeing as they power the Web.
We have a Javascript interpreter orbiting around the L2 Lagrange point.[1] Safe to say that will remain there even if our culture down here on Earth collapses.
As far as cultural artefacts go that one will probably survive all of us.
I am not conflating, just replying to OP. Anyway, even if you do want to talk about web dev in general... how did web dev look in 1987, again?
The mere fact that you are listing languages that are only a decade or so old in your statement should be a rather large hint that web development is a much faster moving target, and highly unlikely to still be recognizable in a couple decades.
Some technologies, even if they are popular today, die a death of slow attrition. There may be demand, but it's niche (like COBOL today).
C (and C++) will remain popular for a longer time for a number of reasons; after all, under the hood NodeJS is a C program right? Because it's the most useful portable macro assembler anybody has invented, and it forms the basis of nearly every higher-level system.
In the context of this discussion Perl is an exception that proves the rule.
There are no Perl jobs because Perl was supplanted by Python and Ruby and embarked on a disastrous Perl 6 journey.
This will not happen to node.
JavaScript is and will continue to be for the next 10 years the most popular programming language ("popular" == "most jobs") because it has monopoly in the browser.
As a result JavaScript will continue to be used in other domains (backend, desktop, mobile) due to sheer number of JavaScript programmers. Quantity is a quality of its own.
So node (and deno and bun) will continue to be used and there will be plenty of jobs for JavaScript programmers ("node" programmer is 90% JavaScript programmer and 10% "node specific APIs" programmer).
Of all programming languages that you worry might disappear in the future, JavaScript is at the end of the list.
To be clear, my thought process was something like this:
I have useful skills that I can use to leverage into another job right now. In a year, those skills will be slightly irrelevant, in two years, those skills will be very irrelevant, etc. Basically, the longer I stayed there, the less likely I was to be able to get another job based on my current skillset.
Three jobs later, I don't do NodeJS development anymore. I leveraged my skillset to get a GCP consulting gig and now I work for a startup where I use my expertise to get new products off the ground.
If I decided to leave tomorrow, I have 1000x more job opportunities as a GCP consultant than I would as a C++ developer. My goal is to keep learning the tools that will give me the best job opportunities.
Some people want to be experts in a niche area. But I want to have the most job opportunities available to me. One is not better than the other, but I think more people share my outlook. A new developer today could make an entire career out of doing PHP development for the next 30 years, but would that be an advisable choice of action?
C++ is here for longer than your career will last. Outside of HN/Web bubbles it's still used everywhere. Chances are you're writing this message on a C/C++ OS running a C/C++ browser engine. NodeJS and v8 are C++ applications.
I went to a lecture by Stroustrup once who was asked what he thought of Java and jokingly said he didn't like to be negative about C++ applications. While this is a joke and Java isn't actually written in C++ (anymore?), it's good to remember the majority of the stack under yours is probably in it.
> Chances are you're writing this message on a C/C++ OS running a C/C++ browser engine. NodeJS and v8 are C++ applications.
That's because there was hardly any mainstream alternatives (sans C, I guess) within its domains (ie systems programming and related field) until recently. That's not to say people haven't wished for alternatives. God knows I have
I've only worked in tech for a decade but I remember seeing this back then, and can find articles two decades ago about the same thing. There's just so much code in C++ that can't be re-written or can be re-written but will take hundreds of developer years. For example Rust doesn't even have a spec. I don't think I could use Rust for regulated healthcare/defense fields? There's not really that much support in hardware for Rust in robotics. If something works in banking why risk moving to Rust? Etc... I think Rust has a place but right now I'd wager a C++ code base is worked on way after the last Rust code base has been created.
Right, you're absolutely correct that C++ is currently the defacto standard (or maybe not even just defacto) in those fields.
I have a lot of opinions on the situation. Some are on technical merits, some boil down to humans doing human things.
It's difficult for me to give C++ much credit on that front due to the fact it's had such an incredibly long head start and tremendous amount of effort put into it. Similar efforts exist for Rust now, but they're only starting.
Maybe something better than Rust comes along eventually too. I'm not married to Rust. That doesn't mean I'll want Rust to fail or disappear. It just means there will be more choices.
I'm just not going to let my tools hold me back. Same goes for the C++ and Rust situation currently.
Also, it's possible that it's just a quirk of preference. Some people prefer mangoes to pineapple, some are the opposite.
There have been a million things hyped as alternatives, and even though it is very easy to argue retrospectively that they were not really alternatives, they definitely were hyped as much or even more than e.g. Rust is hyped these days.
think Java and Go. I have already _lived_ an era where I thought C++ would eventually be replaced with Java and I would have to learn Java (this was so long ago). The effect was so pervasive that e.g. universities started teaching Java instead of C as their introductory language. Why would anyone want to manage memory manually, ever again? Benchmarks were showing Java as beating C++ in some algorithms, and theoretical papers appeared about how some kind of programs are much easier to optimize for JIT VMs than classical compilers. Everyone thought it was just a matter of time until classical compiled languages were irrelevant. Even in the embedded space (and Java made significant inroads). The effect was so big I was actually convinced to start up learning Java ... only for C++ to eventually prevail over Java.
The last time this happened was with Go. Every single week there would be an article here in HN about Go this and Go that, or how Google is rewritting their C/C++ codebases into Go. Turns out, they did not. You then start to hear retroactive justifications about how Go was actually a "services" language instead of a C replacement (despite the fact it was literally sold as a C replacement made by the creators of C itself no less).
Nowadays we get articles about Google rewriting their codebases into Rust.
What? Java dominates C++ in number of professional programmers. It totally ate C++'s lunch. Meanwhile, universities teach Java, C, Python, and a bit of Scheme if they're feeling spicy.
Look, I'm not saying C++ will go away. I agree with you the whole "X will be the Y killer" arguments are nonsense.
I used to like C++, and just don't care about it any more. It can stay, and I'm sure it makes people happy to use it if that's all they know. It's just that it mostly made me miserable—even though I reached for it for years.
Right now people have more choices, some of which you mentioned. Is Go a better choice than C++ for some projects? Absolutely! Can it be worse? Absolutely! Theses things depend on so many things.
Same goes for Java, and Rust, and TypeScript, Haskell.
The whole "C++ can do everything those languages can do" is just a nonsensical argument. C can do everything C++ can, so what? I can come up with more ludicrous examples of that statement too.
Tl;Dr if C++ tickles someone the right way: I'm happy for them to use it. But shunning any conversation about PL advancements because alternatives have them and C++ doesn't is immature and unproductive.
No one is saying that . C++ will obviously never go away, the same way that APL will never go away. But what is questioned here is whether it will actually be a _relevant_ skill in future times to come.
To simply say "it will be yet another tool!" is just a value-less assertion.
> But shunning any conversation about PL advancements because alternatives have them and C++ doesn't is immature and unproductive.
Who is doing that, either?
My personal opinion is that the language who eventually becomes most relevant will be the one with the _fewest_ PL advancements, and that will be a sad thing, but is life as usual. Or what was popularly considered a PL advancement last decade will just be seen as a side step in the next. Again, the usual...
> > But shunning any conversation about PL advancements because alternatives have them and C++ doesn't is immature and unproductive.
>
> Who is doing that, either?
Unfortunately many. You can even see these comments on HN.
Sometimes people even get angry over the whole RIIR stuff, or if Rust gets introduced into a codebase, and the project moves away from C++. It's like they ignore the listed reasonings the maintainer explained completely.
Or when people speak about memory safety people pivot it into a general security conversation, ignoring the merits of the borrowing system.
If you speak of the benefits of Rust enums (or Algebraic data types in general sometimes, sadly) it gets called "glorified tagged enums" (or syntactic sugar for them).
People saying "well boost has a library for that" and talking about beast asio to compare it to Rust async, etc.
Or saying C++ can do have the same or similar value ownerships semantic through shared_ptr/unique_ptr when that's simply not true.
Or when people say "well standard library uses unsafe" (without even knowing what "unsafe" in Rust means, I might add)
Uh there's so many other misconstructions or misconceptions that I've seen, but I don't go around collecting them so I can't really remember more from the top of my head.
Look at the Chromium discussion when the devs decided to introduce Rust, or the recent Fish shell announcement, or when Linux decided to add Rust. Full of "but C++..." shills who haven't even contributed to the projects
> My personal opinion is that the language who eventually becomes most relevant will be the one with the _fewest_ PL advancements, and that will be a sad thing, but is life as usual. Or what was popularly considered a PL advancement last decade will just be seen as a side step in the next. Again, the usual...
I disagree because I think nature (and humans) seek to reduce the amount of energy spent on activities for desired outcomes. Ie, we want to optimise the process, and we are lazy. Rust saves me mental and emotional energy. Since changing jobs (from C++ to Rust) by burnout has been recovering and I'm feeling more energised after work too. And the current job is arguably more straining as it has more responsibility. I don't think Rust is quite there yet either, but it feels like a step in the right direction.
> C++ is here for longer than your career will last.
How many C++ jobs are there currently compared to, for example, NodeJS? 1000:1? 10,000:1? I have no idea, but I do know that there are very, very few c++ opportunities in the midwest.
As in engineering, careers are about trade-offs: we can go deep into a tech to make us very qualified for a narrow sub-set of jobs; or we can go broad and be less qualified for a wider selection of jobs. I've decided that broad, shallow skills are more useful than deep, narrow skill sets.
I think the poor availability of C++ jobs is what keeps people from focusing on it as a career, and I was providing a personal anecdote to express that idea. While the software I'm using to write this message may be written in C++, the company who owns the software I'm using to write this message isn't going to hire me.
Worked at cruise line company many years ago that had some IBM mainframe developers who I think used COBOL as the programming platform. Given my preconceptions that few engineers had COBOL skills, I assumed that there were making big $'s in this niche market. Found out it was like 50 dollars an hour which was significantly less that I was getting as an enterprise java dev. Asked one of them why the comp was so low and they said its was because there was still allot of graybearded COBOL devs around and fewer opportunities.
There's this mindset that you have to avoid finding a niche, because you're limiting your options.
Being a perfect fullstack devops generalist is like fishing in the ocean with trillions of fish, while having a niche is more like just shooting fish in a barrel.
You don't need an unlimited supply of jobs. You just need one job, and specializing in something puts you in a good position to find one.
He seems to be talking about some specific type of C++ programming.
Starting in the mid-2000s, C++ started feeling like a different language at each company I worked at. Different libraries allowed, c-style versus STL coding, even completely different ideas about how classes should be written.
I looked at some recent language proposals and didn't even understand what the code was doing. Saying "I know C++" is too vague and almost certainly incorrect.
When you write C++ you have to know that you don't know the language.
If you think you know the language - you are aiming that shotgun right at your foot.
C++'s attempts to modernize usually mean adding features with maintaining backwards compatibility. It's like adding new paint to a bucket of brown paint - things never really get better.
I think the percent of programmers who can keep the language in their head all the time is very low.
That is just in the very well engineered standard library. What kind of code is in your company's repos? What do programmers need to keep in their heads?
Writing good C++ requires good testing, good tools, good education, good colleagues and a quasi green-field because legacy C++ is segfault...
C++'s attempts to modernize usually mean adding features with maintaining backwards compatibility. It's like adding new paint to a bucket of brown paint - things never really get better.
I think the percent of programmers who can keep the language in their head all the time is very low.
There are minefields everywhere.
This is sounding a surprising amount like Javascript at this point. Not hating on JS, but it has significantly changed over the years while maintaining backwards compatibility.
Looking at a codebase I can pretty much pinpoint when it was written (± 3 years).
I shudder at the thought of people who onboarded in JS in the last 2 years coming across a 20-year-old codebase though.
I used to be a die-hard C++ dev. Started learning when I was 13, loved it. Later I ran my gamedev company [0] for 10 years, released 18 titles across Linux, Mac, Windows, iOS and Android - which required writing my own STL-like library, because when I started this the S in STL was aspirational (in particular, VS6 was terrible). I later wrote some C++ at Google.
But now... I don't even recognize the language anymore. The syntax looks alien and clunky. I've also gotten used to writing Java and Python with IntelliJ and PyCharm respectively, to the point that writing C++ feels painful now.
I don't like this. I wish I could find the joy of C++ again (I also like high-paying jobs). Any suggestions of books / courses / tutorials to learn modern C++?
I started C++ firmware development last year coming from Ruby/Java background. Boy, I was so impressed - completely shattering the previous impression built in my college - 2005 or so. The C++ compiler seems so advanced and lets you do so many things like compile time checks. Built a framework for all our embedded development with thing like compile time checks, type safe abstractions over freertos threads/queues etc
I don't know if finance people would consider me "talented", but as a developer who has been using C++ for over a decade, not once in all that time have I ever wanted to work in HFT.
I don't know if that's a solvable problem (maybe higher pay? But I hear they pay well already). Or maybe my perspective is an uncommon one. I just think it's silly to say there's a shortage of C++ devs because a specific industry has hiring difficulties. The article says that it's not a HFT-specific problem, but doesn't go into it.
I'm a talented C++ programmer, but I do try to avoid jobs where I'm doing very much C++ anymore. I used to love C++, but it has become such a pain to work with that I prefer to work with most other languages when I have the choice.
My home projects are mostly embedded systems things, and for those, I use C++ -- barely. I use it in the old "as a better C" style.
I would love doing a C++ job, as the language is a proper challenge. However, being a C# Web developer pays much more, in The Netherlands.
I've also missed the boat now, as I've gained more seniority I'm certainly not dropping in salary and benefits to become a Junior C++ developer and I will probably not be hired for senior functions.
Unless you are in gaming or HFT, setting out to learn C++ in 2023 is a major career limiting factor.
Why would someone burn a sizable chunk of their energy & free time to just entertain those C++ standard committee members sitting on a pile of their RSUs who intentionally delayed almost every single reasonable additions to the language. We are talking about a language that took almost 40 years to get networking support into its standard library! It is a modern museum of bureaucracy in Computer Science.
Some people mentioned the term "modern C++", let's be honest, that is mostly C++11 or C++14, you'd be lucky to get C++17. I won't call 10 years old C++14 modern. Just check where were golang and rust back in 2014 and how much they've changed & created. Modern is the term reserved for languages driven by its user community, like golang, rust, zig etc. New ideas get from open proposals that can be directly commented on by everyone to production in a few quarters, not a few decades.
I mean come on, why would someone with reasonable plan for his/her career choosing to put himself/herself onto that sinking ship called C++?
Let's be clear, learning C++ in 2023 is like migration to Russia/China/Cuba - you give away all your reasonable freedoms & funs to submit yourself to the mercy of a close group of "elites" who try so damn hard to dictate your life & work.
> ... setting out to learn C++ in 2023 is a major career limiting factor.
No it is not.
> Let's be clear, learning C++ in 2023 is like migration to Russia/China/Cuba
No it is not.
> you give away all your reasonable freedoms & funs to submit yourself to the mercy of a close group of "elites" who try so damn hard to dictate your life & work.
No you do not. It is not a slavery operation.
Learning C/C++ now is a good foundation as to why things like Rust and Zig are popular. Understanding the underlying mechanics is good. To say it's a major career limiting factor is hyperbole at best.
Please stop mixing C and C++ together. Learn C gets you to know all the underlying mechanisms. Learning C++ gives you nothing else but some overmarked concepts like OO.
I'm not mixing them. Both are good to have foundations for why things are the way they are. Completely bypassing them is asinine. There's a reason in computer science a computer organization class is still teaches about assembly instructions going through pipelines.
no one is against C or assembly, they are direct models of how machine works, they provide native access to underlying stuff.
the same can't be said for C++, e.g. its OO concept seemed to be cool back in the 90s, but after so many decades, at the core of a legacy language, it is now well known that OO is not the choice, modern languages no longer focus on OO for good reasons.
I encourage everyone to learn C, if they have time, learning ASM is also a good investment. At the same time, I think C++ should be depreciated.
"The good news, though, is that 34.7% of respondents learning to code are using C++, placing it in the top 6 programming languages of that category."
One of the problems C++ has is that this doesn't mean much. In the late 90s when I was an undergrad at college, the main language in the curriculum was C++...
... except it really wasn't. It was a dialect subset of C++ that was what undergrads could wrap their minds around. It was basically C with classes, and even then, the undergrads did a lot of copying and pasting around that whole class thing.
I remember when I was a TA in an early class for the majors, and the central staff updated GCC to a version with namespace support in the middle of one my labs, and suddenly every person in the class had their programs break simultaneously, because this version of GCC had namespace support, and now everybody needed "using std;". Fortunately I could read the resulting error message and worked the problem out in about 10 minutes, but none of the "people learning C++" knew what namespaces were.
I occasionally glance at C++ learning programs the schools are using. They haven't meaningfully changed.
So, a lot of those people "learning C++" really aren't. I expect your average bachelor's degree holder in a programming degree couldn't tell you about move semantics, or explain what exceptions really do in C++, or any number of the sorts of details you need to call yourself a C++ programmer in 2023, let alone a skilled one. C++ is so big.
I feel like C++ is not just big, but in arcane ways. Like needing to know move semantics, but for being such an important concept, there's very little in the way of the language helping you understand it.
Also, it's changed a lot. I learned C++ as my first language, but haven't used it nor kept up with it for the past 15 years. I'm pretty sure that idiomatic C++ is just a different language now than the one I learned, despite the name and basic syntax staying the same.
Headline makes me think of RPG (the language, look it up [0]). It's basically disappeared, but it was one of the key languages used to develop much of the banking system waaaaay back. For a variety of reasons, it's still very much present but the experts are in their 70s and anyone competent enough to debug is well into their late 50s at the youngest.
Attempts at upgrading to, say C++ or Java usually fail for the same reason any massive system-defining upgrade fails, so they have to trot these guys out every now and then to the tune of $100-500K per day whenever there's a problem.
Moral of the story - sometimes it could be a better very long-term strategy to be an expert at just one language that has enough mission-critical functions in an industry that doesn't like investing in IT. C++ could turn into one.
Yes, a day. When you're dealing with a bug that could disrupt all international transfers at your bank for several days, and the kid you have on staff who learned RPG on YT has reached his limit, it's cheap.
I learned about it from a friend who worked at an IBM partner with a tool to help translate RPG to something else. Rarely worked because of the decades of nuanced patches to deal with evolving business rules, and when it did they usually came in several million above budget.
> The pool of talented C++ developers is running dry
> However, only 9.3% of respondents used Rust at all and only 8.8% did so professionally. C++, meanwhile, languished at 48%.
Oh, and don't forget the classic tweet these clickbait bloggers love to quote from official Microsoft Cloud Man, Mark Russinovich......."C++ bad, Rust good".
The real issue seems to be that C++ jobs pay 2-4x less than other jobs. Why would I suffer through arcane template compilation errors when I can make 3x more writing basic JS? I actually find C++ really fun but I don't see much opportunities in it right now.
At least at the companies that the article is mentioning (Citadel, for example) the pay for coding in c++ will likely be 3x _more_ than writing some basic JS.
New grad packages are usually in the 4XX-5XX range.
Which C++? C++ is not a static language. There have been many revisions to the language standard over the past 30 years. I started using the language in the early 90s and continue to use it today.
I try to keep up with the new standards and incorporate features that I find useful in my code, but the majority of it would probably compile with a C++11 compiler. If I were to suddenly be introduced to a code base written by someone proficient in C++20 with some C++23 features sprinkled in; I would likely require some time to figure out what some of the newer code actually does.
Looking at job postings in my area (flyover state), I seems kind of rare when a job is posted that is primarily looking for someone proficient in C++.
One day, tech companies are going to re-learn the value of training up talent, with increasing compensation to match skill so they don't jump ship. Of course talent pools dry up when every company expects people to be trained by other companies.
I started writing C++ about 15 years ago. It's still my strongest and most enjoyable language. However, at the moment I mostly write Swift\ObjC because I couldn't find any decent paying C++ jobs. I'd love to get back to it.
I like Rust and think it's got a good future. However I've not seen too many job postings that actually use it, but as it catches on more that will probably increase. I guess it depends on if you're thinking near term or long term.
Every time I try and get into C++ development I get hung up on build systems, compiler choices, and IDEs. For some reason I just can't build up enough steam (motivation, determination, whatever) to get past that initial hump, even though I know once I get rolling it will be fine like every other language. I've tried lazyfoo's tutorials several times and can never figure out how to get the SDL libraries working correctly >_<. Maybe it's worth another shot...
Lots of comments here debating what’s legacy, what’s modern. Here’s my take:
Never use objects with behavior. (Ban OOP.)
Prefer monadic types.
Functions should only take or return moved values or const references. (These form linear types when you need state and ensure immutable values for stateless types.)
Never use a template without a concept.
Prefer the stack and ban mutable memory.
You end up with a functional language which resembles Haskell and competes with C. Not even rust has that level of generality.
I found 10 years back that getting into C++ jobs that would give you valuable experience were the ones that already required you to have that experience, or have very good connections. The ones that were easier to get into were the C-with-classes balls of mud that only were written in the first place because they were early for Enterprise Java to be invented, I doubted that entering from the latter would give you a pathway to the former.
I decided it wasn't worth pursuing, went from doing Clojure to Big Data in Scala.
Ten years later, I hear that there's not enough "C++ developers", read, "C++ developers with the desired qualifications". Seems straightforward to figure out why.
I cannot tell how many times I have heard this story, over and over and OVER again, yet their complain remains the same and the issue is still unsolvable!
I have said this before and I will say it again (until you HR people embed it in their minds): if you cannot find C++ developers, start training people and persuade, let alone motivate them to embrace it, learn it deeply and learn its rough corners.
I have lost counting how many interviews I went through and wasn't the right match for them, but loved my zeal for C++ as they have exclaimed with surprise.
When you get rejected so many times, you say "C++?! why bother anyway?" and you give up and follow a different route, using a different toolset that does not asking for the unimaginable, whatever that is they are looking for, and you get respected for what you can offer to them!
If I had the way to gather all HRs around the globe and ask them all at once what is it they are looking for exactly, it would have saved us all from wasting our time.
The whole situation has gotten way out of hand and needs to end, at last!
Companies seem to expect anyone that isn't a new grad to not just have recent C++ experience, but also in the right specialty. It needs to be game development, web browsers, or whatever.
Even as someone with C and C++ experience on my resume, I just haven't seen that many jobs I meet the requirements for.
Domain knowledge usually trumps programming language skills for more experienced positions, but C++ is so hairy they often want expertise there if they need it.
But those domains are usually tied to C++ anyways, games, web browsers, operating systems, etc… are usually written in C++ right?
I used c++ for 15 years but I haven’t touched it in over 10 years now. The language I learned is totally different to the point where I don’t want to learn it. It’s like an entirely new language. The C++11 was the last version I used and to me the modern version of C is trying to do too much.
It doesn’t help that we’ve saturated the pool of programmers with JS and Python developers who are trained primarily to glue libraries together instead of actually writing code that isn’t third party library glue. That’s not a common job for C++ developers (and when it is, the gluing process is a bit more involved). This makes it pretty hard to satisfy our hiring needs with a huge number of the people who entered programming seeking fame and fortune with the data science and web dev waves. A lot of people aren’t good enough to pick up more complex and involved systems.
I’ve noticed that it’s not so bad to get someone proficient in Java or C# or Fortran to pick up C++, so hiring people from those backgrounds helps us fill the C++ developer roles. The python and JS devs: not so much.
People aren't scared away from it. It's simply that there are few jobs relative to other languages. Why would I commit to learning C++ when there's at least 25x the jobs in JS/TS, Python, or, Java? It sounds like these trading companies are complaining but don't want to train.
This is the capitalist version of Vonnegut's "everybody wants to build and nobody wants to do maintenance." The kind of programming HFT firms want to do has vanishingly low diminishing returns basically everywhere else. They're used to lazily offering high pay and bad working conditions to self-driven people who learned C++ because it was the only tool available. Now other languages are mature and they are being caught flat-footed without a development pipeline for junior devs.
Strategically I understand - it was a pretty good bet that you could use the same "get gud" philosophy that still powers their trading desks, but they just got unlucky because we're in a moment where the net opportunity-cost for not-learning c++ is basically a reward (better work experience, often better money).
I'm stunned that the OP doesn't come to the obvious conclusion from his own data: migrate to Rust. What better way to attract new talent? And from personal experience, it's guaranteed to result in a more stable, less buggy, and more responsive system.
Ideally I would prefer working using a language that I am most comfortable with like Nim. The interface with C++ is pretty good. It's also easy to learn and onboard into a team. Wish it was more popular.
I'd love to have a C++ job. I didn't study for an A GPA to move data in and out of databases all day.
But I currently live in a 3rd world country which has no software C++ jobs. And I can't get a foreign C++ job because I don't have C++ experience.
Imagine wanting to leave all your networks, friends, family, and culture; get a lifestyle pay cut and still not get a C++ job. All skilled migrants must get a masters degree or PhD in their destination country just to get their get their CV viewed by an actual person.
I wrote a ton of C++ back in the early 90's. Should I dust off my chops and spend the last few years of my career consulting like the Cobol and Fortran people?
> Anthony Peacock, formerly a quant at both Citi and Citadel said “it’s impossible to find people with a really high level of C++ skills which is exactly what every trading company wants.”
When you're looking for devs with a "really high level" of skill, that's at the far end of the knowledge curve where you'll find a smaller number of devs. I'd imagine the same holds true for pretty much every language, not just C++.
I see some comments comparing C++ to COBOL, given similar articles in the past. However, this is where I think COBOL is much better than C++!
Most developers could jump into a 40 year old COBOL codebase and safely make changes. This is probably less true for even a 20 year old C++ codebase. Sure COBOL looks old but its complexity is so much lower.
Similarly, I haven't written COBOL in 25 years but I suspect the language hasn't changed much, unlike C++.
I think you’re right: COBOL is boring, C++ is exciting in terrible ways! It would take time to understand why COBOL was written the way it was but you’d need to understand that with any legacy app, but C++ also introduces a lot of arcane language complexity to learn just to understand the business logic.
C++ has become a fantastically complex language. The pool of people with a "really high level of C++ skills" is narrowing because "really high level" has become more difficult to attain.
I don't understand why trading companies settled on C++, or why they need a "really high level" of proficiency with it. But it seems like a self-inflicted problem.
> Hickling pointed to Java, which has long “seemed to be replacing C++ itself,” but hasn't.
Just like I said when this article was originally posted last December, this is totally ignorant of history. Java obliterated C++ in the enterprise space. All of Java's marketshare today would belong to C++ had Java (or any other language of its ilk) never been produced and/or popularized.
If I was picking language for a new project, I would take c++ over golang or Java hands down. Many people don't realize it, but modern c++ is actually very good.
Java's gotten a lot better with latency with new GCs. Some codebases use statically-allocated memory in Java and do it very carefully. Sometimes shops will just shut off the GC. Graal also gives you AOT options now.
One thing I read is that memory allocation can be faster in Java because malloc can result in system calls. Deallocation is what's slower.
Why stop there, any one who spends money on internement is unproductive human being, it is immoral to pay for Netflix instead of helping kid in Africa, right ?
The entertainment industry is useful to keep people entertained, which is good for their overall well-being. I think you don't have to feel bad about your Netflix subscription. And the sustainable development goals are not only about helping kids in Africa.
* corps don't want to fund education or hire anyone that hasn't already done what they're doing. They want to extract as much as possible out of workers and shove that money elsewhere, never back into the resources that allow their company to exist.
lots of expensive California C++ coding got outsourced to the Ukraine and other places, faster than you can say 'dollar conversion' a long time ago. What is this trend, similar to "shortage of truck drivers" and "this airline stewardess job pays up to $300k per year" ?!
I'm very good in C++. If you offer enough $$$ i might work for you (prefereably remote).
But in all honesty. I would rather like a non C++ job, because i have ~30 years of work before me, and i don't want to end up like those dinosaur Cobol or C programmers today.
"The reality is that there are plenty of C++ jobs available in finance, and that compared to other languages there are comparatively few people to fill them. The language may be hard. But it's also worth it."
Measuring growth or shrinkage by % seems like an obvious mistake. While I agree from my own anecdotal evidence this is true, the article doesn’t make any substantial case for this (and the quality is overall pretty poor).
One solution would be to ask the "rainmakers" to replenish the drying pool with some "liquid means". Developers are known to be attracted to the highest bidder / latest master of the Universe.
This feels like an ad invoking Cunningham's Law. There's a link to the job board at the bottom after paragraphs stroking the egos of oh-so-clever C++ developers and reminding them how well finance pays.
Can't we have an automated C++ to Rust converter (with full correctness), and then add a pass of GPT3 to transform it into something readable (only correctness-preserving transformations allowed).
Most of the core infrastructure at big techs like Google and Meta (and I can only assume Microsoft) are written in C++. Many of the folks working on said infra escaped from finance to get there.
Personally, I would love to code in C++ but most projects are Python these days. I spent most of my career as a C++ generalist, along with doing a bit of graphics work.
C++ at Google is almost a different language (and nonstandard tooling and libraries and workflows). It's entirely possible to have decades of experience that don't translate to anything useful outside of Google. To give you an example: I joined Google when SVN was a thing, and by the time I left* I was a senior software engineer with zero experience using git.
I don't doubt that the pool of capable C++ developers is running dry. I was never full anyway. But talented? I'm not sure if talent is that important to become competent in C++ - masochistic tendencies are much more important for sure.
But also, these companies have a lot of weird modern C++ shibboleths in their interview processes. If they compromised on those and went for low-level engineering, performance engineering, and software engineering skill instead, there would be many more candidates.
This, among other reasons, is why I avoided applying to these places when my C++ skills were much more current. Certain shibboleths might have been applicable, but these were things any junior developer could have learned and made use of with a few minutes' study: they shouldn't be used in an interview process.
I interviewed at a trading firm once, while I was working at Netflix (because Netflix encouraged us to interview for outside jobs at least once a year). The comp would have been double my Netflix salary.
But I would have had to work in their office in Manhattan, be in by 8:30am every day and not leave until after 5 at a miniumum. But that wasn't the part that scared me off. It was the fact that I would not be allowed to share my work internally. I would not even be allowed to brainstorm with people doing the same job in other areas of the business. I wouldn't be allowed to take my laptop home, so if I had a hard problem to solve, I'd have to stay in the office the whole time. So basically they expected us to never see our family nor collaborate with anyone.
Basically, they were so worried about secrecy of their trading algorithms and people sharing them with other companies, they didn't even let people share internally for fear that one person would learn too much about their business.
I decided to stick with my FAANG job because even the ridiculous money wasn't enough to make it worth the stress and isolation.