I'm currently mentoring a small team of 4 junior dev in small software company. They are very smart and often achieve their tasks with a high-quality job but I'm sure they still can do better - actually I have exactly the same feeling for myself :) -. Besides some of them are more "junior" than other.

So I would like to find of a funny way to improve their CS skills (design, coding, testing, algorithmic...) in addition to the experience they acquire in their daily work. For instance, I was thinking of setting up weekly sessions, not longer than 2 hours, where we could get together to work on challenging CS exercises. A bit like a coding dojo.

I'm sure the team would enjoy that but is it really a good idea? Would it be efficient in a professional context? They already spend all their week to code so how should I organize that in order for them to get some benefits?

Any feedback welcome !

  • 3
    MR. NOLAN ~ Dead Poets Society : "At these boys' ages? Not on your life! Tradition, John. Discipline. Prepare them for college, and the rest will take care of itself." Coudn't resist :P +1 for good question.
    – Matthieu
    Dec 23, 2010 at 16:09

8 Answers 8


Here are some ideas

  • Book club, read the books like Pragmatic Programmer or other career centric stuff.
  • Coding Dojo, you can start with a simple problem outside of project and then extend it to the Project or otherwise if you may choose.
  • Retrospectives or feedback meeting, for getting ideas from the group itself to improve the project development in which every one participates
  • A user group meeting in which a designated person presents this would improve the presentation/soft skills of the team

  • once in a while doing a non-work related task like going to Dave & Busters to have a fun friday or sorts.. to improve team chemistry

Any of the tasks or meeting should be less than 45mins just to have the entire group interested. Any thing that goes beyond and hour will completely fall on to the shoulders of the presenter or leader of the group.

  • I second the book club. I wouldn't be even close to a good developer if I didn't read the books I have on programming and software development. Books let you see how the experts do it, so you yourself can become one.
    – Brian D.
    Dec 23, 2010 at 17:14

People may well have their own ideas about how they want to learn. Personally I would rather take a course or work on a project in my own time - and have done both. If everyone on the team is OK with the training sessions then go for it, as long as the people on your team will not start to treat it like "work" over time...

  • I get the point that they mey need a different "atmosphere" to learn but I like the collective approach of coding dojo. Everyone can benefit from the best ideas and may understand what was the approach to find them...
    – pierroz
    Dec 23, 2010 at 16:12
  • Fair enough, although if you are going to bring everyone together you might want to make the group more involved. For example, bring your own ideas to the first couple of sessions but then have a different person bring the exercise each of the following weeks. Also, consider doing other things as well such as reviewing a weekly code snippet, having people present tasks they have worked on (or technical areas they are learning about such as WPF, TCP, etc), and so on... Dec 23, 2010 at 16:37

I think that the only way to keep a team well-trained is to hire developers that want to continue learning.

If it isn't coming from inside, it won't yield lasting results.

if they do desire to learn, then whether team learning activities are effective or not will depend mainly on interests and learning styles.


I think the dojo system sound cool, and allow them to proceed at home if they want to. Adding some kind of reward could be useful but you might emphasys cometition and i dont think to much of that any good for teamwork. Anyway, an amazing place to go look for computer problems its Sphere Online Judge. It defines a problem, a set of expected results and lets you upload a file with the solution to the problem. If you get it right, you points go up.

Good luck with that!


There's a number of skills we need as developers that aren't necessarily directly related to code. One example is presenting, and explaining technical things to non-technical people in a way they can understand. Something that can be effective while you are getting your team up to where you want them is to give something like homework.

Each week, you give your guys a problem to work through. To keep it most beneficial to the company keep the problems to something relevant to what you are working on. Preferably some pain point you haven't figured out the solution to yourself yet. Each of your junior members would take turns presenting (preferably one a week) while you play the role of the client. Essentially, you have two goals with this approach:

  1. The act of teaching/presenting requires the guy on the floor to have a deeper knowledge than just doing exercises. It's an indirect, yet very effective way to teach someone a topic.
  2. If they can convince you that it is a good idea, they might be able to convince a client the same thing. Make sure you throw in questions that make them think about the business impact of what they are proposing.

Of course, start each session with a reminder that you are going to ask pointed questions--and the purpose is not to be mean, but to prepare them for a tough client.


As a manager or senior I would strive to keep throwing up challenges in the 'real' work. Try give people things to work on that are a little bit out of their league or at least challenges them. Send in one of their peers to help out and tutor if needed.

After someone finished something, challenge them to try a new/different approach.

Coach them at figuring things out on the spot instead of working around stuff they don't know how to do yet.

Integrate learning into the work itself, side projects for learning tend to get skipped with deadlines on the horizon.

Sometimes directly stating a need for a given expertize can help as a motivator.


Give them 3 hours a week to research/hack on whatever they are interested in for programming. Ideally this would be more, but I think 3 hours is a good start. It could be all in one chunk, it could be broken down into little 30 minute segments along the way. It sounds like these programmers are motivated enough that they would be able to keep things in check.

But allowing them to explorer their own fields of interest will come back to help the team as well. One person that really likes data may look into and write a small app using a NoSQL solution that could help a project that comes up a few months down the line. Another person might right a small utility app for a trivial need (such as parsing log files) that becomes a staple app in your team. Even the knowledge gained from reading up on what the big companies are doing can help evaluate options for the next project that comes up.

We're in an environment that is ever changing, and each member of your team I'm sure brings something unique to the table, so give them the opportunity to expand on their own terms. They'll be appreciative that they haven't been forced into something (even though all intentions are good) and you'll get a good diversity of feedback.


Another technique I've seen that works is a lunch presentation from a senior developer/consultant once a month or so. And don't forget to provide the lunch. Most devs I know love free grub. You might ask them if they prefer any specific topics.

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