5 habits that made me a better Ruby developer
2016 was the second year I worked as a freelance developer. Of course my previous roles in companies involved some level of development, but I often considered those to be too quick & dirty (prototyping ideas for applications in safety critical environments) or as a temporary solution (CTO in a tech startup, after-work co-founder).
I still learn new techniques, new tools and gain new insights (e.g. into Rails) every single day, but here are five habits that I developed over the last years that help me to do a better job. It’s not so much about specific know how, more of a mindset to know your tools, and keep on pushing to get better.
1. Use RuboCop, all the time, everywhere
I’m a firm believer that a style guide and accompanying tools that enforce it are the best way to a uniform codebase. Uniformity is desirable because it keeps my cognitive load low when browsing through source code, having enough reserves to focus on the actual task.
Having RuboCop enabled not only in your editor (I’m using the linter-rubocop package for Atom) but also on your CI helps you to stay consistent across your team. My go-to choice is pronto, which you can configure to post comments to GitHub PRs.
One thing to keep in mind: RuboCop ships with the default ruleset of the Ruby Styleguide. You might not need/like/support all the rules - so settle for a ruleset that you like and that you wanna adhere to. I don’t think it’s pretty if there are two empty lines following a class definition. But that’s not the point - the point is that it’s easier for me to read source code that has a common style and sticks to common rules.
2. Keep your git history clean
I’m an advocate for a clean git history: when I work on a codebase I’ve never seen before, or on code that I haven’t touched for a long time, understanding how things developed is a big plus because it helps you to gain context to better understand the problem you’re trying to solve.
Before submitting a PR I re-read all commits, checking if each one makes sense on its own (because that’s what you will see when running a
git blame) and describes a separated piece of changed logic or added functionality. I clean up individual commits, squashing them together, splitting them up, and refining commit messages.
3. Start a playground project
Mid of 2016 I started blogging again (keeping a consistent schedule is my plan for 2017). One of the first things I did was to create a fresh new rails project. That way I could try out a few ideas I had in mind about potential topics.
Soon that project evolved into a general go-to place when I wanted to test a new gem, try out a design pattern I wasn’t sure how to implement or use, or any other form of test bed.
Sometimes I would hack on it for hours, only to do a
git reset --hard at the end. If I was happy with a new gem or a snippet, I would commit my changes and make some notes about issues I’ve found or things to keep in mind when I wanted to use it elsewhere.
4. Read the Rails source code
I’m definitely not saying that you need to read all of the code (which I guess wouldn’t make sense anyway), but there are certain interesting parts: currently I’m diving into the Rack middleware that ship with Rails, or recently I was interesting in how
Rails.env.production? works. You will find gotchas that are sometimes not documented in the guides, sometimes not even documented in code, and you need to look for references to tickets or PRs. You will get to know how things work behind the scenes (or why they don’t), and you’ll find some new tricks.
5. Re-read the Rails guides
The second best thing next to the Rails source code is its guides. Back when I started with Rails around 2005, the guides were my first place to go when I wanted to learn about a feature. Even though the first books have been published and people started blogging about Rails, the guides were still the best place to learn about new functionality, get tips and tricks, and keep up-to-date with changes in newer versions.
Even if you’re a senior Rails developer, there are always new things to explore: Did you know that ActiveRecord has a
#only method that lets you skip certain conditions from a query? Or that there’s an
absence validation? Or that you can prevent certain redirects from being logged?