Ask HN: Switch career if I'm not a polyglot?
In job posting I see polyglot thrown around a lot with pride - companies will have an infrastructure comprising of 6 or more languages and they want someone senior who knows all of them - and i'm only 1/6th of that.
It took me a long time to get the nuances of my favorite language down (go). I'm OK with dabbling in others, but it takes me a decent amount of time (months/years) to pickup and be actually fluent in a language - there's almost no way i can juggle more than a few. There's only so much room in my head. I can't even get the nuances of English down.
Should I look into another career? I'm wondering if i'm not cut out for being a developer. Jobs seem to want polyglots (they'll say: "you are a polyglot") and that's not an option (or even an interest) for me.
27 comments
[ 0.26 ms ] story [ 79.7 ms ] threadIn general what I am seeing is they are looking for people who are not tied to one thing. I worked with a guy before, anything you asked the answer was 'Oh I can do that in Cold Fusion'. Another guy 'SQL is the answer'. To be fair, myself I favor C# as it is the most recent language I have done a lot of work in. But I am skilled in SQL, and Cold Fusion, as sell as SharePoint, JS, HTML, LISP and a few others. The important this is to be open to the other possibilities. Sometimes C# is the answer, but usually something else will work better, but you have to consider maintainability.
The other thing a polyglot shows is you are learning diversity. Not stuck in what you learned 20 years ago at University.
For most jobs they have 3 maybe as many as 5 real needs, but usually it is 3. You need to identify those and talk to how you match their NEEDS. Then look at the others and see how you can talk around them.
<story> A number of years ago I was working for a company and we were going to hire another devloper to work with me. My boss created a job posting, without vetting it through me. I was surprised to see the list of langauages. C / C++ / C# / JS / Java / Ada / Assembly (2 specific versions), I think there were a couple more languages listed. These were all 'REQUIRED SKILLS'. I asked my boss why she did this, since no one in the company knew all those languages (I knew 5 of them, but I was an oddity, most only knew 2) and we only used 4 of those (C, ada and the 2 assembly languages). Her answer was 'Would it not be cool if we had someone who did?'. My answer was they either knew very little about each or were a compulsive liar. Most likely the compulsive liar. </story>
so if you know go very well, you could read code written in something different, I think you can learn a lot from reading code in an entirely different paradigm, so for instance, you could read a program written in Lisp, or Assembly, or Prolog, just as a learning exercise, you don't have to become an expert
for example, why do people program physics engines in C/C++, but do GUI in Java or Python? because each language has its strengths (in this example, performance for the engine, simplicity and expressive power for GUI)
why do languages like Prolog exist? because they are useful for things like AI or reasearch
now, because a lot of languages sort of inherit from the C language, learning C is a good way to make it easier to get used to the syntax of those languages, because it's going to be fairly similar to C, Go itself inherits a lot from C as I understand it
You have said that you know the nuances of Go, and with that you probably have touched the outside world like databases, caching, HTTP, TLS. And I think this is much more worthy to grasp the overall concepts from end to end and knowing how to integrate your parts you have done in Go into the rest of the infrastructure.
Of course it is always good to dabble around in other languages and reuse insights across different languages, but having a good understanding across the infrastructure stack is in my opinion more helpful.
They want someone who explores a bit, checking out what other languages offer, so that he's not always reaching for the same thing to solve every problem, regardless of how appropriate it is.
It's like a carpenter who has his go-to tools, but at least knows when a scroll saw is more appropriate to the task than a circular saw.
Most polyglots are only really strong in two or three languages at a time. They may be passable in a few others, but they only remember bits and pieces of most of the languages they've worked with. They only have so much space in their head, just like you; the difference is in how they manage it. They organize their headspace differently, and there are upsides and downsides to that.
There are four main skills to being a polyglot. The first is knowing how to separate programming from coding. Your first language is always the hardest, because you're actually learning two things at once: you're learning the mindset and methods to create programs, and you're learning how to write down what you create in a particular language. When you go to relearn your second language, you don't have to relearn programming: you already know how to do that. This makes your second language, and later languages, easier than the first.
The second skill is understanding when and how it's okay to forget. There is only so much space in your head, and you forget things you aren't using. You mention this as a problem, but polyglots are no different. The trick is that almost every programming language was created because its author thought something was too difficult in the lanuages of the time, and wanted to program that thing in a way that flowed more naturally in the way they thought about it. These are the areas where you want to focus your attention: learn them as thoroughly as you can, and incorporate the concepts behind them into your general knowledge of how to program. The rest can be forgotten unless you're using the language often.
The third skill is how to draw connections between languages. As you learn new languages, focus on figuring out how to do the things you already know how to do in other languages. This will help you learn them faster, and relearn them faster (because you're going to have to relearn things you've forgotten sometimes). There's a book called "Seven Languages in Seven Weeks" which is good practice for this: you will not become an expert in any of the seven, but that's not the point. The real goal of the book is to teach you how to evaluate a new language and break it into parts that are easier to understand.
The last big skill is getting help. A polyglot is never going to have the same depth of knowledge in a language's libraries as a single-language expert will, so you need to know where to go when you don't know something. The official documentation is good. Other people are better, but not always available. You need to be able to have a sense of what you're looking for, where to get that information, and how to get it from there. You get faster at this with time.
That's most of it, really. And note that last paragraph: it's important to rememver that "polyglot" doesn't just mean "awesome". Polyglots get the job done and they look good doing it, but there's a price to pay for that. A single-language expert may or may not produce code that's any better than a very careful polyglot's. But the polyglot will take longer -sometimes much longer- to produce the same code, due to the overhead of relearning. This makes experts great, when you can find an expert that can do what you need. But sometimes, especially when your needs are very specific or demanding or the language you want to use is very new, it's not feasible to find an expert. That's where the polyglot shines: if you can't find an expert able to do what you need, the polyglot will become able to do what you need. Experts sculpt the language; polyglots sculpt themselves.
You're worried about whether or not you're cut out for this career, but I think you can succeed. If y...
Point is, having a few tools in the toolbox is great. Knowing when to use each tool is priceless. Having a lot of tools in the toolbox, but not knowing how to use them effectively is the sign of a poor crastman.
Have a few tools, and know them well. That's not to say dont explore and learn, of course do that, but maintain your primary focus on your core skills and dont ignore improving those, either.
b) in the vast majority of cases, I suspect companies using 6 languages don't have everyone working regularly in all 6, but being able to read or do small tweaks to code in all of them is useful. I don't recall really seeing job postings requesting advanced knowledge in many languages, it's more typically to have one or two and then "nice to have" of further ones.
For instance, since you know Go, learning Java should be pretty easy since they have very similar semantics since they are both garbage collected languages used primarily for writing server side programs.
1. I spent nine years at a company where I did some VB, lots of C and C++, Perl, Java, Object Rexx, Classic ASP, a little JavaScript, some C#, and worked with MySQL and SQL Server. I had become a jack of all trades but a master of none. I guess I was a "polyglot programmer". But while my skillset may have been valuable to the company I was working for, it wasn't valuable to the overall market. They wanted someone with a deep knowledge of either Java, C#, or to a lesser C++. My suggestion is to avoid jobs where they want a "polyglot programmer" especially early in your career and focus on working somewhere where you can get experience in one or two related things.
2. I have no opinion on the technical merits of Go, but if you want to tie your horse to a language, why tie it to a language where there is not as much demand? In my market, there are plenty of jobs for C#, Java, and Javascript and the jobs that want PHP and Python developers pay much less. Guess which languages I focused on after leaving the job I had for nine years.
I am not a polyglot developer (I don't think) but I do try to know at least one language/framework/technology down the whole stack. For me that's JavaScript, C#, most major RDMSs and Mongo, and AWS for netops and devops and a dabble with Python for scripting.
I would ask them to clarify the statement "knows all of them." If they simply mean "had exposure to them" I could maybe see that, although 6 sounds high even given that.
If a company says that a candidate must be "proficient" in all 6 languages present in their entire infrastructure I would take that as a "red flag" and not bother applying.
If you're applying to a company that expects you to know 6 languages, I posit that you're applying to the wrong companies. Find somewhere sane to work. If you're focused on the SV startup scene, maybe broaden your horizons a bit.
I hold very serious concerns about any project that requires the use of 6+ languages. Even in an enterprise setting with lots of legacy systems, I would expect different people to be competent with subsets of all the languages in use.
Go is an excellent language with a rapidly growing ecosystem. It might be a good strategy for you to be known as the Go expert instead of a jack of all languages who is not an expert in any of them. Besides it is not the language, it is the libraries, the tools and the ecosystem that takes a lot of effort to be competent with.
- syntax familiarity. This should come to fluency in a few weeks of daily usage (or more for languages with very unique syntax in comparison to what you're familiar with). You'll find yourself discovering new ways to use a syntax expressively or leverage the syntax for correctness for the rest of your career.
- common libraries and idiomatic patterns. This will take years, but is more linear than front-loaded like syntax. There's always a new pattern or library. My guess is you're judging yourself on this aspect. Don't. Everyone goes at the same pace on this metric.
- infrastructure. How does it build, how to configure the runtime, when does it blow up or exhaust threads or do random things like spin the CPU for no damned reason or deoptimize a function. No person can be an expert at a language without a solid grasp on these features of a language implementation. You don't go "deep" on a language without it. You should have two or three of these after ten years unless you're weird and like it. But if you're a 10 year dev without one, quit.
More to your question: I expect senior backend/fullstack devs to be experts at at least one language, at least one RDBMS, and at least one extra tech like elasticsearch, mongo, redis, etc. Without that, you'll just get paid less. If you're not expecting to be called a senior developer, then you shouldn't be expected to be deep in any technology. If you're having trouble getting shallow on new technologies, however, yeah you should probably quit.
OP, ignore stuff like this. "Expert" at a language is an extremely high bar, and not very important. Workplaces that focus on language expertise (and other narrow skills like "mongo") tend to not be great places to work. By definition the leadership at such places clearly doesn't understand what's actually important. These are the places where management obsesses over ludicrous metrics and where the worst whiteboard interviews (with questions about obscure language features) are conducted.
There are places where you're seen as a person rather than a bucket of buzzwords. Such jobs value your general intelligence and emotional intelligence a lot more than # years in language X. There's room for you to bring all kinds of skills and expertise to the table and you don't have to worry about fitting some mold.
The real measure of success at such places is getting stuff done, and that's done at the team level. A team doesn't have to be N "experts" at language X and trendy technology "Y".
This discussion reminds me of those about "intelligence" and IQ. Many people believe intelligence is a single measurable metric, when in fact it's a constellation of many kinds of aptitudes.
Being a senior coder is about a lot more than language expertise.
I've noticed my design skills go up drastically the more I learn about a language.
For example in most PHP frameworks there's a service container you bind your services into. In RoR that does not exist.
Using asyc/await vs promises makes very different design decisions in js and if you know only one you may not design something optimally.
I could go on. But my point is that lang expertise gives you the knowledge to design things better, and reduces your chances of putting out a quick hack because you know how to do things properly and rapidly due to you expertise.
Optimally? How would you even define that? Good developers make good use of the tools that are laid out before them, and sure the available tools differ in each language. But: 1. These languages tend to have more in common than they do different. 2. These concepts aren't magic. They're relatively easily understood, and you can make good use of them long before you can call yourself an expert in the language. 3. A good design doesn't necessarily make use of any specific language feature. e.g. a Go library might be well designed and make use of mutex (a very generic and ubiquitous concept). It's not a "quick hack" just because the author didn't choose to use channels.
That's all I'm saying and it may be anecdotal but it's been my experience in the industry.
Do you think that if you came across a developer who's been doing JavaScript for 10 years and didn't know bind, call, and apply, or a 10 year Java developer who didn't know how to set max heap size, that that person is likely to be smart or get stuff done?
I've come across them. I've hired them. They're people who habitually blame others and dont move cards.
I do a lot more Devops type work now and the knowledge of how different languages run comes in handy. Realistically though, that much Go experience should lend you to plenty of opportunities. At the same time, it never hurts to branch out.
One of the great things about going deep with a single language before learning others is that you know how to experiment and push things. You know more about what to look for than a brand new programmer that decides to learn 1 language a month at a surface level. It’s a benefit, not a hindrance.
Don’t bite off 6 at a time, but definitely find something else and learn it just to broaden yourself.