Hi there, my name’s Volodyya, and I’ve been a Ruby developer for many years now. I’m on the Pivorak Ruby Community core team and a Ruby mentor.
Ruby engineers have been quite a in demand lately, while when it comes to hiring them, there’s not that much of a choice for recruiters to make. Well, this is the 2010 whirlwind hype at its notorious best: the year witnessed Ruby on Rails hitting the popularity charts, while in 2015, we saw many engineers leaving for Node.js, React, Python, and Elixir, as well as other contiguous web technologies. Nonetheless, the projects built on Rails did not vanish into thin air. What’s more, today’s full-stack software development lets us observe the technology’s renaissance. It took years to form the best practices and write copious books and articles – everything a newbie might need to feel more confident. Yet, we are nowadays short of experienced engineers and not newcomers. So, where do we find them?
I’ve been prompted to write this article by a hypothesis that’s been getting on my nerves for the last couple of years. Having started their professional journey, Rubyists find it hard to reach the next career level if not being mentored by experienced engineers; the fear of plunging into something new and unfathomed only exacerbates the situation. Sure, it all can boil down to the wide variety of methods and approaches to dealing with the one and the same issue, just as well as uncertainty in one’s decision-making.
What is more, the accessible information pool is over-saturated with varied literature, articles, and limitless online courses, prevailed by converse views regarding the very same issues. Thus, folks get to feel behind the trends and, as a result, lose their motivation to continue learning. Finding your own roadmap amid this smokescreen is a tall order to deal with. Let’s puzzle it out!
Becoming a Ruby Engineer with Pivorak
Five years ago, the Pivorak community enthusiasts launched a course for Ruby developers, known as the Pivorak Ruby Summer Course. Based on the idea of mentorship and self-education, the course goes on for two months, equally split into an intensive theoretical session and a mentored practical involvement into a real-life project. More than a hundred Ruby freshmen have graduated from our course over the last four seasons. Our course’s key success factor is our graduates’ high employment rates ensured by the support of our partners. Many of those whom we taught have become experienced engineers, yet some haven’t had the guts to start their professional journey and went off the distance. Yet, those who are only 1-2 years into the Ruby world and are already lost or too idle in development also come in abundance.
The question is why so many specialists, with years of tangible project development and production experience, are still beating around the bush of Ruby basics, unable to form their individual vision of professional development? How’s that even possible that a developer with one year of experience knows how to harness SOLID and patterns, while the others – with more than ten years into the industry – haven’t made it further than the service objects and still think that infused with business logic models and callbacks are just fine? Let alone Faraday, which is something they don’t even bother learning about!
Evidence suggests that we’re lacking refresher and advanced training courses. People need help with not only “becoming IT”, but also moving forward: from junior to middle, from middle to senior. I’m not much of a fan of those “labels”, but as long as the market standards go by this terminology, I’m fine with that.
The Hypothesis Validation
In order to check this hypothesis, a month ago, I announced enrollment for a free-of-charge mentorship in my Telegram channel. The conditions to meet were simple: an entry-level of working experience, bats in the belfry, and the desire to learn. The number of messages I’ve received was overwhelmingly surprising. Sure enough, it was impossible to mentor everyone. Still, allocating 30 minutes to get acquainted with every candidate was an exceptionally useful and exciting endeavor. Eventually, I’ve chosen three of them who, in my opinion, needed a mentor real bad: they had no team leader, a strong desire to develop, and time to invest in the process. I’ve thanked everyone else for their time and promised them to write this article. Said and done.
Here comes the tricky part. Generally, when I’m being asked about my go-tos regarding the news on Ruby, I rather stay silent or blurt out something like: “I google on purpose.” Googling stuff is a helpful habit, yet not that efficient. When solving an issue, you should have 2-3 viable variants to choose the most optimal out of them. Only real-life cases described in books and articles can supply you with the volumes and quality of information needed to opt for that variant. So yes, get ready to hit the books. When I interview newbies, and they say something like, “Books are tedious and boring,” I feel like crying. Humanity has not yet come up with a better training method than reading. One way or another, there’s a reason why you’re reading this text, right? Reading is a long and meditative process that does not require you to learn the entire text by heart. It’s all about choosing the essential parts, analyzing them, and forming your vision of the absorbed information. That’s it: patience and hard work.
Here’s my selection of portals to read:
- The RubyWeekly digest is the best platform to stay constantly updated on the news, scandals, and everything that’s worthwhile in the Ruby world.
- Twitter is the place where everything comes faster and more abundantly than on RubyWeekly. Find everything possible regarding Ruby, Rails, and Hanami and stay in the loop. It’ll take time to distinguish between what’s worthy and what’s not, but you’ll get there.
- ruby.libhunt – this is my compass when it comes to searching for relevant libraries. I always use it when the question boils down to finding a ready-made code instead of coding it all myself.
At its core, Ruby is a simple language. The main building blocks are not that many. Everything’s an object, and you can apply the public_methods and object_id methods to every object and watch everything happen yourself. Objects are affiliated to inter-heritable classes. The modules are needed for namespaces and mixins. Even the primitive data types, such as Numeric, String, Hash, and Array, are very powerful; nonetheless, Struct, OpenStruct, Set, Queue, and others are also worth your attention. There are many tools to pull out of the Ruby box, and you don’t need to use everything, but knowing how to apply them all is a must.
Quite often people find it hard to deal with method_lockup, as well as understand how things occur within the language. Thus, I would recommend you to read BasicObject and then move along the tree of standard classes.
The books I recommend reading:
- The Well-Grounded Rubyist, Third Edition by David A. Black and Joseph Leo III – there is nothing better for newbies to read.
- Ruby Programming Language by David Flanagan and Yukihiro Matsumoto – it was the first book on Ruby that I’ve read. It’s old but still delivers the ruby-way idea just fine.
Asking whether a programmer must know what OOP is when working with a language where everything is an object is a rhetorical question. We need an object-oriented design for delivering a discernable and clear description of the program’s business processes. We write code for folks and not machines, so let’s not reinvent the wheel. The industry has everything ready for us. We only have to familiarize ourselves with the methods and tools available and instrumentalize them. Merely knowing SOLID is not enough, you have to use it actively.
Here comes a stunning selection of patterns with Ruby examples from my colleague Bohdan. When I interview the new candidates, I often ask them to describe any interior object – be it a chair, table, or guitar hanging on the wall – within the OOP context. As a rule, newbies often get stuck when it comes to design, so here’s a couple of books I recommend reading:
- Practical Object-Oriented Design, An Agile Primer Using Ruby by Sandi Metz – this is interesting research on the OOP design based on the example of a company renting bicycles. It is deemed classics among Rubyists.
- 99 Bottles of OOP by Sandi Metz, Katrina Owen, and TJ Stankus – a great follow-up on the OOP design topic.
Magic is a hoax. This is just the code that was written by someone else. Metaprogramming is a code writing method that generates another code. This is the dark side of the force and you have to know about it, while the matter of using it is still up for discussion. When it comes to building a DSL, I use class_eval, instance_eval, define_method, send, and public_send. If you want to know more about it, I recommend you to read the book Metaprogramming Ruby 2 by Paolo Perrotta.
If you’re more of a video person, pay attention to a lecture by Volodymyr Benyo, my colleague from the first season of the Pivorak course.
It does not matter whether you’re writing tests prior to code; what matters is whether you write them at all. A poorly written test is better than an inexisting one. Tests must be written. Full stop. The thing that matters here is just accepting this as a fact and starting writing them. During an interview, don’t bother yelling out that “development goes faster without testing.” A developer saying things like this does nothing else but testifies to their scarce qualification. Testing is an inalienable part of software development. “Client does not pay for testing” is just an excuse used to mask one’s sloth. When you get into a car, you don’t ask someone whether you should fasten your seat belt. Tests are your seat belt.
While RSpec is the testing standard in the world of commercial Ruby development, it would be an excellent decision to find out what must be tested and how the testing must be carried out:
- Effective Testing with RSpec 3 by Myron Marston and Ian Dees
- Everyday Rails Testing with RSpec by Aaron Sumner
Ruby on Rails
As I’ve already mentioned, magic is a hoax. This is just code that someone else has written, and by saying someone else, I mean these folks. First of all, you must know the Rails components: ActionPack, ActiveRecord, ActiveModel, ActionView, and others. The very framework module matters a lot, and keep in mind that you can always adjust the components you need. Rails offer you a plethora of opportunities, but not each and everyone is worth taking. Injecting business logic into controllers and models – that’s a no-go by default; the rest shall come with experience. My first book was Agile Web Development with Rails by Sam Ruby and David Bryant Copeland – the 3.0 edition. You can also find a succinct guide to Ruby in Rails Crush Course: A No-Nonsense Guide to Rails Development by Anthony Lewis.
Sure enough, Rails is a framework for creating web apps and you can’t get away with it if you don’t apply some special tricks. In due time, I have binge-watched all the RailsCasts from the legendary Ryan Bates. Yet, if we’re talking new school, I suggest paying attention to GoRails and Chris Oliver.
I cannot fail to mention Crafting Rails 4 Applications by José Valim. Don’t get spooked by the number 4 featuring in the title. The things that José describes in his book have once and forever changed my attitude towards developing web apps with Rails. The book is still relevant.
As a follow-up, I suggest taking a look at Modular Rails by Thibault Denizet. This book will show a whole new world of Rails apps architecture. I’m sure the book will resonate with those in the know. If the project you’ve ended up on is already “decomposing”, consider reading Fearless Refactoring Rails written by my colleague from Wrocław, Andrzej Krzywda.
Practice. Lots of it. Programming must not rest in your head but reach your fingertips. Your head, in turn, must be nothing else but storage for the most efficient solution to an issue at hand.
I do recommend you to create a side- or a pet-project of your own that will serve you a sandbox, where you’ll be able to try out everything you’ve read about in the books and articles. Make sure to transmit only the workable, tested, and ready-made solutions into work. Do not expect your work project to become a playground for learning things. Professional development is your sole responsibility. Your employer is only responsible for paying your wages on time; so you could buy more books and video courses.
To my deepest conviction, you cannot be a great Ruby developer, if you know only Ruby. There’s a lot of other and cool programming languages and frameworks that you can take the most of. New techniques and paradigms enhance and extend the potential for generating effective solutions within Ruby. Now that you know one language, learning a new one shouldn’t be that hard. In due time, Elixir and Phoenix Framework have become my development tools. Practicing these technologies has rendered me a better Ruby specialist, while Ruby itself has lowered the margin of my assimilation into Elixir. By the way, here comes a cool book that I suggest you read: Phoenix for Rails Developers by Elvio Vicosa.
Programming is hard. I find it hard to believe that there is a simple way of professional development but for continuous learning and practice. Do not deceive yourself with illusions that you can learn everything in practice without reading books and articles. Spare yourself time and effort, and adopt the experience of others. Eventually, our occupation is about automation and the world’s betterment.
I cordially invite everyone – my opinion’s proponents and opponents – to join the conversation in the comments. Attach links to educational resources that you’ve found useful. And subscribe to my Telegram channel