Performance is Key

The reccurring theme for the two-day event was performance. Some of the big takeaways for me were:

We’re all used to hearing that “Rails is slow,” but that’s just a quick jump to a “root cause” that doesn’t tell us anything. Rails 4 (which is creeping towards its release date) has several performance-related fixes, but slowness in an app is almost always the result of poor choices in data structures or algorithms:

Are you requiring tons of files and gems? In MRI, Ruby’s ‘require’ compares each file you load to all the previously loaded files, making the problem exponentially worse with every file you add. This is why your Rails app takes so long to start.

Are you using set operators in Redis without understanding their performance implications? Is there a good chance that the data you are sorting is already sorted? If you haven’t thought about the big-O impacts of your code, you’re probably doing it wrong.

Get convinced that legacy code is good and what you want to write, after watching Chad Fowler’s “Legacy” talk.

See what makes a Ruby library great in Mitchell Hashimoto’s “Building a Ruby Library: the Parts No One talks About.”

More than code

Lastly, were reminded that it’s not just about the code. Being a great developer means growing into new roles to build something bigger than just your own interests. What starts as contributing to open source grows into creating or maintaining a major open-source project, which grows into enabling other people to maintain the project for you (see Wesley Beary’s talk “Maintain Less, Mentor More”). Or pulling things together for designers turns into learning some key design fundamentals and getting to a minimum viable product sooner (see Glenn Gillen on “The Designers are Coming”).