7
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – ivanivan
    Commented Aug 20, 2018 at 1:48

3 Answers 3

6
$\begingroup$

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 for a specific description or Extreme Programming Explained 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.

$\endgroup$
2
  • $\begingroup$ This seems like a fun and constructive way of working / learning, thank you! $\endgroup$
    – phagio
    Commented Aug 13, 2018 at 15:07
  • $\begingroup$ 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.) $\endgroup$ Commented Aug 15, 2018 at 9:26
2
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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.

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

$\endgroup$
7
  • 1
    $\begingroup$ 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. $\endgroup$
    – Buffy
    Commented Oct 13, 2022 at 18:56
  • 1
    $\begingroup$ 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. $\endgroup$
    – Buffy
    Commented Oct 13, 2022 at 18:59
  • $\begingroup$ 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. $\endgroup$ Commented Oct 14, 2022 at 1:48
  • $\begingroup$ About TDD I am against writing test before implementation as I answered in another question. $\endgroup$ Commented Oct 14, 2022 at 1:50
  • $\begingroup$ 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! $\endgroup$
    – Rushi
    Commented Oct 20, 2022 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.