Hacker News Reader

I feel like better expertise targets tend to be more durable. In other words, rather than expert in a specific technology or technique, the best experts had the ability to develop expertise in any given technology within a space and often overlapped cursory knowledge with other spaces. I met plenty of graphics experts at Oculus and they didn’t care so much about whether it was D3D or Vulkan - originally they were D3D engineers for PCVR and then a good chunk of them shifted to Vulkan once the focus shifted to mobile VR. They just knew how those APIs mapped to the actual HW reality, how things connected, why things were slow, how to improve performance, etc. The mundane stuff of “what is the sequence of steps to do X in Vulkan” is answered by Google/StackOverflow (or even these days ChatGPT). Heck, a good chunk of them were creating their own new APIs. This isn’t unique to Meta by the way. It’s like engineers who say they’re “C” or “C++ experts”. With the exception of authors like Scott Meyers or people working on the C++ language spec who I think can truly maybe claim that title, the kind of thing that is called a “language X expert” is the kind of expertise that a good engineer should be able to develop in any language with 2-3 years of practice and proficient mastery within ~3-12 months because the true expertise is the underlying CS principles (at least for a family of languages - I’ve never done too much with non-Algol families so I don’t know how I’d fare there).

However, I do agree that generally graphics engineer is a niche limited to the few people working on gaming engines, VR R&D, or animation R&D. But those skills, at least today, are generally transferable to AI engineering because GPU compute plays such a huge role. There’s less graphics programming of course and the APIs for GPU compute are a bit different, but AFAIK many of the hardware concepts remain (e.g. wavefronts, how GPUs do threading, etc etc).

When people like Bjarne Stroustoup, Herb Suttter, Andrei Alexandrescu say they are by no means a C++ expert, always beware of anyone that says otherwise.

Same applies to most languages, unless they are talking about toy languages.

Even something like C or Go, have so much room to debunk such experts. Between compilers, versions, language evolution, runtime, standard library, OS specific behaviours,....

> When people like Bjarne Stroustoup, Herb Suttter, Andrei Alexandrescu say they are by no means a C++ expert,

Then you know something is deeply wrong with C++. If even they aren’t experts, that just means the language, despite being a human made artifact meant to encode human thought, is beyond human comprehension.

That’s kind of a problem, isn’t it?

While it is kind of fun bashing C++, I also noted "Even something like C or Go, have so much room to debunk such experts. Between compilers, versions, language evolution, runtime, standard library, OS specific behaviours,....".

Anyone that thinks otherwise, we can arrange a pub Quizz in Germany, I get the questions, audience has to give up any kind of device with Internet connection.

Many times when someone says "X-lang", they actually mean the entire ecosystem, practices, third party libraries… And for anything popular enough it is indeed impossible to be an expert in all of that. With C++ that’s still the case even if "C++" only means the language itself.

I’ll concede that C with the insane breadth and (over)reach of UB, is closer to C++ than I would like. And that’s a problem too.

I don’t know Go well enough to judge.

We can start with level 1 questions, "name which version where this feature came to be".

Okay, you could… and if you’re honest enough to accept answers like "it’s over 20 years old" I guess any expert could answer that. My main point remains though: if even Stroustrup or Stutter can’t answer 95%+ questions of this kind, it would show beyond a doubt that C++’s complexity got completely out of hand.

Even Stroustrup’s humble bragging about being a "7" at C++ looks real bad. If I’m not a 10 at a language I created and maintained my whole life, I’ve birthed a monster.

My example question was actually in regards to Go, made public in 2009, with 14 years of history.

The bonus round of the same question would be, "name one feature that was removed before 1.0".

We could make this question even more fun, if taking into account gccgo specific extensions, or runtime changes as well.

To put it bluntly, if someone shows up calling themselves an expert, I expect World Cup skills towards the language they are an expert on, across all levels.

While it may not be strictly correct semantically, I'd expect most people to understand "Go expert" as "expert Go programmer", not as some sort of Go historian.

I get the overall point, but this humility makes it difficult to use some kind of grading/levels.

Take e.g. MS Office as an example of a large C++ project. Certainly, there are developers with just "average" knowledge of C++ working there. Then there are people having strong/advanced C++ knowledge.

But in a project like MS Office there are certainly devs who are still much stronger in the language, best in the project/company, but still likely below people like Stroustoup or Alexandrescu. How to call those? I think avoiding the term "expert" just to be consistent with the above-mentioned humility is impractical.

Humility regarding on how much one actually knows, is a common trait in senior developers.

So when one sells themselves as über expert, that is already a kind of red flag.

That's pretty sad. Without people like you, the engines all the others use would not exist. It always saddens me to see people making millions off of high level tools while the people who made it possible get limited returns.

