Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Job prospects for pure C and C++ programmers?
28 points by rrao84 34 days ago | hide | past | favorite | 39 comments
I am looking long-term - 15 years at least and I want to know from the HN folks, what prospects do I have as a C and C++ programmer with a good grasp of algorithms.

What other fields should I pick up along the way? And, do I need to have significant knowledge of AI/ML/Cloud-computing/Data-Science, etc. to sustain myself in the long-run (long-run being defined as 15 years)




I wouldn’t build my career around a programming language. Languages are one of the least important factors in a programming career.

That said, if I had to choose a couple of languages for the rest of my career I would choose C, C++, and SQL. All of those have enjoyed huge success since they were introduced, with mountains of legacy code and plenty of new development.

Once you master C and C++ a lot of similar languages should be very easy to learn: Java, C#, Python, Go, Ruby, PHP, Swift... they are all more alike than not.

As a hiring manager I would not be very interested in someone who only worked in one or two languages, or only had language expertise to offer. A candidate stuck with two languages for years would send the wrong message for sure.

To build and sustain a long career you need to solve problems and add value. You need to get along with people and contribute positively to a team. You need to learn business domains, not just languages and tools. You need to be the person who says “I can figure it out,” not the person who says “Leave me alone, I only want to write C++ code.”


Yes, that is the conundrum of modern software engineering.

Companies would like to have people that are flexible and can jump on any language or technology while people have a natural need to sharpen their skills and build upon and enrich their existing knowledge.

Learning the Nth framework or language is neither of those. It's a grind, it's waste and it's always running only to stay in the same place. Programmers instinctually feel this, but the argument of flexibility is persuasive and market success does seem at least to correlate with breadth of skills.

To put it bluntly: many programmers don't give a crap about building successful products or producing value and instead want to become masters at what they do.


I agree, and well-put.

If we don’t constantly hone our skills and learn new things we risk getting left behind. I think programmers can imagine that as a bigger threat than it is, but it can happen if one chooses a dead end to specialize in. Not getting in on a trend early presents the risk of getting left behind, especially in today’s tech hiring process that often requires experience with relatively young languages and tools. That said I would still focus on the larger trends rather than specific languages or tools.

When I got into programming 40 years ago it was just barely possible to learn most of the major languages and tools used in business applications. Today that’s not even possible for niches like web development. I read an interview with Bill Gates a while back. We’re close to the same age. He said he just got lucky, born at the right time, and he got into programming as a teenager and grew up with the technology. He said it’s much harder now to get started because there are so many places to start, so much to learn, and the languages and tools continue to drop on us faster than we can keep up. That can lead to despair, or over-specialization.

I now specialize in web applications, but I can’t learn everything, so I don’t try. I wait until something gets traction, when I start seeing demand from customers (rather than HN buzz or a mention in the TIOBE rankings), before I pay attention to it. Once a language or tool gets significant traction it tends to have a long lifespan: Unix, C, COBOL, SQL and relational databases, PHP, etc. I work mainly on legacy software so I don’t have to stay bleeding edge. I know this seems like a boring “I give up” path, and I partly got here because of increasing age discrimination, but it let me relax a bit about keeping up with beta versions of Rust and React and focus more on what my customers actually want.


Learning a language is easy, Learning the idioms, ecosystem, culture of a language to become senior level can take years.


Maybe. I think of a senior programmer as someone with a track record of adding value, capable of solving problems, leading a team, making sense of requirements.

Mastering every intricacy of a language and its ecosystem has value but that’s not what most employers or customers care about or pay for. My customers almost never care about the language or tools I use, or quality of the code, or anything programmers obsess over. They care about spending their money to get more value through reduced costs or increased efficiency.

You can optimize to impress your peers, or to always have a job (or customers if you freelance). Depends on your priorities.

Programming expertise is largely cumulative because the basic concepts apply in every language. Someone with 5+ years experience with real C++ projects shouldn’t struggle too much with Java or Python.


I think you are forgetting that when somebody solves a problem and adds value, it cannot be disassociated from how it got there. That is where mastery of the language/technical details come in. Of course you don't need to know all dark corners but fluency in commonly used idioms/techniques are a must.

PS: David Packard's address to Managers might be relevant here - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...


To get anything done fast, and reliably it takes that knowledge to be decent.


