Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

Post reply on HN
Print view View original

441–450 of 595 posts

Re: The pool of talented C++ developers is running dry

#441

Post by bombolo »

varispeed wrote: post #196
AtlasBarfed wrote: post #157

Earlier quoted context omitted.

Exactly. SHOW ME THE MONEY. I'll be a C++ programmer. 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…

To be fair all engineering positions are paid poorly if you compare to the profits corporations are making.

software companies often don't make any money at all.By that logic paying them at all is too much.

Re: The pool of talented C++ developers is running dry

#442

Post by sshnuke »

zeroonetwothree wrote: post #374
nostrademons wrote: post #307

Earlier quoted context omitted.

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…

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.

so gaming addiction is also a silly argument?

Re: The pool of talented C++ developers is running dry

#443

Post by raverbashing »

netheril96 wrote: post #397
cue_the_strings wrote: post #323

Earlier quoted context omitted.

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 wi…

> At least around here (Europe), 1.5-2x more EEs graduate each year compared to CS people, Do you know the reason for that? EE is significantly harder to learn than CS, so it baffles me why more people are choosing EE.

Probably has to do with the 'Engineering' in the name

But yeah, fully agree with you and parent comment. And no, it is not worth it

While naturally CSs don't know about Analog or GHz stuff, EEs know very little about best practices on SW development. So it kinda balances out

Re: The pool of talented C++ developers is running dry

#444

Post by tomtom1818 »

jedberg wrote: post #142

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…

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.

You did the right thing for you and your family.

Re: The pool of talented C++ developers is running dry

#445

Post by rightbyte »

dataflow wrote: post #416
Pelayu wrote: post #399

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.

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 a…

C'mon. In practice the differences are hugely overblown. The fundamentals are about the same.

Also doing "modern" Cpp with dogmatically ugly static and reinterpret_cast and shared or unique_ptr:s everywhere is just annoying.

"Best practices" in SWE are usually antipatterns since they are Cargo culted in a dogmatic way.

But then again I am a embedded C programmer ...

Re: The pool of talented C++ developers is running dry

#446

Post by bostik »

bobsomers wrote: post #384
nostrademons wrote: post #288

Earlier quoted context omitted.

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…

> 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 th…

> 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

Re: The pool of talented C++ developers is running dry

#447

Post by snordgren »

impossiblefork wrote: post #428
jedberg wrote: post #142

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…

>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…

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.

Re: The pool of talented C++ developers is running dry

#448

Post by amyjess »

lelanthran wrote: post #400
WorldMaker wrote: post #333

Earlier quoted context omitted.

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 str…

> 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 s…

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.

Re: The pool of talented C++ developers is running dry

#449

Post by jleahy »

nostrademons wrote: post #217
tinfoilboy wrote: post #127

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 w…

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…

Bloomberg is actually mostly C++.

Re: The pool of talented C++ developers is running dry

#450

Post by ben-schaaf »

logicchains wrote: post #402
spoiler wrote: post #75

Earlier quoted context omitted.

> 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,…

> 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.

Post reply on HN