Earlier this week, I attended a Vancouver Ruby meet-up. It was my first time ever attending a development-related meet-up, and I thought I’d share some of my takeaways here.
The first talk was called “Change is a CONSTANT” and was given by Andrew Vit. I had a few takeaways about Rails architecture and git, but the main one was this:
Your version control history should tell a fluent and coherent story. If it doesn’t, you can squash your commits to better group commits together such that the history is useful for people reading your code.
The second talk was called “The OTHER product you’re building” and was given by Jeremy Baker. I had quite a few takeaways about good coding practices from this talk, some of which I’ve mentioned below.
When you’re building a piece of software, you actually have at least two products. The first is what we think about as the product: the thing created for customer use. The second is the product that other developers will be using when maintaining or improving your code. We’re often reminded to remember quality when it comes to customers using the product, but we also need to remember quality when it comes to other developers using the code.
The limit in any organization isn’t resources or time. It’s energy and motivation.
To ensure quality code, it’s important to decide on and define coding patterns. And then it’s important to document them. It’s a lot of overhead up-front, but it ensures that developers being introduced to the project are able to quickly get an overview of coding patterns and standards.
The Guard gem can be used to automate quality control by triggering certain events when file changes occur. These events may include running tests, ensuring styling guidelines are observed, and scanning for security issues.
Another point on documentation: it’s important to document decisions and their histories. This includes the decision, the options that were considered, and why the choice was made. This provides context for people who are looking back at the code.
The product is the behavior change you cause in your users. It is not the application you’re building.
For each desired change, make the change easy (Warning: This may be hard), then make the easy change.