I got promoted to my current position, Lead Developer, about eight months ago and I've recently been reflecting on what I think I've achieved and what I need to improve on, you can consider these posts thinking out loud. The role was newly created when I was appointed, we previously only had developer roles reporting straight to managers.
First, a little background on what we are and do. We are a small IT Department, working as a support team for a multi-disciplinary engineering contractor, including development of bespoke systems, mainly web applications. We're currently trying to move all these sub-applications into one big application. We currently employ three developers and two trainee developers. The developers work full time on the main application, while the trainees work through training material and small projects to gain experience.
Trainee Developers
When I first got promoted to the position, the main change to my daily work was being mentor to the trainees. When I started as Lead Developer, we didn't actually have any trainees, but were about to recruit. I was involved in the recruitment process, which was a good experience for me. I had actually asked my manager if I could sit in on a couple of interviews for experience before I got promoted, so I was interested in the aspects of hiring anyway. I did a little background reading on interview techniques [Recommended: 1, 2, 3, 4, 5], particularly regarding programmers and stuck to the technical side of things, allowing my managers to use their experience to judge the 'people skills'. Things went pretty well, but I'm concerned I probably wont ever do it enough to get good at it. Having said that, I'd rather keep the staff we've got than get really good at recruiting.
I inherited a training programme and modified it only slightly, except for the module on working as a team, which I rewrote. The trainees work through the programme completing exercises and taking on mini projects along the way. It seems to work pretty well, but I haven't given the actual programme any attention recently and should get it updated, to try and introduce some more modern development techniques.
The biggest problem I have, is not doing things for the trainees. Whenever they have a problem and ask for help, the temptation is to big up the keyboard and crank out the code they need. This would have benefits, the trainee gets decent code doing what they need and I can get on with my other responsibilities. The downside is, unless the trainee goes back and studies my code, they'll never learn. Instead I need to take my time and coax the answers from the trainee and let them solve their own problems, albeit with a little provoking
Recently I experimented with our newest trainee, who came to us with little actual programming experience. For his first project, I gave him the choice of implementing it the slightly harder way, which would take him longer but hopefully he would learn more, or the quick and easy way, leaving the harder stuff until later on. Thankfully he chose the hard way and I set him off on his way to use the Zend Framework. I like the idea of this, I know a lot people find it difficult moving from procedural techniques to object oriented methods, so why bother learning the procedural techniques first? I gave him a pointer by showing him Akra's superb tutorial and he went from there. On demoing the project to my manager, the trainee was asked "if the system was object oriented?" He replied "No". He didn't actually know he'd implemented the whole system, barring the view scripts and the boot loaders in object oriented PHP. At first I thought this was bad, thinking he hadn't realised what he was doing the whole time, but maybe it's just that he thought that was just the way things were done. I think this was a success and would be interested to hear how other companies introduce their trainees to frameworks and object oriented principles.