Comments on: Planning JavaScript and Ajax for larger teams, equine invigorating imagery, one voice for libraries and a lot of good speakers - this was @mediaAjax 2007 http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/ Chris Heilmann - Accessibility, Web Development and Pragmatism - can talk, will travel Fri, 05 Sep 2008 19:38:04 +0000 http://wordpress.org/?v=2.5.1 By: Tim http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6699 Tim Thu, 06 Dec 2007 23:52:36 +0000 http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6699 @Ion: You're dead right. If you're interested in programming practices I can recommend reading Extreme Programming Explained by Kent Beck (or take a look around xp123.com). XP lists the practices that Chris mentions such as: team agreed coding standards, communication between developers, collective ownership of code rather than heroes, code reviews (through pair programming, not mentioned), plus a whole bunch of others that Chris probably did not have time to get to such as testing. There are also alternatives to XP. Google for 'agile development' or SCRUM. @Marko: One way to get around different skill levels is to pair an experienced/senior developer with an inexperienced/junior one. The senior will have control of the keyboard and mouse initially, but over time as the junior should learn and understand what the senior is doing by actively asking lots of questions. Within a couple of months the junior will be typing more and the pair will work better together as they realise each other's strengths and weaknesses. Recommended reading: Pair Programming Illuminated by Williams and Kessler. One benefit of pairing within small teams (and try to get everyone in the team to pair with everyone else at different times of the week) is that knowledge of the code is shared, so holidays and stepping in front of busses, become much less of an issue. One note of caution: I wouldn't have people pairing all day long. It can be very intensive and therefore exhausting. You must be feeling fresh and energised throughout the working day. Good luck! @Ion: You’re dead right. If you’re interested in programming practices I can recommend reading Extreme Programming Explained by Kent Beck (or take a look around xp123.com).

XP lists the practices that Chris mentions such as: team agreed coding standards, communication between developers, collective ownership of code rather than heroes, code reviews (through pair programming, not mentioned), plus a whole bunch of others that Chris probably did not have time to get to such as testing.

There are also alternatives to XP. Google for ‘agile development’ or SCRUM.

@Marko: One way to get around different skill levels is to pair an experienced/senior developer with an inexperienced/junior one. The senior will have control of the keyboard and mouse initially, but over time as the junior should learn and understand what the senior is doing by actively asking lots of questions. Within a couple of months the junior will be typing more and the pair will work better together as they realise each other’s strengths and weaknesses. Recommended reading: Pair Programming Illuminated by Williams and Kessler.

One benefit of pairing within small teams (and try to get everyone in the team to pair with everyone else at different times of the week) is that knowledge of the code is shared, so holidays and stepping in front of busses, become much less of an issue.

One note of caution: I wouldn’t have people pairing all day long. It can be very intensive and therefore exhausting. You must be feeling fresh and energised throughout the working day. Good luck!

]]> By: Ion Morega http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6518 Ion Morega Sun, 25 Nov 2007 14:21:04 +0000 http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6518 I really enjoyed your talk, I think it was a really useful set of tips on how to work with a programming team in general, not necessarily on JavaScript. I really enjoyed your talk, I think it was a really useful set of tips on how to work with a programming team in general, not necessarily on JavaScript.

]]> By: Sander Aarts http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6495 Sander Aarts Fri, 23 Nov 2007 08:50:50 +0000 http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6495 The "No more heroes!" and "Don't listen tot the 'inner hacker'" photos are great ;-) The “No more heroes!” and “Don’t listen tot the ‘inner hacker’” photos are great ;-)

]]> By: Marko http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6477 Marko Thu, 22 Nov 2007 10:45:38 +0000 http://www.wait-till-i.com/2007/11/21/planning-javascript-and-ajax-for-larger-teams-equine-invigorating-imagery-one-voice-for-libraries-and-a-lot-of-good-speakers-this-was-mediaajax-2007/#comment-6477 I was there and like I said couple of days ago, I really enjoyed your presentation, especially since it tackled the problems I'm facing in near future. I know it's hard to be specific, but I would love to hear more about how you handle differences between developer skill levels. It seems having a strict hiring process and avoiding too-clever techniques would only get you so far. I was thinking about having different expectations for code that goes to our "library" than the one living outside of it, but the problem with this approach is that with a young, and hence very small team, this distinction doesn't guard you from pitfalls you've mentioned (going on vacation or stepping in front of a bus problems). Conference was excellent and if there will be another one next year with a lineup like this, I'll be there again. I was there and like I said couple of days ago, I really enjoyed your presentation, especially since it tackled the problems I’m facing in near future.

I know it’s hard to be specific, but I would love to hear more about how you handle differences between developer skill levels. It seems having a strict hiring process and avoiding too-clever techniques would only get you so far. I was thinking about having different expectations for code that goes to our “library” than the one living outside of it, but the problem with this approach is that with a young, and hence very small team, this distinction doesn’t guard you from pitfalls you’ve mentioned (going on vacation or stepping in front of a bus problems).

Conference was excellent and if there will be another one next year with a lineup like this, I’ll be there again.

]]>