About 2 years ago, I created a javascript image/photo gallery to embed gallery functionality into a web site using only client-side processing. Although I created it for a specific purpose, it was generic enough that I decided to make it available for other people to use on their sites.
Imagine my surprise when people took me up on that offer.
In spite of the number of image gallery alternatives, a number of people have used the version I created and have contacted me with questions and comments. Looking back on the code, as I frequently find with code I wrote in the past, there are definitely a lot things I could do to add to it or improve it (e.g. put the image data and config options in an XML file).
In fact, I’m interested not just in making improvements, but also keeping the code in a repository and tracking changes, announcing updates, and testing it more rigorously. An added dose of professionalism to a pet project – all because I know that other people are working with the code.
I recently read a quote on the pbkiki site: “When students write a paper, they’re usually writing for one person: their teacher. When students know their peers will read what they write, students care and they try harder.”
This is an interesting observation (and one that certainly holds true for the marketing class I am currently taking). I think this observation applies to web development as well: when you’re writing code, you’re writing for the computer. You want to make sure that it runs efficiently and without errors, and that browsers render the output as you expect. If you share that code and you know that other developers are going to look it over and evaluate it, I think you try harder. Quick-and-dirty solutions become a little more clean-and-organized.
I’ve been trying to champion code reviews at work (with limited success) as a way of improving our developers’ code through feedback. Perhaps that’s only part of what improves the code, though: if you know you’re code will be reviewed, you might put more effort into it!
Likewise, participating in an open source project is probably a great way to improve your coding skills, not just because of community feedback, but the extra effort you put into it either to impress other developers. It might not make sense make every application sufficiently configurable to release to the public, but developing as though you are might produce a better product.
Chris, I couldn’t agree more. Releasing code to the public is sure to cause your code to move up a notch in quality. (which is not always a good thing, One of the weird things that I have been learning as a freelancer is that sometimes quick n’ dirty throw away code _is_ the right answer)
At the same time I don’t know that code review with co-workers will have the same effect. I think its a question of the belch check. Would you feel comfortable belching loudly in front of the co-worker who is going to be reviewing your code? If so then you probably are willing to let him catch you with your globals hanging out as well.