Of course. I should have written that programming mastery, which includes a good understanding of how to use programming languages, is necessary but not sufficient to achieving "senior" status, or building a long-term career in the field. A programmer who focuses exclusively on mastering languages is like an architect who focuses exclusively on mastering drafting. I would have thought this would go without saying, but more and more I see programmers define themselves in terms of languages and related tools, and even demand that their work revolves around their preferences. That's a limiting choice, not a way to build a successful career.


Please point me to these employers who don't care about technical skill.

I was a tech lead for a year and senior developer for another on a FileNet application. I would love a $140k+ tech lead position that doesn't require experience in the tech.


I never wrote that employers don't care about technical skills. You either didn't read what I wrote or you reduced it to a binary choice so it doesn't make sense.


"My customers almost never care about the language or tools I use, or quality of the code, or anything programmers obsess over."

I would say technical/language expertise falls in that last category. You also allude to employers caring more about the qualities listed in your first paragraph and caring about output/value.


That's my experience. My customers never tell me "We need 2,000 more lines of Javascript code by next month." They do tell me "We need to reduce shipping costs" or "We need to put up a new marketing web site." They don't care how I solve those problems, though their existing infrastructure, code base, and staff will usually put some constraints around the possible solutions.

My customers almost never look at my code. Most of them couldn't tell you what languages and tools I used. They care about the result, in the same way I care that clean water comes out of my faucet a lot more than I care about what kind and brand of pipe was used in the construction of my house.

As I already wrote in other comments, mastery of multiple languages, tools, idioms, and purely technical skills are necessary but not sufficient to call yourself a "senior programmer" (in my opinion, anyway), and necessary but not sufficient to build a long-term career as a programmer.

I know in many jobs language skill and experience matters a lot, because the company has already committed to an ecosystem and can't afford to or won't invest in lengthy training (mainly because of the high cost and risk). Some shops absolutely do care that their new hires already know Python or C++ in depth, and I have worked in those environments. But that's because they can test and measure that ability, whereas they can't easily measure a candidate's ability to add value and solve problems in the business domain. I can say with confidence that I can learn a new language ecosystem very quickly because of my decades of experience, but I may not be able to persuade a room full of programmers quizzing me that I have that ability. As a freelancer I'm normally dealing with business people faced with business problems, not a a group of programmers forced to interview me. Either I can deliver or I can't, that's all that matters to my customers. I have a career history that shows that I can work in a programming team and contribute effectively, and I can learn new languages and tools pretty fast, but I would today not get far in a Google or Facebook interview because they tune their screening process for technical skills they can measure and evaluate. They can afford the false negatives. At my age they wouldn't consider me anyway but that's another problem. I used to work in Silicon Valley for a big tech company but that's not an environment I'd go back to. I now prefer working directly with the people who can make business decisions and pay for them, and not for people who think my inability to balance a binary tree on a whiteboard is relevant.


I run a low-level programming conference [0] with professionals who rely on C and C++ day-to-day or just low-level stuff in general.

While this is a plug, I genuinely believe joining the event and talking to them would help you. The networking / hallway effect, even virtually, shouldn't be underestimated either.

Good luck -- there's definitely lots of system software people needed, as someone else here pointed out.

[0] https://www.handmade-seattle.com


So there is the Problem Domain(specific subject expertise eg. ML, Big Data etc.) and there is the Solution Domain(Languages, frameworks, platforms etc.) As a Programmer you need to become good in the latter so as to apply it in any problem domain that you might be asked to do in a specific job. IMHO, a decent mastery of C/C++ is a must. Because that entire ecosystem allows you to work on everything from dinky little MCUs to honking big servers your opportunity space is large. They form the underlying bedrock and a "glue" between everything. The added benefit is that you are forced to understand how Computers really work. Thus you can fully focus on the problem without simultaneously struggling to map it into a specific language/framework/toolchain/HW. Of course in any non-trivial system, you may need to pick up different languages but that can be done as need arises (for similar type of imperative/OOP languages). C/C++ will never go away and will always be needed.

On the Problem Domain front, Cloud Computing and Data Science are here to stay. They are fundamental shifts in the computing space and hence one needs to become knowledgeable in them. I am not too gung-ho on the AI/ML fad since there is too much hype around its supposed benefits but of course you can study it for its intellectual challenge and apply as need arises.


Thank you for your insights. A couple of answers talked about Rust - do you have an opinion on this language and its uses?


I know very little about Rust and have quite honestly, not bothered with it at all. It definitely does not have the market penetration of C/C++ and hence not proven itself in the "real world". You can do anything and everything in C/C++(multi-paradigm language). I will get more "bang for my time" by upgrading my skills to C++17/20 from C++98 than i ever will studying Rust.

