As I cross my 13th year as a professional Rails developer, celebrate my 35th birthday 🎉, and stand at a career crossroad, I want to assemble a few important lessons I learned along the way, that I wish I had learned much earlier.
Hopefully, if you're reading this younger, earlier in your career, or needing a fresh perspective, this gives you a little shortcut. Enjoy!
1. Rails is not magic
Don't get me wrong: Rails is magical. More than a decade on, I'm still awestruck at least once a week. What I mean is that under a very intimidating hood, Rails is just standard Ruby. You can read it, you can understand it and you can learn from it.
The Rails codebase sometimes leverages lesser-known syntax and advanced or unorthodox patterns, but there isn't a secret layer of the Ruby language that only Rails has access to.
Perhaps the most important sub-point is this: you are officially allowed to make your own DSLs (domain-specific languages). Classics like belongs_to, has_many, and resources are not keywords, they are not reserved for accomplished gem authors, or staff-level engineers. You can just make your own, it's easier than you think, and it feels absurdly good.
The same goes for gems BTW. If you want to write a gem, do it. It doesn't have to be extra clever and there isn't an entrance exam. Read that gem code, it's a great way to learn.
2. Most conventions are legit
Whether you know it or not, your relationship with the many strong opinions that shape Ruby on Rails is something like this:
I have seen countless developers out-clever themselves (myself included) trying to improve upon the layers of Rails that needed no improvement or, more dangerously, trying to solve organisational issues with more "resilient" code (instead of talking to people).
Assuming you're reading this from the point of view of a solo developer or a member of a small team, do not try to improve upon defaults unless they really don't feel good to you and you're fighting them daily. And I beg you, do not try to justify stylistic preferences with performance arguments.
Remember also that every deviation from the defaults is an additional potential obstacle come major version upgrade time.
There are still a few areas where I will straight up replace an entire layer (Phlex is a good example), but it's with the knowledge that it's a compromise that has an associated cost, therefore the benefit must be greater.
3. Patterns & Principles are not hammers
In the course of your career, you will have learned of design principles (like SOLID) and design patterns (all of them here). Some are liberally used in the Rails codebase and popular gems.
Confession time: I have gone the majority of my career without understanding at least 2 of the 5 SOLID principles (can you guess which ones?). It made me feel bad for the longest time, then I didn't think about it anymore, then I went back to them and they all made perfect sense.
These principles are tripe-distilled solutions to very specific problems. A lot of people have faced these problems a lot of times, and they are the winning solution out of a really large sample size.
You won't really understand exactly what the problems they solve are until you've faced them yourself and successfully connected the dots.
Until then, you will be tempted to shoehorn a pattern or a principle in every problem. Most often the wrong one. Do not, please, stress about fitting patterns and best practices in your app.
You know the saying: "when the only tool you have is a hammer, everything looks like a nail". Patterns & principles are not hammers, not even tools, they are blueprints for cost-efficient building.
4. Skip the junior flexes
I spent about 3 months learning Vim about 11 years ago. Because I needed to impress my colleagues and extract the most productivity out of myself I thought. Guess how often I use Vim nowadays.
Statistically never. And there's nothing preventing me from it, I could just add the vim bindings to Rubymine, but it's not really useful or productive to me.
Learning vim (and thinking it's important) is somewhat of a rite of passage among developers, which turns out to be not really important or impressive once you're past it.
You use it because it feels fast & natural? Great. You're using Vim (or anything) to flex on Twitter or because you've been convinced that it's required to be a Real Engineerâ„¢? Think twice. No one who matters cares.
5. Engineering is not above the rest of the product
When you're doing the really complex programming (with the principles and patterns and everything), it's easy to get a chip on your shoulder and think of code, especially the bits you've written, as the most important part of the product, vastly eclipsing other areas of product development.
Especially if they're performed by other people (otherwise, you'd probably be biased towards them a little more).
It's really easy to confuse complexity with value early in your career, which is not only bad when you're learning and everything is complex, and you feel like the second coming for understanding it, but also has the side effect of making everything you do feel worthless once it's become easy.
I am not proud to admit it, but this is a pitfall I have fallen in several times shockingly late in life.
Now, if you're working on a product alone, you have the benefit of doing most of everything yourself, which is a really humbling experience that I would recommend to every highly specialized engineer.
That's it for the lessons, I hope they're helpful, or at least that the slight misfortunes get a laugh out of you.
Build well, build smart, but spend more time playing.
— Kevin
​