I'll join the choir and say to not ever try to become an OpenGL expert. It's deep and kind of useless. First of all, if your application use OpenGL, either:

- you've unlimited resources for testing and vetting drivers, and you're working for huge CAO software that can tell users what to use.

- you don't have huge resources and then your only hope if to use an abstracted API like Skia, GDI, bgfx, IGL, WebGPU, anything other than using OpenGL directly.

It will just never work everywhere if you use OpenGL directly, and you won't be able to debug the driver or find all OS x drivers x GPU combination you need to debug it.

Your OpenGL-specific skills (avoiding driver bugs) will have very little value, but 3D-specific skills could. It's a waste of time that is only rivalled by learning C++. I would concentrate on abstracted API that avoid those driver bugs, or even learning a game engine to stay topdown.

This is something that those arguing for OpenGL as a kind of universal 3D API never get, the amount of code paths can scale to the point that it is like using multiple 3D that just happen to be all called OpenGL.

But without people like you (who understands the low-level graphics programming), the development of engine will completely stagnate.

> Sure, I could have gone and re-skilled and learned another similar graphics API, but the second problem is nobody really needs people who write low-level Direct3D or Vulkan or Metal anymore because that's all abstracted for you by engines. And there are max 5 or 6 companies in the world that even have the need for people who can do low-level graphics drivers. It's a career-limiting niche.

I did that for a living and can only agree partially.

First, the part were we agree: only a handful of companies hire graphics driver developers. This means that if this is your career you need to be willing to either put up with the idiosyncrasies of your employer or be willing to move geographically. As a result, people tend to stick to the same employer for many years.

As for OpenGL becoming obsolete, it's like anything else in tech: you need to keep up with whatever is in demand. Vulkan/Metal/DX12 didn't appear out of thin air, they were created by the exact same folks who worked on older APIs for many years, so it really wasn't a huge paradigm shift for driver developers.

GPU driver development is a perfectly valid career choice with good job stability and very decent pay.

What I disliked about it is that, perhaps contrary to what you are saying, I felt that it was rather repetitive and after having worked on a few different GPU generations. Innovation happens in other areas like GPU architecture, not in driver development, but that's a topic for another day.

Going broad rather than deep cuts both ways. Sure, you have more employment opportunities, but the value of your individual contributions has a ceiling. That means after a relatively short period of time, you plateau career wise. Like is a generalist with 15 years of experience really that much more valuable than one with 7 years? Not really. So if you want to progress beyond a generic senior engineer, then you need to specialize in something.

But how many of those deep specialists got there by rationally weighing pros and cons and then picking a strategy?

My guess would be that for every example who got there on the curriculum drawing board, there are at least two who just happened to be in the right place at the time the technology grew, four who got infatuated with "their" technology so much they'd specialize no matter the pay relative to generalists, and eight would-be generalists who failed to keep their generalization in balance through a sequence of projects built on top of the experience of those before.

GP mentioned Carmack, that outlier of outliers. He did not get there by picking one technology and burying himself deep, he did whatever was practical. At the time IrisGL begat OpenGL, Carmack was battling the limitations of EGA and CGA in the Commander Keen series and then moved on to create the 2.5D wonders that followed. But he was more than ready to retire his world class expertise in software rendering when OpenGL came into reach of PC hardware. Textbook generalist behavior.

>It's a career-limiting niche.

This depends on your career aspiration. There are not as many companies hiring graphics programmers as there are shops who need "front end" or whatever they call scripting web pages nowadays but the barrier to entry is rather high so there are plenty of jobs in every FAANG plus Microsoft, Tesla, self-driving shops (I even have been approached by self-flying robots startups couple of times), training (from military to oil rigs), of course, the every game studio (which may or may not pay little and force you to work overtime, I am pretty sure a graphics programmer at, say, Roblox has better compensation and working condition than a front-end developer at Amazon, for example), and yes, the 5 or 6 companies that need drivers (Apple, NVidia, AMD, Qualcomm, Samsung, ARM, Intel, etc).

Focusing on a single technology never was a great idea though. Even already towards the end of the 90's D3D was the better choice on Windows, so one had to write code against multiple 3D APIs anyway. This also gives a better perspective where the strengths and weaknesses of the different technologies are and it makes it easier to learn new APIs. But in the end, 3D APIs are just a utility to write applications (mostly games), not to build one's career upon. 3D APIs come and go and are (to some degree) also subject to fashion cycles, the underlying GPU hardware develops a lot more predictable than 3D APIs (e.g. especially Vulkan had pretty bad "mood swings" recently).

Of course when focusing strictly on money and "career growth", going into game development is a pretty bad idea to begin with ;)