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.

  • $\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
    Aug 20 '18 at 1:48

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.

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

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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