Bill Ricker wrote: > speaker Scott Mattocks > topic “treat your code like a member of the dev team.” > > You expect your developers to communicate well; you should expect > your code to communicate well. You expect your developers to continue > working when things go slightly wrong; you should expect your code t'o > continue working when things go slightly wrong. The core message is > language neutral. ...
Below are my notes that I "live blogged" to #boston.pm (irc.perl.org). Not much detail, but they'll give you a taste if you couldn't attend. Dealing with 12 year old code. Writing code is easy. Good teams make it easier. Code has to be part of the team. Write stuff down, communicate; code uses logs to communicate. Knowing there is a problem is half the battle. (Speaker uses log4perl at his employer, GSN.) Good developers tell you what they are going to do; in code, that's unit tests. Good developers adapt quickly to changes; good code changes its behavior without changing the code. i.e. dev/qa/production run modes; configuration files. Good developers tolerate bad news; good code handles failures. Isolate code and let it make the best it can with the data or resources available. You don't give a new team member production access on the first day; don't release features the instant you deploy the code. New features are wrapped in conditionals so they can be deployed dormant, then turned on, and if there is a problem, turned off. Good developers communicate well with non-technical people; good code doesn't require you to read the code to understand it. i.e. it has good comments. Talk over. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
