I love coding. My ideal day in the office is one with a long to-do list and a clear calendar.

One of my favorite ways to block out background noise is to put on a set of headphones and fire up iTunes, Pandora, or Grooveshark.

I’ve long wondered why the two activities fit so well together. The music I’m listening to can impact my energy level, level of focus, productivity , and sometimes even my passion for the project I’m working for. Perhaps, music is just a great way to cancel out background noise, allowing increased focus. Or, maybe music stimulates the same logic or mathematics-oriented areas of the brain that coding does. Skills like pattern-recognition, inference, and abstraction are common both to both. I’m no psychologist, but my own empirical observation has shown a heavy overlap between the programmers I know and friends who count seeing or making live music as a hobby. Maybe it’s self-selecting, but I think there may be a shared set of innate qualities between the two populations.

Or, perhaps as an engineer I am simply doomed to attempt to vigorously try to reverse-engineer everything I come into contact with. Though the practical merits of listening to music while I code are clear to me, I’d never realized how similar the process of writing a computer program is to writing a piece of music: Galghamon, a stackoverflow.com commenter who studied both music theory and composition, notes:

Musical notation is a lot like a system spec: There are varying amounts of information present, from which you have to make educated guesses about what was intended. Composing music on paper is a lot like writing a system specification. The more you spell out what you want (using all the notational elements available), the more faithful to your ideas the final performance of the piece will be. But just as you can have coders that ignore some of the specs, you’ll have some musicians that will improve on the piece by ignoring certain instructions and providing their own interpretation. Sometimes this works, sometimes it doesn’t.
Writing code is a lot like playing music: you interpret the instructions of others, internalize them, interpret them, until you can deliver a performance. There’s no clear right or wrong with either, just degrees of faithfulness to the original thought or intent, but there’s a goal in both (even improvisations follow a certain style and direction). How well that performance was executed is left for others to judge (audience, users), except when your playing or programming for your own pleasure.
Debugging and testing is a lot like hearing your a composition played for the first time – there are often wrong pitches in the notation, simple notational errors, but sometimes you can tell that something just isn’t working right in an ensemble, so you have analyze the problem and look at why this is. You can do trial runs with users/audiences to see what their reaction is.
[ Click through to read the whole thread ]

So there you have it. Some musical pieces can be engineered or reverse engineered, the same as how us hackers can engineer a website, program, or video game.

But anyway, I’ve digressed.

After a chat with a close friend about music and code, I’ve come up with three themes I consistently see in good coding music:

1. Fast Paced.
2. Instrumental, without lyrics.
3. Heavy on melody and rhythm

Genres like classical, jambands, and electronica fit right within these themes. But, basically, I’ve found that anything instrumental (primarily, without the spoken word) works.

Some of my favorite artists for coding:

• Classical:
  • Bach,
    
  • Mozart
    
  • Beethoven
    
• Jamband:
  • Lotus
    
  • Explosions in the Sky
    
  • STS9
    
• Electronic:
  • Cut Copy
    
  • Radiohead
    

Do you see any parallels between music and code? What are they? What do you listen to to help you focus?

What I’m paying attention to this week (via delicious)

• Ponder This [FLASH] – Woody Harrelsons poetry about community and leadership
• Andrew Hyde – 3 Simple Blogging Tips [TEXT] – Advice for those who are just getting started blogging
• Aurora Borealis [PIC] – Breathtaking
• WIRED – Gone Forever, What does it really take to disappear? [TEXT] – Stories of ordinary present-day Americans who’ve decided to leave their whole life behind, for reasons legitimate or sometimes not so legitimate, and create a whole new identity.

dfib8u9my6

— This post is part of a series of ongoing tips on lessons learned & experiences I’ve had as the lead developer of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I’d wish I’d known as a lead developer at Techstars. —

I spend a lot of time worrying about how my system is going to scale. The next time we get that big press piece or hit some load issue, I want to make sure that I have a plan in place.

Build for Scalability
I’ve collected a small bag of tricks to help the performance of my application (which is coded in PHP, MySQL and jQuery).
- Learn how to use MySQL indexing.
- Use include(); sparingly (PHP only).
- Use Memcache in your database layer.
- Use front-end hacks like far-futures expires headers, CSS sprites, and image maps.
- Perhaps this goes without saying, but: Make sure your code-architecture is de-coupled and highly logically-cohesive. More on this here.
- Prepare your database architecture for scalability. This post, by Digg’s Joe Stump, does a good job of laying out their database architecture.

Beware of premature optimization
Sometimes you bend over backwards to make sure a new feature is entirely scalable, and when you launch, nobody (or almost nobody) uses it.

You may not know for sure which features your users are going to use heavily. You could have a hunch, but you don’t know for sure until you launch that new feature.

It’s a balance, for sure. I don’t know that I have the magic formula. But, I think I’ve struck a good balance by considering which features are critical/central to the system, building for scalability, being careful not to make any short-sighted design decisions, writing good documentation, and following my instincts.

In the spirit of giving credit where it’s due, I’d like to mention that Eventvue’s Josh Fraser gave me the idea for this post during my time in Boulder last month. Check out his blog, Online Aspect, for his musings on his adventures at Event Vue.