From a current industry/job pov, i think the following are the most important ones; C/C++, Python, Java, SQL, Javascript and C# (from MS ecosystem). They allow you to tackle different possible domains.

Also given the prevalence of distributed systems; Erlang/Elixir are good to learn.


There are lots of jobs in systems software that almost all C and C++ with some scripting languages. I think in this field the most important things to understand are operating systems, Linux pthreads / syncronization, some hardware fundamentals so it memory coherence and fences make more sense.


I agree with gregjor, and I’ll just add that I recommend checking out these (highly entertaining) videos by Alex Stepanov, creator of the C++ STL: https://www.youtube.com/playlist?list=PLHxtyCq_WDLXFAEA-lYoR...

In the first few lectures he lays out what he thinks it takes to be a great programmer. I’m pretty confident that there will be a job market for great programmers for at least the next 15 years.


+1 for Stepanov.

Programmers who can solve problems, add value, and work with other people will always be in demand.


Not to be snarky, but this is just a oft-repeated platitude by the "Management" types who do not understand the psychology behind programming. Given the synergy between language and thought expression, mastery of a language is what will help you solve a problem and add value. If you just have a cursory knowledge of the language you will never get anything done.


I've been programming professionally for 40 years. Sometimes I'm in a manager or hiring position, but mostly (as a solo freelancer) I'm working directly with customers and solving business problems, using programming skills.

I'm very familiar with the psychology of programming. Read the classics: Weinberg's The Psychology of Computer Programming, Tom DeMarco's Peopleware, Brooks' The Mythical Man-Month. Notice that those books are all about programming but not about languages. Alistair Cockburn studied programming success and failures and concluded that team dynamics -- "soft" people skills -- are a first-order driver of project success. Brooks came to a similar conclusion.

Mastering several languages well enough to produce working code and (more important) participating in a team and business organization is a necessary precondition to calling yourself a programmer. But language mastery is not sufficient for long-term success (many of the languages and all of the tools and platforms I worked with in the 1970s and 80s are extinct today), nor is it sufficient to contribute at a senior level. By analogy a person can get through life just knowing how to hammer a nail, but they aren't going to work their way up to architect doing that, and eventually they'll get replaced by a nail gun.


>Sometimes I'm in a manager or hiring position, but mostly (as a solo freelancer) I'm working directly with customers and solving business problems, using programming skills.

I think this explains why we seem to be a little at cross purposes :-) Your job requires Programming but you are not "just" a Programmer (you are a one-person company). As i interpret it, "Programmer" is a specific role within an organization which demands more of technical skills and less of others. Their focus is to design/implement a module within a larger system and not bother about Customer Relationship, Sales etc. which are no doubt, important facets for a company but it is not their role to play (Brooks says the same thing with his "Surgical Team" metaphor). Most "average" people have enough innate "Soft Skills" to function in a team working towards a common objective which is usually sufficient for a programming role.


I have solo freelanced for a little over a decade. The prior almost 30 years of my career was mostly spent in cubicle farms with other programmers. I started programming professionally (meaning I got paid to do it) in 1977, to give some context. I started programming for free, on my own and in school, in 1974.

One thing I learned early on, thanks to some good mentors and managers, was that expanding my interests and skills out of programming would improve my chances of surviving a layoff or getting made obsolete. The most recent incident, at my last full-time job at an educational software company, illustrates that. Most of the programmers I worked with limited themselves to a couple of programming languages, hated meetings, did not interact with marketing or sales or management except under duress. When the company's fortunes turned and they started laying people off, I survived. I actually asked the CEO (my two direct managers had been laid off) why more senior people had lost their jobs but I hadn't. He told me that I was the only programmer who had taken an interest in the business, could work with marketing people, and had expanded my skills when needed (I had to learn enough Lisp in a hurry to deal with a product the company bought and had to integrate, no one else volunteered).

I've had similar experiences in my career, and I attribute it to being that one person, or one of a small number of programmers, who took the opportunity to learn the business domain and contribute in ways beyond just writing code. I survived at another company that replaced a lot of in-house code with a Salesforce-like product, probably because I was one of the only people in the programming group who didn't crap all over and moan about the management decision (I actually pointed out that our backlog of technical debt evaporated when the company moved to a third-party solution).

