12 years of experience programming computers.
4 years experience with Ruby and RubyonRails, expert with both.
One of the first to adopt RubyonRails in September of 2004.
In 2003, I attended a scrummaster training taught by Ken Schwaber.
Ardent believer and avid practitioner of Test Driven Development.

I take pride in the work I do and strive every day to produce higher quality code. I care about the success of the projects I'm brought in to work on as if they were my own.
I believe the best thing any programmer can do is to try hard to avoid writing code. Writing the right code to support the wrong business goal is as common as it is wasteful.
The business of software is hard.
Object oriented programming, the agile movement, and the rise of dynamic languages has changed the way software companies go about creating business. Still most developers who claim to practice all three well are probably lying. It's harder than it looks.

If stuck on a desert island and I had to choose between only reading works by Paul Graham or works by Joel Spolsky I would choose only to read Paul's essays. Hopefully though, the ship wreck would afford me the opportunity to read whomever I wanted. In which case I would read the complete works of my heros: Martin Fowler, Kent Beck, Robert Martin, The Pragmatic Programmers, 37 Signals, and Bruce Schneier
Make it work, then make it right, then make it fast. There is no other way to do it.
You want all three, I know, but...

I've worked on enough social network apps, to be able to say that the hardest part of social networks is the "Cold Start" problem, or how to get an initial population of users. Nobody thinks about this until it's too late, and in this day and age, it's hard to get people to try another social network.
Scrum is hard, what gets championed as agile, usually is a masquerade for the same old command and control. It's hard for us to give up command and control thinking.
I'm agnostic about testing frameworks, RSpec, Test::Unit, Shoulda, miniunit, I can make them all work for me (and you).
If you don't have the right value proposition to match your business model, then in all likeliness you will build the wrong Features.
A lot of times the person who you are selling to is different than the person who is your user.
There is no such thing as a hard and fast rule for software best practices. I can quickly pick out what I like, and what I don't, my tastes in the best way to build software seem to follow pretty closely with what other industry leaders are doing.
I'm passionate about my beliefs and as such I'm prone to being flat out wrong sometimes.
I try always to be nice and treat others with the utmost of respect. I have a pretty firm "No Assholes" policy, I won't work with them.
As a rule of thumb, I don't like any method or function to be more than 13 lines.
One of my favorite coding practices is Refactoring as described by Martin Fowler. My two favorite refactorings are extract method, and extract class.

I've tried 100 percent code coverage and found it not really necessary or desirable, I have a pretty good feel for what quantity of code coverage is needed, also the quality of the tests matter more than the code coverage.
No one really believes in writing code without unit tests any more do they?
Rails has a much steeper learning curve than what many newcomers might expect, it's not for the meek.
It took me years to reach the point where I feel all powerful with ruby. Metaprogramming can be overkill if you aren't sure why you are doing it. As much as I think I know about Ruby I'm always finding someone else who shows me a new trick.
A code base is considered worthless if the time to learn how it works is longer than the time it takes to rewrite it. Software isn't like home construction, you can go from 80 percent completed to zero percent completed if key developers leave.
If you are in the software business then you are in the recruitment business there will always be a shortage of skilled people and recruiting should be familiar. Be aware of the "hit by a bus" syndrome as well. Knowledge needs to be spread out amongst multiple people.

Web Development

Featured Work