# get the list of photos from flickr
def get_flickr_photos(self):
    flickr = flickrapi.FlickrAPI(self.flickr_api_key, format='etree')
    photos = flickr.photos_search(user_id=self.flickr_user_id, per_page='50') # comes out as the _ElementInterface
    # parse out the XML and return an array of URLs
    # http://farm{farm-id}.static.flickr.com/{server-id}/{id}_{secret}_[mstb].jpg
    urls = []
    for image in photos.getchildren()[0]:
        img = {}
        src = 'http://farm%s.static.flickr.com/%s/%s_%s_m.jpg' %  (image.attrib['farm'], image.attrib['server'], image.attrib['id'], image.attrib['secret'])
        url = 'http://www.flickr.com/photos/%s/%s/' % (self.flickr_user_id, image.attrib['id'])
        img['src'] = src
        img['title'] = image.attrib['title']
        img['url'] = url
        urls.append(img)
    return urls

• Use a source control system
• Use a continuous integration process that compiles, unit tests and if possible integration tests on each check in.
• Unit Tests. Without unit testing you cannot guarantee the code at its lowest level does what the function/method says it does.
• Integration Tests (or functional tests as we call them). Without integration testing you cannot guarantee the functionality works as the GUI, DOM, public API, Webservices or Remote Interfaces say they do. These tests will also shake out issues with the database, third parties, or transactions.
• Descriptive classes, method names, and variables to minimize the need of commenting code. Naming is very important and can dictate how another developer will interact with the code.
• Software minimalism is good. Write less code. Make methods smaller so they only do one thing. Don't nest if statements. Only write as much code as is needed and don't design ahead for possible future needs.
• Use RuntimeExceptions unless a checked exception makes sense or needs to be explicitly communicated through the API to a developer using it.
• Commenting code is valuable when it explains why something coded that way. The code should say what a method, or a variable does and not need a comment.
• Never check in commented out code.
• Never check in broken unit tests.
• Always leave the code in a better state - ie, higher quality - than how you found it. That means must be unit tested, must be functionally tested, descriptive method, class and variable names and commented where necessary.
• If you are stuck on an issue for more than twenty minutes ask for someone else to help you. We often ask, "Can I borrow your pair of eyes on this please?" Usually another person looking at the issue will point out something minor thar is causing the block, or the process of explaining the issue will lead to an ah-ha! moment.
• Design important pieces with other developers so that the most efficient mechanism is sketched out. Do it as informal chat around a computer if possible.
• Avoid formal meetings like the plague. Sometimes they are important, and those that are should be attended, but 99% of the time they are a complete waste for everyone involved and productivity sapping.

• Refactoring. Improving the Design of Existing Code
• Clean Code

try {
    ...
} catch (Exception eee) {
    ...
}

try {
    ...   
} catch (Exception e) {
    try {
    } catch (Exception ee) {
       try {
           ...
       } catch (Exception eee) {
          // swallow exception
       }
    }
}