I still write code most of the time, but my customers (most of whom I've had for 3 years or more, a couple for a decade) tell me they appreciate that I take an interest in their business and help them solve business problems, rather than just telling them that rewriting in Rust or whatever will solve everything, which most managers have heard (or tried to do) enough times by now to show some caution.


My experience with our C/C++ devs: they do a wide variety of software. From old Windows programs, Embedded firmware with or without operating system, drivers, or extensive Linux based UI programming.

They are hard to replace, are tough problem solvers and deliver code in our toughest environments.

I think all this data/ai focus is nice, but I think hardware is the real deal breaker. Have an eye on Rust in all the regards.


Do you think Rust will get a leg up on C++ in the near future?


I think Rust will continue to gain more traction, but it has a looooong way to go to catch up to C++. Regardless, if someday all the jobs are in Rust, you can simply learn Rust and you’ll be good to go. Knowledge of the fundamentals is 10x more valuable than knowledge of some particular flavor-of-the-month language.


I've found in every job I've had the best results were from being good at mixing c++ code with other stuff. I know how to work with a lot of languages, but am not really an expert in any of them except C/cpp. Some examples: ios/android apps (objC/java) but the visualization part is cpp. Huge rendering pipelines in Python, with specialized converters and renderers in cpp. Large complicated web thing but it needs to encode video fast, so that part is in a standalone cpp tool. At least half of the job is getting good at knowing what parts to write in cpp and what to write in something else.


I used to be a typical C++ programmer but lately I have mostly been using C/C++ with other languages.

- C as a workaround for a Docker problem.

- C++ with C# in Unity.

- C++ in Android with Kotlin

As you hinted in the question, it is good to combine C++ with other skills.

If you want to stay purely in C++, then the automotive and aeronautical industries are heavy C++ users.

But as @gregjor says its best not to stick to one language. To add to that, I would recommend not to define yourself by the language you program in and instead be prepared to stay flexible and keep learning.


When I’m hiring and get a candidate who seems very focused on a language, or only has experience with one language, I’m probably not going to consider them.

It’s not just the limited skill set. I’ve run into too many programmers who only want to work with the tools they know and like, which limits their usefulness in a team and in the business. Most companies write and use software as a tool to solve business problems, they aren’t all that interested in catering to what programmers think is cool or fun.

I’m all for mastering language and tools, as many as you can, but if you want steady employment keep your eyes on what employers look for.


My 2 cents: anyone selling themselves as an X programmer would immediately lose points as far as I'm concerned if I were hiring. Programming languages are tools. Being a C programmer is like being a hammer woodworker. It makes no sense.


I have seen C++ programmers jump from HFT to image processing to video compression and then to embedded systems.

They were completely different domains.


Depends on your goals to start with.

Regardless of what I think about C, it is undoubtly the king of UNIX/POSIX platforms and embedded development. So that might be an area you feel at home with.

Although C++ has lost the full stack role it once enjoyed with the 90's OS stacks, it is the current king of GPGPU programming (CUDA, Metal Shaders, SYCL and HLSL), HFT, what game engines use at their core.

Finally as many are pointing out, don't silo yourself with one language, most of use many languages at once.

For example using C++ alongside either Java or .NET is quite common.


Thank you. I feel more comfortable with C++ & Python. Somehow Java irritates me!


It's more important to focus on the problem domain than the specific tools. Figure out where you would like to work and the kinds of problems you would like to solve, then evolve your technical skills with them.

C is mostly used these days for embedded systems. C++ for high performance network services. Higher level and more sophisticated languages are coming for those domains, e.g. Rust. Lua is interesting for embedded systems, and the Erlang VM for network services.


Loads. If you're a programmer capable of programming well in C and C++, with a good grasp of algorithms, you'll have no trouble finding software jobs. Many of them will use other languages, but that's no great impediment. You'll have a lot of opportunity to learn them.


Not sure if I’m too late to the party, but if you get into embedded bare metal and RTOS programming you can easily get 10+ years out of C/C++.

FWIW, I am on year 16 of my own C/C++ only career.

EDIT: Huh I’m old


very good, neither of them is going anywhere any time soon...or ever. but it is mostly about what yo uwant to do and learning the language to get you there. c and c++ are the low-level languages so you will be doing low-level stuff. it might be fun or not, depends on you.


I guess in embedded, C is still strong?


You guess right. That’s not the only domain C gets used, though. I think of C as a fundamental skill to build on even if you seldom write C code.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: