Answers.Body: <p>I will have to disagree with Buffy that the pair programing is a bad idea in your case. As a matter of fact I think the pair programing is a bad idea in general and I never see it work in real situation but that is another big topic.</p>
  <p>My suggestion is to let them <strong>update/write</strong> the team's technical document, be it high level design documents, technical spec or even good/up-to-date code comments. If you are those &quot;agile teams&quot; that we don't really have a decent document then let them make one.</p>
  <p>I believe the document is always a technical debt for any fast moving team. Let the newcomers update/write technical documents to explain how the system works, how a piece of codes work, make the existing document up to date.</p>
  <p>To write a good document they need to get their hands dirty, consult with the old guys etc to understand how things work. Writing a good document that people actually will read and refer to is also a challenge to the newcomer and benefit the whole team in the end.</p>
  <p>This article <a href="https://evanlimanto.github.io/2019/10/06/so-youre-a-new-grad-software-engineer.html" rel="nofollow noreferrer">So You're A New Grad Software Engineer</a> resonates with me.</p>
  <p>Another answer mentioned test driven development, which I am not so sure about either. Of course test drive development is another big topic like pair programming. Personally I tend to  agree with the points <a href="https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d" rel="nofollow noreferrer">Test-Driven Development is Fundamentally Wrong</a> made, writing tests afterward (not beforehand) makes much more sense. &quot;Were I to follow the TDD architecture I would have to constantly revisit my tests, review all of them, revising them to match my discoveries.&quot; because there will be always things that I didn’t think of until I really implement them and &quot;Because the same blind spots that I had in design will appear in my tests.&quot;</p>
  <p>I don't mean to provide an answer just to argue/disagree the existing answers. One of reasons I answer the question is that I would like to know 4 years later, when looking back, does the pair programming/test drive development really help you bring up the newcomers? (if the OP would answer it) If yes it will also change (a little bit) my attitude towards pair programming and test-driven development.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-13T18:56:43.013Z
Answers.Text: Actually, I've seen pairing work for a major project on a major product at a major international company whose name you would instantly recognize.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-13T18:59:01.303Z
Answers.Text: WRT TDD, you don't just _write_ the tests and run them one at a time. You repeatedly run them all as a suite so that any error anywhere shows up as a test failure that points you to the error. So, you don't "revisit" the tests until you see a failure. But when you do, you know you have an inconsistency between spec and program.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-14T01:48:58.277Z
Answers.Text: That actually may illustrate my point here,  it takes 2 highly experienced engineers to make pair programming work (if it does work), which may not be the case here.
Answers.UserDisplayName: Qiulang 邱朗
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-14T01:50:57.060Z
Answers.Text: About TDD I am against writing test before implementation as I answered in another question.
Answers.UserDisplayName: Qiulang 邱朗
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-20T08:36:19.610Z
Answers.Text: The context of your answer is that all ideology ultimately backfires. That much I can agree with. Hence +1. However your *concrete* suggestion amounts to postponing **writing code.** Programmers are hired to write code. At some point the sleeves need to roll up.  When?... Remains a question. BTW Jordan Peterson is eloquent in his take against ideology. As is Dijkstra. But both in the end give their own!!! Practice-what-you-preach is *hard!*
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-20T08:48:25.310Z
Answers.Text: When will you let a new guy start to contribute to the code base is basically the team leaders' judgement call. BTW, what is the story of Jordan Peterson  (who is this guy in the first place) ?
Answers.UserDisplayName: Qiulang 邱朗
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-21T09:54:26.363Z
Answers.Text: One of the first that comes up if u search "Jordan Peterson+ideology" https://www.youtube.com/watch?v=sJo5WxqpgmQ. Its critical of JP but otherwise an ok summary
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-12T10:29:41.523Z
Answers.LastActivityDate: 2022-10-12T11:46:39.350Z
Answers.LastEditDate: 2022-10-12T11:46:39.350Z
Answers.UserDisplayName: Qiulang 邱朗
Answers.Body: <p>In places that use the ideas of agile software development, the usual way is to just let the newcomers pair with the more experienced members in all tasks. In your case it would consist of a lot of pair programming. But you would need to do it correctly. It isn't one person programming and the other person watching. Both participate, but in different ways. See <a href="https://rads.stackoverflow.com/amzn/click/0201745763" rel="noreferrer">Pair Programming Illuminated</a> for a specific description or <a href="https://rads.stackoverflow.com/amzn/click/0321278658" rel="noreferrer">Extreme Programming Explained</a> for a more complete description of the whole process. </p>
  
  <p>The experience of agile shops is that pairs produce about as much as people working individually (there is research to that effect) but with higher quality. (Specifically, the hypothesis that individuals produce more in total is not supported). </p>
  
  <p>But more so, the newcomer is immediately introduced to the local process in an active way and can start to be productive much sooner. However, the experienced member of the pair will need to turn the keyboard over to the novice frequently (roles switch every several minutes, not hours), and both will need to learn to adopt to the individual roles of "driver" and "navigator". </p>
  
  <p>Pairing combined with faithful use of test first development is especially productive of high quality software, but you need to actually practice the skills, not just talk about them. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-13T15:07:46.683Z
Answers.Text: This seems like a fun and constructive way of working / learning, thank you!
Answers.UserDisplayName: phagio
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-15T09:26:48.640Z
Answers.Text: Pair programming takes about 2 weeks to get up to speed, before that it is slower. However I have done pair programming with a pier on very difficult tasks, and we were more effective almost immediately. I suspect that for the OP they will be slower for the first 2 weeks, but because of training value, it will pay have positive value immediately. (note: Pair programming would have been my answer. But Buffy did it first and better.)
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-13T14:39:38.750Z
Answers.LastActivityDate: 2018-08-13T14:39:38.750Z
Answers.UserDisplayName: Buffy
Answers.Body: <p>As well as pair programming, look at other agile/lean techniques.</p>
  
  <ul>
  <li>Test Driven Development.</li>
  <li>What does done look like? / definition of done (scrum).</li>
  <li>Short release cycles (scrum).</li>
  <li>Minimise work in progress (scrum/kanban).</li>
  <li>Shared ownership (scrum/XP/lean).</li>
  <li>Local product owner (XP/scrum).</li>
  </ul>
  
  <p>To teach Test Driven Development, you can start by writing the tests yourself (you probably will need to do the whole lot, including writing the production code, and then deleting it), and then pass this to the trainee to code, one test at a time. After this they can start creating their own tests.</p>
  
  <p>If you are new to any of this, then take advantage. This will make you more equal, so take the journey <strong>with</strong> the trainee. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-15T09:36:16.487Z
Answers.LastActivityDate: 2018-08-15T09:36:16.487Z
Answers.UserDisplayName: ctrl-alt-delor
Body: <p>In my workplace, my team (working both on a ASP.Net MVC ecommerce and a C++ client) had a recent addition of two young members. One is a fresh graduate and the other worked as PHP programmer for some time. They're both kind of new to the ASP.Net world, along with all advanced concepts of ORM mapping, IIS configuration, performance issues and tricky-to-spot bugs. I'm the owner of the C++ side, and the other team member owns the ASP.Net side (on which I can work a little bit).</p>
  
  <p>We, as senior team members, are expected to carry out our duties efficiently, and at the same time support the young ones in their gradual growth. They're doing their best, and our company allowed me a bit of dedicated time to spend for their education.</p>
  
  <p>I collected my colleague's impression that the basis are already kind-of covered and what they really need to grow is to start thinking in a "professional" way (e.g. understanding the life cycle of a web application or HTTP request, or face a problem without relying entirely on the "senior" side).
  I think these skills come naturally by spending time on the particular project / language / framework and only if one accepts (or is forced) to take responsibilities.</p>
  
  <p>Are there ways to efficiently pass one's "experience" and "problem solving attitude"? Does sitting beside the young ones and working together on the same problem (almost always splitting the work like 70/30) help or hinder their growth?</p>
  
  <p>Thank you for your time.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-08-20T01:48:21.943Z
Comments.Text: As some one who teaches Linux admin stuff and programming at the tech-degree level I really wish I had a good answer for you.  It really can be a struggle explaining "look, you know X about technology Y, now here's how tech X and W are basically the same thing, how do you think W should work?"  I know that as a long time LAMP guy if you dropped me in a ASP.Net/IIS job I'd flounder for a long time - but I think I'd at least have an idea as to what questions to start asking.
Comments.UserDisplayName: ivanivan
Tags: <web-development><debugging><industry-training>
Title: Best way to pass on the problem solving experience
ThreadText: # Best way to pass on the problem solving experience
  
  (Asked by: username_0 on 2018-08-13)
  
  In my workplace, my team (working both on a ASP.Net MVC ecommerce and a C++ client) had a recent addition of two young members. One is a fresh graduate and the other worked as PHP programmer for some time. They're both kind of new to the ASP.Net world, along with all advanced concepts of ORM mapping, IIS configuration, performance issues and tricky-to-spot bugs. I'm the owner of the C++ side, and the other team member owns the ASP.Net side (on which I can work a little bit).
  
  We, as senior team members, are expected to carry out our duties efficiently, and at the same time support the young ones in their gradual growth. They're doing their best, and our company allowed me a bit of dedicated time to spend for their education.
  
  I collected my colleague's impression that the basis are already kind-of covered and what they really need to grow is to start thinking in a "professional" way (e.g. understanding the life cycle of a web application or HTTP request, or face a problem without relying entirely on the "senior" side).
  I think these skills come naturally by spending time on the particular project / language / framework and only if one accepts (or is forced) to take responsibilities.
  
  Are there ways to efficiently pass one's "experience" and "problem solving attitude"? Does sitting beside the young ones and working together on the same problem (almost always splitting the work like 70/30) help or hinder their growth?
  
  Thank you for your time.
  
  **Tags:** web-development, debugging, industry-training
  
  > **Comments:**
  > **username_1**: As some one who teaches Linux admin stuff and programming at the tech-degree level I really wish I had a good answer for you.  It really can be a struggle explaining "look, you know X about technology Y, now here's how tech X and W are basically the same thing, how do you think W should work?"  I know that as a long time LAMP guy if you dropped me in a ASP.Net/IIS job I'd flounder for a long time - but I think I'd at least have an idea as to what questions to start asking.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2018-08-13. Score: 6 | Accepted answer
  
  In places that use the ideas of agile software development, the usual way is to just let the newcomers pair with the more experienced members in all tasks. In your case it would consist of a lot of pair programming. But you would need to do it correctly. It isn't one person programming and the other person watching. Both participate, but in different ways. See [Pair Programming Illuminated](https://rads.stackoverflow.com/amzn/click/0201745763) for a specific description or [Extreme Programming Explained](https://rads.stackoverflow.com/amzn/click/0321278658) for a more complete description of the whole process.
  
  The experience of agile shops is that pairs produce about as much as people working individually (there is research to that effect) but with higher quality. (Specifically, the hypothesis that individuals produce more in total is not supported).
  
  But more so, the newcomer is immediately introduced to the local process in an active way and can start to be productive much sooner. However, the experienced member of the pair will need to turn the keyboard over to the novice frequently (roles switch every several minutes, not hours), and both will need to learn to adopt to the individual roles of "driver" and "navigator".
  
  Pairing combined with faithful use of test first development is especially productive of high quality software, but you need to actually practice the skills, not just talk about them.
  
  > **Comments:**
  > **username_0**: This seems like a fun and constructive way of working / learning, thank you!  
  > **username_5**: Pair programming takes about 2 weeks to get up to speed, before that it is slower. However I have done pair programming with a pier on very difficult tasks, and we were more effective almost immediately. I suspect that for the OP they will be slower for the first 2 weeks, but because of training value, it will pay have positive value immediately. (note: Pair programming would have been my answer. But username_3 did it first and better.)  
  
  ---
  
  ### Answer by username_5 on 2018-08-15. Score: 2
  
  As well as pair programming, look at other agile/lean techniques.
  
  * Test Driven Development.
  * What does done look like? / definition of done (scrum).
  * Short release cycles (scrum).
  * Minimise work in progress (scrum/kanban).
  * Shared ownership (scrum/XP/lean).
  * Local product owner (XP/scrum).
  
  To teach Test Driven Development, you can start by writing the tests yourself (you probably will need to do the whole lot, including writing the production code, and then deleting it), and then pass this to the trainee to code, one test at a time. After this they can start creating their own tests.
  
  If you are new to any of this, then take advantage. This will make you more equal, so take the journey **with** the trainee.
  
  
  ---
  
  ### Answer by username_2 on 2022-10-12. Score: 0
  
  I will have to disagree with username_3 that the pair programing is a bad idea in your case. As a matter of fact I think the pair programing is a bad idea in general and I never see it work in real situation but that is another big topic.
  
  My suggestion is to let them **update/write** the team's technical document, be it high level design documents, technical spec or even good/up-to-date code comments. If you are those "agile teams" that we don't really have a decent document then let them make one.
  
  I believe the document is always a technical debt for any fast moving team. Let the newcomers update/write technical documents to explain how the system works, how a piece of codes work, make the existing document up to date.
  
  To write a good document they need to get their hands dirty, consult with the old guys etc to understand how things work. Writing a good document that people actually will read and refer to is also a challenge to the newcomer and benefit the whole team in the end.
  
  This article [So You're A New Grad Software Engineer](https://evanlimanto.github.io/2019/10/06/so-youre-a-new-grad-software-engineer.html) resonates with me.
  
  Another answer mentioned test driven development, which I am not so sure about either. Of course test drive development is another big topic like pair programming. Personally I tend to agree with the points [Test-Driven Development is Fundamentally Wrong](https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d) made, writing tests afterward (not beforehand) makes much more sense. "Were I to follow the TDD architecture I would have to constantly revisit my tests, review all of them, revising them to match my discoveries." because there will be always things that I didn’t think of until I really implement them and "Because the same blind spots that I had in design will appear in my tests."
  
  I don't mean to provide an answer just to argue/disagree the existing answers. One of reasons I answer the question is that I would like to know 4 years later, when looking back, does the pair programming/test drive development really help you bring up the newcomers? (if the OP would answer it) If yes it will also change (a little bit) my attitude towards pair programming and test-driven development.
  
  > **Comments:**
  > **username_3**: Actually, I've seen pairing work for a major project on a major product at a major international company whose name you would instantly recognize.  
  > **username_3**: WRT TDD, you don't just _write_ the tests and run them one at a time. You repeatedly run them all as a suite so that any error anywhere shows up as a test failure that points you to the error. So, you don't "revisit" the tests until you see a failure. But when you do, you know you have an inconsistency between spec and program.  
  > **username_2**: That actually may illustrate my point here,  it takes 2 highly experienced engineers to make pair programming work (if it does work), which may not be the case here.  
  > **username_2**: About TDD I am against writing test before implementation as I answered in another question.  
  > **username_4**: The context of your answer is that all ideology ultimately backfires. That much I can agree with. Hence +1. However your *concrete* suggestion amounts to postponing **writing code.** Programmers are hired to write code. At some point the sleeves need to roll up.  When?... Remains a question. BTW Jordan Peterson is eloquent in his take against ideology. As is Dijkstra. But both in the end give their own!!! Practice-what-you-preach is *hard!*  
  > **username_2**: When will you let a new guy start to contribute to the code base is basically the team leaders' judgement call. BTW, what is the story of Jordan Peterson  (who is this guy in the first place) ?  
  > **username_4**: One of the first that comes up if u search "Jordan Peterson+ideology" https://www.youtube.com/watch?v=sJo5WxqpgmQ. Its critical of JP but otherwise an ok summary  
  
  ---
  
  