I am a programmer living in Tokyo, Japan.

Lately I've been very excited by learning Clojure, and I've been slowly going through the problems at 4clojure.com, but I have a long way to go.

Other stuff I'm interested in include learning Japanese (I'm at conversational level now, and I can read probably at a middle or high school level, depending on the subject), music (I studied music), and cooking. I'm originally from Western New York, and most of my family is in the Rochester area. I've lived in the Northeast of the U.S. for most of my life, primarily in Boston, MA and New York City, New York, but in 2011 I moved to Tokyo, Japan to practice my Japanese and try something new.

Software Development

I've been doing web development, with occasional forays into other domains of software development, for almost 15 years. However, only in the past four-to-five years would I say I've moved from being a "hacker" to someone who takes software engineering seriously as a professional discipline. For me this means:

• First and foremost, ensuring the software I'm building meets the needs of my company's customers or my clients.
• Continuously refining my ability to give good estimates on the time it will take me to develop a feature.
• Producing well-tested code of the highest quality I can, both because it provides the most value to users, as well as relieves pressure on future maintainers (whether that be me or other developers).
• Continuously working on learning more about computer science and software engineering best practices so I can grow as a person as well as a professional.
• Learning more about adjacent disciplines like design, user interaction, marketing and finance. This allows me to provide more value as a developer as well as communicate better with my co-workers who I build software with.

I believe Agile software development as a practice provides the most value to teams building software—especially incorporating "Extreme programming" practices such as test-driven development, refactoring, continuous integration and pair-programming—but I appreciate that these practices have different utility for different teams, and I try to integrate them where they fit best, without dogmatism.