The engineering selection process at Devengo prioritises candidates with the right profile regarding previous business experience and skills over a perfect match on a specific toolset. Consequently, our hiring application process is language-agnostic, and a big portion of our dev team had no experience with Ruby/Rails when they started working at Devengo.
This article describes the reasons for this approach and presents some insights members of our team have developed after landing in the Ruby landscape.
People over tools
In the good ol’ days of web development, it was pretty normal for most developers to have quite a broad set of skills. One would have to be able to deal with a backend language (PHP, Java, Perl…), be fluent enough in frontend technologies (HTML, CSS, Javascript) to build the UI, have enough knowledge to be dangerous when it came to data storage and DBs, and finally have more than a basic grasp on how servers work to deploy and maintain the final product/app. What is now called “full-stack” is not actually a recent invention but the original modus vivendi of most web developers at the end of the 90s, through the 2000s and the beginning of the 2010s.
Of course the web used to be a simpler place then. Now, the complexity of the web is obscene, and the amount of code inside the browser you are using to read this post is not far from the amount you need to build a whole mobile operating system. As a consequence, the work of most of the professionals in the sector has been increasingly specialised in the last decades.
Unfortunately, skill specialisation has been misunderstood by many companies as just tool specialisation and today, the desired profile on many hiring processes looks like a shopping list more than a qualification instrument. You have seen the offers: “The candidate must have ${random_number_of_years} years of experience in ${random_tool_we_are_using_now} and ${random_number_of_years} years on ${another_tool} and…”
The problem with a tool or specific tech-oriented mindset in a selection process is that tools are a very bad proxy for identifying the right candidate for your company for multiple reasons.
First, of all the different pieces that conform to the technological profile of a developer (or a company), the tools are the part that changes more frequently and more rapidly. In that sense, technology has its own pace layering, an idea first introduced by Steward Brand, and tools sit as the very top layer. If we keep digging, we will find other layers like Stacks, Frameworks, Languages, Practices, Principles, and Protocols, each showing great, deeper friction to change.
All of them are eventually subject to change, but if you have to bet on which one you will change first, you will be safer picking from the top layers. Focusing on the tools to pick the right candidate is not only a moving target but also the wrong one.
Second, technologies are very context-specific and, therefore, subject to becoming obsolete or inefficient as the business naturally evolves, both in scale and/or nature. The toolset for managing 10 RPS and 10.000 RPS is substantially different and requires changes in deeper, more substantial layers. So even if you could pick a developer ticking all the boxes of your current toolset, you will soon find that those boxes are not relevant anymore, and a whole new set of boxes is now the right thing you need.
Finally, and more importantly, obsessing about specific tools and technologies moves the focus away from important traits that are more universally useful and vital to everyday software development: the ability to communicate clearly your designs and decisions, the internalised use of good basic practices like testing, the capacity to self-organise and deal with unknowns. All these skills are far more future-proof, versatile and relevant than having 1 or 2 years of experience using this or that language.
For all these reasons, we are always looking for professionals who have the necessary knowledge to perform the functions of their position regardless of the technology used, and our hiring offers reflect that.
I hear you saying… “but doesn’t that imply that there is a very long learning curve?”. Not necessarily. A large chunk of the time spent in the onboarding of a new coworker is dedicated to explaining the “where” and the “why” of things in the company, both technically and from a business perspective.
Knowing this or that process is asynchronous, delivered to a queue or required for regulatory reasons is the most substantial thing for someone landing on the project. The fact that your current implementation is using RabbitMQ, Amazon SNS, or Pub/sub is not completely irrelevant but for sure more inconsequential, even more so if you hire senior developers who are used to moving between different technologies.
We have seen coworkers go through that process many times, and we’d like to provide some examples of this approach from the developer’s point of view. So here are some preconceptions about Ruby members of the dev team before joining, how they have changed after learning Ruby in Devengo, and the insights they have gained in the process.
Raul (9 months using Ruby/Rails)
Raul is one of the latest additions to Devengo. Previously, he had worked on large Java (+ SAP, SOAP) apps for over a decade, something that shaped his first weeks in Devengo:
During the first weeks, the issue of conventions was -as expected- the most difficult for me to internalise about Rails. I started with the idea that I prefer a framework in which everything is explicitly defined to clearly see a map of the terrain I am walking on.
In Ruby/Rails, everything is packed with conventions, the “magic”, as is commonly referred to. For example, if you don’t indicate explicitly which template will render, the one associated with the name of the controller+method will do. The same thing happens with routes and many other things.
Before joining Devengo, he worked for a few years with Python, a “closer” experience in some ways.
At the philosophical level, I have been struck by the strength of “pragmatism” that I have noticed in the Rails ecosystem (and in Devengo as well, by osmosis). It’s a bit intangible, but I feel much more focused on “Hey, this is about building tools effectively and efficiently.”
I come from the “software craftsmanship” world, and I already had the idea of “Are we not thinking about things that are not so important?” What difference does it make if this function does more than one thing? Are we really going to separate related tasks into three functions?”. I’m evolving along the same lines with TDD; it was almost unthinkable for me to write code without doing strict TDD, and if I did, I felt dirty. Now, without getting to DHH level, I’m waaaay more flexible with this.
Carlos (15 months using Ruby/Rails)
Carlos arrived from a completely different vertical -software for streamers- where he was using Node and Typescript. He was initially worried about the “Ruby/Rails doesn’t scale mantra”:
Before coding a single line of Ruby/Rails, I had a prejudice that it was slow and that you couldn’t scale it. Total nonsense. I have been able to see first-hand that Ruby/Rails is capable of handling our entire volume of requests and processing with fairly standard servers and making intelligent use of tools such as work queues.
As in any other environment, there is immense room for improvement before your bottleneck becomes the language itself. Empirical examples of this are giants like GitHub or Shopify, which have demonstrated the stratospheric scalability possibilities of Ruby/Rails.
Over time, he has grown as a developer and discovered areas where the Ruby/Rails tech is strong:
In Devengo, we usually use the byebug gem to debug our code locally. From my experience, I was used to using breakpoints to be able to go step-by-step inspecting the execution flow, but it had never occurred to me that it would actually be possible to do this same thing with a simple gem and zero configuration. Now, other ways of debugging seem uncomfortable in comparison.
Testing is another point that took me a while to get used to, but now I wouldn’t change it for anything. The ease of
rspecfor defining different test contexts and sharing and making small changes between them without too much fuss far exceeds anything I’ve tried before.
Nacho (2 years using Ruby/Rails)
Nacho came from PHP where he had experience developing HR software under DDD design practices:
What surprised me most about my transition from the Java/PHP world to the Ruby world with Ruby on Rails was the flexibility that exists in the ecosystem to do anything. This flexibility sometimes, and especially when you enter this world, makes certain parts of code difficult to understand what it is really doing due to the “magic” that is done behind it, but once you get used to it, you will not want to go back.
Additionally, we are very conscious of other options we have at our disposal:
If, on the other hand, you need a slightly more rigid ecosystem with typing, you can get it with gems like RBS or Sorbet; if you need something, there is probably already a gem that does it! What pleasantly surprised me was the community and the number of gems that exist, making your daily life easier.
Ivan (+4 years using Ruby/Rails)
Finally, Ivan joined Devengo after being a tech lead in companies like Inditex or Audiense and having tried a lot of technologies:
During the years leading up to joining Devengo, I had been interested in learning different programming languages and exploring various approaches to solving common problems in software development. I dabbled in languages like Scala, Python, and Kotlin and even ventured into other paradigms like functional programming, which I liked but never felt truly comfortable with.
Over time, he has developed an appreciation for Ruby/Rails:
Everything changed when I started at Devengo and had to learn Ruby/Rails. For some reason, in my mind, Ruby/Rails was perceived as ugly and challenging to learn, but I quickly discovered how incredibly concise and idiomatic this language is. When combined with Rails, it’s the stack where I’ve felt most productive, capable of swiftly building an end-to-end web application. Without a doubt, I’m a Ruby lover now.
So, in summary, we should focus on skills like fast learning, team communication and self-organisation because those are far harder to develop than some tech-specific knowledge.
Right now, Devengo is a Ruby-powered shop, and we are pretty happy with it, but we are deeply aware of the weak points it may present in some contexts (concurrency, data processing, etc.) and are always open to adopting whatever technology is needed to take care of business.
Do you have any experience onboarding people in your company to new tech stacks? Let us know on LinkedIn or Twitter, we would love to hear your story!