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)
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)
16 comments
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.”
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.
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.
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.
PS: David Packard's address to Managers might be relevant here - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...
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 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.
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.
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
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.
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.
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.
Programmers who can solve problems, add value, and work with other people will always be in demand.
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.
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.
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.
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.
- 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.
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.
They were completely different domains.
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.
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.
FWIW, I am on year 16 of my own C/C++ only career.
EDIT: Huh I’m old