I agree with William except on point ... William, I'm sure you're idea is in the spirit of improvement and sharing, but putting Jr. developers on the hot seat and allow senior developers to show off a little is one of the reasons I don't like working in large development teams with this kind of environment.
There's nothing worse than a knowledgable developer that wields his knowledge for the benefit of their own ego at the expense of others. It should be more of a mentoring environment. It's true, that a developers knowledge is their greatest stregnth, but the use of that knowledge is the greater test the person's character. My 2 cents. >You are the lead, you see a problem with not only the current code but >future code put together. You are introducing standards to the group. This >is not at all a bad thing. You will probably be heralded in the future for >your attempts now, however despised you might be for it now. > >I would suggest doing 'spot checks' on other people's code, or 'peer >reviews' on their code so that you can verify that the standards are being >kept to. > >You might even do this as a 'group' event. Where the group of developers >gets together and puts 1 programmer on the 'hot' seat. The programmer will >'run through' his/her code and explain what it is doing and why it is there. >You could critique the code based on ample commenting and standards >adherence, and you can have the group come up with plausible solutions for >'heavy' code or code that is 'muddled'. This would be a great exercise to >help the 'junior' coders get better as well as the 'senior' coders to hone >their skills and 'show off' a little. To get everyone off on the right foot >you might even make the first few 'sessions' regarding a custom tag or UDF >that you can download from the exchange. Send it out to everyone and have >everyone 'change it' based on their programming skills but to your new >standards. Then you can run through the original example and open it up for >discussion. > >Just an idea... > >Can you tell I am 'dying' to get out of my '1 guy' shop and join a bigger >team? > >William > >-- >William E. Seiter > >Have you ever read a book that changed your life? >Go to: www.winninginthemargins.com >Enter passkey: goldengrove >I recently started a position as a technical lead at a new company. Most of >the development is done on a few intranet/extranet sites, so the code (much >of it spaghetti) is touched by a lot of different developers. > >I've recently set up a wiki that contains coding standards, and used a lot >of the LiveDocs recommendations (with a "References" section indicating >sources). I've gone the route of placing these standards under some general >categories, such as "Security", "Performance", and "Stylistic". > >The "Stylistic" category defines things such as capitalization and >indentation. It may have been a bad idea, but with this category, we came to >a lot of these standards based on the consensus of the group - most of whom >maintain the coding style of the CFWACK, e.g., title casing function names, >uppercasing CF operators, etc. > >Wondering if any of you would think it is beneficial (or too draconian) to >have these "stylistic" standards in place, even if it isn't an individual's >preference, to promote readability, consistency and prevent constant >reformatting (annoying when doing diffs), especially in an environment where >different developers are touching a lot of the same code? > > > > >http://webapper.net/index.cfm?fuseaction=Fuseblog.ShowComments&ArticleID=200 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Get involved in the latest ColdFusion discussions, product development sharing, and articles on the Adobe Labs wiki. http://labs/adobe.com/wiki/index.php/ColdFusion_8 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290595 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
