5 ms·

There are three main aspects to learning a new language - syntax familiarity. This should come to fluency in a few weeks of daily usage (or more for languages

There are three main aspects to learning a new language - 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.

solipsism 8y ago
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. 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".
- nickthemagicman 8y ago
  I feel like experts 'get things done' with less tech debt though and are therefore more beneficial to have on a project.
  - solipsism 8y ago
    I don't agree at all. Being a language "expert" doesn't mean you know when to write tests and what kinds of tests to write (which is mostly a language neutral skill). It doesn't mean you know how to choose between a quick hack and a well thought out design (and again, language expertise is not the most important ingredient to producing a good design). 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.
    - nickthemagicman 8y ago
      Hm. I feel like there's a correlation between knowledge of a language and being able to design well with the language. 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.
      - solipsism 8y ago
        Using asyc/await vs promises makes very different design decisions in js and if you know only one you may not design something optimally 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.

solipsism 8y ago

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

nickthemagicman 8y ago
I feel like experts 'get things done' with less tech debt though and are therefore more beneficial to have on a project.
- solipsism 8y ago
  I don't agree at all. Being a language "expert" doesn't mean you know when to write tests and what kinds of tests to write (which is mostly a language neutral skill). It doesn't mean you know how to choose between a quick hack and a well thought out design (and again, language expertise is not the most important ingredient to producing a good design). 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.
  - nickthemagicman 8y ago
    Hm. I feel like there's a correlation between knowledge of a language and being able to design well with the language. 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.
    - solipsism 8y ago
      Using asyc/await vs promises makes very different design decisions in js and if you know only one you may not design something optimally 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.