I've recently become the leader of a group of 3 junior developers. I'm looking for resources to develop their skills and motivate them to become better at what they do. Any ideas where to start? Practical is better.
Without more specifics it's hard to give practical advice. Daniel Pink's book 'Drive' and the video that has been doing the rounds in response <a href="http://www.youtube.com/watch?v=u6XAPnuFjJc" rel="nofollow">http://www.youtube.com/watch?v=u6XAPnuFjJc</a> make an awful lot of sense.<p>Essentially to get the best from people you need to give them
* Autonomy
* Mastery
* Purpose<p>I suspect from your question that you are most interested in
focusing on Mastery, specifically how to help them make progress towards it.<p>I found Pragmatic Programer to be a pretty good general resource. <a href="http://www.pragprog.com/the-pragmatic-programmer" rel="nofollow">http://www.pragprog.com/the-pragmatic-programmer</a><p>Outside of that I'd second the other comment here taking about Design Patterns - I think that the Head First book <a href="http://oreilly.com/catalog/9780596007126" rel="nofollow">http://oreilly.com/catalog/9780596007126</a> is a great introduction<p>Day to day, finding ways to give to really quick feedback is important, code review and general collaboration with the others will really help.
I had a stack of books that I felt were relevant on the new developer's desk the first day they showed up. The exact stack depends on what you are doing specifically, I started from the Joel List: <a href="http://www.joelonsoftware.com/navLinks/fog0000000262.html" rel="nofollow">http://www.joelonsoftware.com/navLinks/fog0000000262.html</a><p>Each week during our 1-on-1 I would review various concepts from each of the books and suggest reading for the following week. It was the best way I found to 1) get them up to speed on best practices and my expectations 2) help them see that my suggestions were (generally) founded on data.
The first thing you do is buy each of them a design patterns book and start forcing them to both read, and use eachother's code. When bugs appear, don't make the author fix the bug, make one of the other guys fix it. That'll probably motivate them faster than anything that they need to 1) write common library of code with interfaces they all agree on, 2) have a version control system they all like, 3) have unit tests to make sure there's no bugs.
Agile methodology is applicable to almost any context, it gets my vote. Particularly test-driven development.<p>Most of my programming is web apps which are a major PITA to use TDD on since so much of it is UI based, but nevertheless I'm struggling through and have found it to be the most useful addition to my repertoire in the last couple of years.
Thanks for your comments. Most development is web-based in PHP, and we also do light customization of OSS solutions.
The company is a contact center, we mostly work on automating business processes