It doesn't only depend on the individual involved -- it crucially depends on the specific technology as well as the individual's background; certain technologies, esp. languages, are just harder and slower to get into. I've seen world-class Java gurus with zero previous exposure to C++ take many months, say on the order of six or so, to be fully productive in C++; vice versa (world-class C++ guru with zero previous exposure to Java) I've seen take about 2-3 months; again for extremely experienced and skilled programmers with no previous exposure to dynamic languages, being fully productive in Python can be expected to take 3-4 weeks. In each case I'm talking about 100% full-time involvement in the relevant technology, by a programmer in the world's top one percent in terms of skill and experience, within a team having several other programmers of that caliber who also gurus in the specific language in use.
Factors that can shorten the time are previous exposure to "similar" languages/technologies, e.g. a solid background in C makes C++ slightly faster to learn, solid background in C# helps with Java, solid background in Ruby or Perl helps with Python. Factors that can lengthen the time include lack of suitably experienced teammates, not being 100%-immersed in the "new thing", and psychological resistance (not really wanting to do it with all one's heart!-).
I've focused on programming languages for my examples, but some technologies can be even harder, i.e., take longer to master -- if you've never written embedded real-hard-time programs (no dynamic allocation of memory allowed, proofs of upper bound on response time required of all function) even six months might not suffice; some application areas require mastery of application domains that, all on their own, can take even longer (if to understand at all what's going on, and therefore be fully productive, you need the equivalent of a BSc in Psychology, or deep knowledge of the Law, or a CPA's qualifications, etc, well, each of those takes years on its own!).
I don't think the language as such is the issue, rather the programming paradigm it encompasses.
e.g. earlier this year I tried C#, coming from a Java perspective. That was all very straightforward. However, I'm now trying Scala. Because of the functional aspect, I expect to be learning and honing my skills for a lot longer (you can write Scala in an imperative fashion, but you don't leverage its strengths doing that).
I suspect the same would apply when (say) migrating from a relational database to an OO database, vs. a MS-SQL/Oracle migration.
It does depend, mainly on how closely the language resembles a language they already know, as well as individual abilities at picking up new things. Moving between similar languages like C++, Java, and C# is very easy. Similarly, moving from (say) Win32 to MFC to .net is going to be easier than from MFC to MacOS.
Moving from C to C++ is likely to take longer, as the programmer has to learn OO methodologies. Moving from C++ to Perl or ML could take a lot longer!
However, you usually don't need to know much to get started. Moving from C++ to C# can be done in a few hours reading (on the main differences) and then you can start writing (or modifying existing) code. That's because (a) you already know how to do OO programming, and (b) 95% of the syntax is identical.
But the main thing it depends on is your definition of "proficient". With similar languages, you will be able to write good code within a few days (an algorithm is usually failry language independent), but it usually takes months or years to become truly "proficient" in a language or large library.
So I'd say as a rule of thumb, "up to (a reasonable) speed" in a few weeks, but you might see silly "mistakes" or inefficiencies in their code for months/years until they learn all the little tricks of the language.
In the case of people learning OO, usually it seems to take a few days to get the basic concepts, and then at about the 2 year mark, a moment of epiphany occurs where the programmer suddenly relises that they truly "get" it. (I guess this is when your brain starts thinking fluently in OO rather than trying to think procedurally and then translate that into an OO aproach)
In our environment (US health care revenue cycle) it is more than just learning and becoming proficient in the language or technology stack we use to deliver our solutions to our customers. The developer also has to understand the problem domain. We work with entities that often don't document the behaviors of their systems well-enough for external entities (us) to communicate with to get the data that our customers we want. Our developers are forced to think beyond the specs to build a functioning system.
There is also the inevitable "It doesn't work; fix it" problem report from the customer support staff. Frequently the problem isn't a defect in our software; it is an issue with other entities with which our software communicates. Our developers have to be able to identify (and sometimes prove) that it isn't our software so that our business analyst-types can go to that other entity and explain the issue in a way that will get them to resolve the problem.
You were expecting this answer but it all depends on the person/programmer. I have been in a situation where two equally skilled programmers had to pick up something new, one got it right away, while the other one took some time. Previous exposures to other technologies are also a factor.
Personally, in regard to something new, I budget my time to learning everything about it every chance I get. It would take about 6 months to fully be comfortable.
学习是渐进的。一个人可以终生继续学习 C++ 语法等细节。当一个人成为某一主题的“专家”时，这只意味着在该主题上学习更多知识所带来的收益越来越小。
I am talking about something fairly substantial, like a language, or a framework / product that has a lot of ways of doing things. Obviously, many libraries takes very little time to start using.
When you hire somebody new (but experienced) to the team, and they don't have expertise in technology you are using, but know something similar, how much time do you budget for them to "get online."
Twenty-three work days, six hours, forty-three minutes, and seventeen point nine seconds.
What do you do in your projects? How do you budget the time to account for learning.
I think these questions are better!
Try to find an easy project in the new technology, and have them do that. If possible, have the person start by fixing bugs, then adding small features.
Learning is incremental. One can continue learning details of, say, C++ syntax throughout one's life. When one is an "expert" in a topic, it just means that the gains from learning more in that topic are growing smaller.
the attitude and capabilities of the person learning it
is the problem area programming/paradigm well understood by that person
the similarity of the new technology / language to other technologies he/she does know
the consistency of the new technology / language in its interface (API, grammar, etc...)
what is proficient (knowing just the language, or als the basic library, or also runtime behaviour (interactions with underlying technology))
Having said that, in my experience a smart person learning a new language/technology will quickly be more productive than other people with more experience in that language/technology.
It so completely depends on whether you already know languages that are similar to the new one, and know something about the problem domain the new language is suited for. I'd say don't expect to be reasonably proficient in less than 3-6 months, but again, it depends.
To take one example I implemented a PHP/MySQL web application a couple years ago (total effort was about 6 months). It was my first reasonably large web application, and my first PHP ever. I've used relational databases, but this was also my first exposure to MySQL. MySQL came very quickly, as expected, since it's really only a dialect of a language I knew well. What surprised me was that PHP also came quickly. I realized that not only did it borrow ideas from PERL and C/C++, but the whole paradigm of coding with integrated SQL statements strongly drew on some experience I had in the 90's with, of all things, Informix 4GL.
At the other end of the spectrum, I've never really learned a functional language, so I'm trying to pick up Scala. This is going to take substantially longer, and there'll be a long period where my Scala will feel like Java in disguise, and not be that functional.
You also run the risk that if the person knows one technology/paradigm, they will code in the new language/technology using the old practices/paradigms.
For example, I picked up Python really fast (I'm a Java/C++ guy), but it took a long time since I stopped writing Java style code in Python and started thinking functionally.
To get really good, I think there's no replacement for experience. For instance, I'm sure I can easily pick up J2EE, but the experience to built up the best enterprise systems is not something you can pick up that fast.
发布评论
评论（9）
这不仅取决于所涉及的个人——更关键的是取决于具体的技术以及个人的背景；某些技术，特别是。语言，只是更难、更慢。我见过一些以前接触过 C++ 的世界级 Java 专家需要花费数月（比如大约六个月）的时间才能在 C++ 中充分发挥生产力；反之亦然（世界级 C++ 大师，之前接触过 Java 为零），我见过大约需要 2-3 个月；同样，对于以前从未接触过动态语言的经验丰富、技术精湛的程序员来说，完全高效地使用 Python 预计需要 3-4 周的时间。在每种情况下，我谈论的是 100% 全职参与相关技术，由一位在技能和经验方面处于世界前 1% 的程序员，在一个团队中拥有其他几位具有相同能力的程序员，他们也是该领域的专家。使用的特定语言。
可以缩短时间的因素是之前接触过“类似”语言/技术，例如，扎实的 C 背景使 C++ 的学习速度稍快一些，扎实的 C# 背景有助于学习 Java，扎实的 Ruby 或 Perl 背景有助于学习 Python。导致时间延长的因素包括缺乏经验丰富的队友、没有100%沉浸在“新事物”中、心理抗拒（不是真的想要全心全意去做！-） 。
我在示例中重点关注编程语言，但有些技术可能更难，即需要更长的时间才能掌握 - 如果您从未编写过嵌入式实时程序（不允许动态分配内存，所有功能所需的响应时间的上限）即使六个月也可能不够；一些应用领域需要掌握应用领域，而这些应用领域本身可能需要更长的时间（如果要完全理解正在发生的事情，从而充分发挥生产力，您需要相当于心理学学士学位，或者对心理学有深入的了解）法律，或注册会计师资格等，好吧，每一个都需要数年时间！）。
It doesn't only depend on the individual involved -- it crucially depends on the specific technology as well as the individual's background; certain technologies, esp. languages, are just harder and slower to get into. I've seen world-class Java gurus with zero previous exposure to C++ take many months, say on the order of six or so, to be fully productive in C++; vice versa (world-class C++ guru with zero previous exposure to Java) I've seen take about 2-3 months; again for extremely experienced and skilled programmers with no previous exposure to dynamic languages, being fully productive in Python can be expected to take 3-4 weeks. In each case I'm talking about 100% full-time involvement in the relevant technology, by a programmer in the world's top one percent in terms of skill and experience, within a team having several other programmers of that caliber who also gurus in the specific language in use.
Factors that can shorten the time are previous exposure to "similar" languages/technologies, e.g. a solid background in C makes C++ slightly faster to learn, solid background in C# helps with Java, solid background in Ruby or Perl helps with Python. Factors that can lengthen the time include lack of suitably experienced teammates, not being 100%-immersed in the "new thing", and psychological resistance (not really wanting to do it with all one's heart!-).
I've focused on programming languages for my examples, but some technologies can be even harder, i.e., take longer to master -- if you've never written embedded real-hard-time programs (no dynamic allocation of memory allowed, proofs of upper bound on response time required of all function) even six months might not suffice; some application areas require mastery of application domains that, all on their own, can take even longer (if to understand at all what's going on, and therefore be fully productive, you need the equivalent of a BSc in Psychology, or deep knowledge of the Law, or a CPA's qualifications, etc, well, each of those takes years on its own!).
我不认为语言本身是问题，而是它所包含的编程范式才是问题所在。
例如，今年早些时候，我从 Java 的角度尝试了 C#。这一切都非常简单。不过，我现在正在尝试 Scala。由于功能方面的原因，我希望能够更长时间地学习和磨练我的技能（您可以以命令式方式编写 Scala，但这样做并不能利用它的优势）。
我怀疑当（比如说）从关系数据库迁移到 OO 数据库时，与 MS-SQL/Oracle 迁移相比，同样的情况也适用。
I don't think the language as such is the issue, rather the programming paradigm it encompasses.
e.g. earlier this year I tried C#, coming from a Java perspective. That was all very straightforward. However, I'm now trying Scala. Because of the functional aspect, I expect to be learning and honing my skills for a lot longer (you can write Scala in an imperative fashion, but you don't leverage its strengths doing that).
I suspect the same would apply when (say) migrating from a relational database to an OO database, vs. a MS-SQL/Oracle migration.
这确实主要取决于该语言与他们已经知道的语言的相似程度，以及个人学习新事物的能力。在 C++、Java 和 C# 等类似语言之间切换非常容易。同样，从（例如）Win32 迁移到 MFC 再到 .net 将比从 MFC 迁移到 MacOS 更容易。
从 C 迁移到 C++ 可能需要更长的时间，因为程序员必须学习 OO 方法。从 C++ 迁移到 Perl 或 ML 可能需要更长的时间！
但是，您通常不需要了解太多就可以开始。从 C++ 迁移到 C# 可以在几个小时内完成阅读（主要差异），然后您可以开始编写（或修改现有）代码。这是因为 (a) 您已经知道如何进行 OO 编程，并且 (b) 95% 的语法是相同的。
但主要取决于你对“熟练”的定义。使用类似的语言，您将能够在几天内编写出好的代码（算法通常与失败的语言无关），但通常需要数月或数年才能真正“精通”一种语言或大型库。
因此，我想说，根据经验，几周内“达到（合理的）速度”，但是您可能会在数月/数年的时间里看到他们的代码中愚蠢的“错误”或效率低下，直到他们学会了所有的小技巧语言。
对于学习面向对象的人来说，通常似乎需要几天的时间才能掌握基本概念，然后在大约两年的时间里，程序员突然意识到他们真正“掌握”了它，突然顿悟了。 （我猜这是当你的大脑开始在面向对象中流畅思考时，而不是尝试按程序思考，然后将其转化为面向对象方法）
It does depend, mainly on how closely the language resembles a language they already know, as well as individual abilities at picking up new things. Moving between similar languages like C++, Java, and C# is very easy. Similarly, moving from (say) Win32 to MFC to .net is going to be easier than from MFC to MacOS.
Moving from C to C++ is likely to take longer, as the programmer has to learn OO methodologies. Moving from C++ to Perl or ML could take a lot longer!
However, you usually don't need to know much to get started. Moving from C++ to C# can be done in a few hours reading (on the main differences) and then you can start writing (or modifying existing) code. That's because (a) you already know how to do OO programming, and (b) 95% of the syntax is identical.
But the main thing it depends on is your definition of "proficient". With similar languages, you will be able to write good code within a few days (an algorithm is usually failry language independent), but it usually takes months or years to become truly "proficient" in a language or large library.
So I'd say as a rule of thumb, "up to (a reasonable) speed" in a few weeks, but you might see silly "mistakes" or inefficiencies in their code for months/years until they learn all the little tricks of the language.
In the case of people learning OO, usually it seems to take a few days to get the basic concepts, and then at about the 2 year mark, a moment of epiphany occurs where the programmer suddenly relises that they truly "get" it. (I guess this is when your brain starts thinking fluently in OO rather than trying to think procedurally and then translate that into an OO aproach)
在我们的环境（美国医疗保健收入周期）中，这不仅仅是学习并精通我们用来向客户提供解决方案的语言或技术堆栈。开发人员还必须了解问题领域。我们与一些实体合作，这些实体通常无法很好地记录其系统的行为，以便外部实体（我们）与之通信以获取我们的客户想要的数据。我们的开发人员被迫超越规范来思考，以构建一个功能正常的系统。
还有来自客户支持人员的不可避免的“它不起作用；修复它”的问题报告。通常，问题并不是我们软件的缺陷；而是我们软件的缺陷。这是与我们的软件通信的其他实体的问题。我们的开发人员必须能够识别（有时证明）这不是我们的软件，以便我们的业务分析师类型可以找到其他实体并以一种能够让他们解决问题的方式解释问题。
In our environment (US health care revenue cycle) it is more than just learning and becoming proficient in the language or technology stack we use to deliver our solutions to our customers. The developer also has to understand the problem domain. We work with entities that often don't document the behaviors of their systems well-enough for external entities (us) to communicate with to get the data that our customers we want. Our developers are forced to think beyond the specs to build a functioning system.
There is also the inevitable "It doesn't work; fix it" problem report from the customer support staff. Frequently the problem isn't a defect in our software; it is an issue with other entities with which our software communicates. Our developers have to be able to identify (and sometimes prove) that it isn't our software so that our business analyst-types can go to that other entity and explain the issue in a way that will get them to resolve the problem.
您期待这个答案，但这完全取决于人/程序员。我曾经遇到过这样一种情况：两名同样熟练的程序员必须学习一些新东西，其中一个立即就掌握了，而另一个则花了一些时间。以前接触过其他技术也是一个因素。
就我个人而言，对于新事物，我会利用一有机会就花时间学习所有内容。大约需要6个月的时间才能完全适应。
希望这有帮助。
You were expecting this answer but it all depends on the person/programmer. I have been in a situation where two equally skilled programmers had to pick up something new, one got it right away, while the other one took some time. Previous exposures to other technologies are also a factor.
Personally, in regard to something new, I budget my time to learning everything about it every chance I get. It would take about 6 months to fully be comfortable.
Hope this helps.
二十三个工作日，六小时四十三分十七点九秒。
我觉得这些问题问得比较好！
尝试在新技术中找到一个简单的项目，然后让他们这样做。如果可能的话，让该人从修复错误开始，然后添加小功能。
学习是渐进的。一个人可以终生继续学习 C++ 语法等细节。当一个人成为某一主题的“专家”时，这只意味着在该主题上学习更多知识所带来的收益越来越小。
Twenty-three work days, six hours, forty-three minutes, and seventeen point nine seconds.
I think these questions are better!
Try to find an easy project in the new technology, and have them do that. If possible, have the person start by fixing bugs, then adding small features.
Learning is incremental. One can continue learning details of, say, C++ syntax throughout one's life. When one is an "expert" in a topic, it just means that the gains from learning more in that topic are growing smaller.
+1，这取决于情况。
这取决于
话虽如此，根据我的经验，聪明人学习一门新语言/技术很快就会比其他在该语言/技术方面拥有更多经验的人更有效率。
+1 for it depends.
It depends on such things as
Having said that, in my experience a smart person learning a new language/technology will quickly be more productive than other people with more experience in that language/technology.
请参阅 Peter Norvig 的 十年内自学编程，了解需要多长时间才能完成编程的相关问题精通编程。
这完全取决于您是否已经了解与新语言类似的语言，并且了解新语言适合的问题领域。我想说的是，不要指望在不到 3-6 个月的时间内就能相当熟练，但同样，这取决于情况。
举一个例子，我几年前实现了一个 PHP/MySQL Web 应用程序（总工作量约为 6 个月）。这是我的第一个相当大的 Web 应用程序，也是我的第一个 PHP。我使用过关系数据库，但这也是我第一次接触MySQL。正如预期的那样，MySQL 来得很快，因为它实际上只是我熟悉的语言的一种方言。让我惊讶的是PHP也来得很快。我意识到它不仅借鉴了 PERL 和 C/C++ 的思想，而且使用集成 SQL 语句进行编码的整个范例强烈地借鉴了我在 90 年代使用 Informix 4GL 的一些经验。
另一方面，我从未真正学过函数式语言，所以我正在尝试学习 Scala。这将需要更长的时间，并且在很长一段时间内我的 Scala 会感觉像是伪装的 Java，并且没有那么实用。
所以……这要看情况！ ;-)
See Peter Norvig's Teach Yourself Programming in Ten Years for the related question of how long does it take to become proficient in programming.
It so completely depends on whether you already know languages that are similar to the new one, and know something about the problem domain the new language is suited for. I'd say don't expect to be reasonably proficient in less than 3-6 months, but again, it depends.
To take one example I implemented a PHP/MySQL web application a couple years ago (total effort was about 6 months). It was my first reasonably large web application, and my first PHP ever. I've used relational databases, but this was also my first exposure to MySQL. MySQL came very quickly, as expected, since it's really only a dialect of a language I knew well. What surprised me was that PHP also came quickly. I realized that not only did it borrow ideas from PERL and C/C++, but the whole paradigm of coding with integrated SQL statements strongly drew on some experience I had in the 90's with, of all things, Informix 4GL.
At the other end of the spectrum, I've never really learned a functional language, so I'm trying to pick up Scala. This is going to take substantially longer, and there'll be a long period where my Scala will feel like Java in disguise, and not be that functional.
So ... it depends! ;-)
我同意这取决于情况。
您还面临这样的风险：如果该人了解一种技术/范式，他们将使用旧的实践/范式以新的语言/技术进行编码。
例如，我很快就学会了 Python（我是一个 Java/C++ 人），但自从我停止用 Python 编写 Java 风格的代码并开始进行函数式思考以来，我花了很长时间。
为了真正变得优秀，我认为经验是无可替代的。例如，我确信我可以轻松掌握 J2EE，但是构建最好的企业系统的经验并不是您可以那么快掌握的。
I agree that it depends.
You also run the risk that if the person knows one technology/paradigm, they will code in the new language/technology using the old practices/paradigms.
For example, I picked up Python really fast (I'm a Java/C++ guy), but it took a long time since I stopped writing Java style code in Python and started thinking functionally.
To get really good, I think there's no replacement for experience. For instance, I'm sure I can easily pick up J2EE, but the experience to built up the best enterprise systems is not something you can pick up that fast.