Frontend development has always been my comfort zone. JavaScript, CSS, React — I knew how to bring designs to life and make things interactive.
Backend? That was someone else’s job. But then, I had to make a backend change.
At first, my instinct was to ask a backend developer for help. But then, I thought—how hard could it be? After all, we have AI now, right?
I was working on the onboarding flow for job seekers, ensuring we fetched relevant data from their preferences and resumes. We already had a service extracting skills from resumes, so all I had to do was send one more extra field. It sounds simple enough.
I wrote the code, pushed the changes, and tested it locally. It worked! But something about it fascinated me. Instead of just moving on, I wanted to really understand what was happening under the hood. That curiosity pushed me deeper into Rails.
The Mistakes I Made (And What They Taught Me)
I opened the codebase, trying to approach it from a JavaScript developer’s mindset. I looked for familiar patterns, if-else statements, function calls and data manipulations.
My first instinct was: "Let me write this from scratch."
1. Where’s My Object?
I initially wrote something like this:
resume = HackerResume.where(hacker_id: current_hacker.id, active: true)
I assumed where would return a single object, just like find in JavaScript. But nope! where returns an ActiveRecord relation (basically, an array). What I actually needed was:
resume = HackerResume.find_by(hacker_id: current_hacker.id, active: true)
Always check whether a method returns an array or a single object. where is great when expecting multiple results, but for a single record, find_by is the way to go.
2. I Forgot to Import the Model
Everything seemed fine, but then I hit a NoMethodError. Rails was telling me that HackerResume was undefined. I was confused because I saw it being used elsewhere in the code.
After some digging, I realized I had forgotten to import the model in the file where I was using it. I had to manually require it in my case.
include Community::Apply::ResumeHelper
3. job.skills Didn’t Work
I expected job.skills to return the skills associated with a job. But instead, it threw an error. Why? Because job was a hash, not an Active Record object!
Instead of this:
job_skills = job.skills
I had to do:
job_skills = job['skills'] || []
In Rails, hashes and ActiveRecord objects behave differently. Always check whether you're working with a model instance or raw data.
4. Loop Didn’t Update the Array
I tried using a loop similar to JavaScript’s forEach, assuming it would update my array:
active_jobs.each do |job|
job_skills = job['skills'] || []
missing_skills, _, matched_score, matching_skills = matcher(job_skills, current_hacker.id, job['job_url'])
job['matched_score'] = matched_score
job['matching_skills'] = matching_skills
job['missing_skills'] = missing_skills
end
But it didn’t update active_jobs. I learned that, unlike JavaScript modifying elements inside .each in Ruby doesn’t update the original array.
Instead, I had to use .each_with_index and update the array manually:
active_jobs.each_with_index do |job, index|
job_skills = job['skills'] || []
missing_skills, _, matched_score, matching_skills = matcher(job_skills, current_hacker.id, job['job_url'])
active_jobs[index] = job.merge({
'matched_score' => matched_score,
'matching_skills' => matching_skills,
'missing_skills' => missing_skills
})
end
What I Learned About Rails and Ruby
At first, I thought of Rails as just another framework with its syntax. But the more I worked with it, the more I realized that Rails is built on Ruby’s unique strengths. To get better at Rails, I needed to understand Ruby first.
Rails follows a philosophy called Convention over Configuration, which means developers follow a set of predefined rules instead of writing repetitive configurations. This makes development faster but can be confusing if you don’t know the conventions. More on Convention over Configuration.
Some key things I learned:
Ruby Methods Are Flexible – Unlike JavaScript, Ruby allows default values, named arguments, and dynamically defined methods.
Blocks, Procs, and Lambdas – These allow Ruby to handle functions in different ways, often used in Active Record scopes and callbacks. Guide on Procs & Lambdas.
Rails Uses Metaprogramming – This allows Rails to dynamically define methods, reducing repetitive code. Understanding Metaprogramming.
Symbols Are More Efficient – :symbol is more memory-efficient than "string", which is why it’s commonly used in Rails.
Enumerable Methods Make Things Easier – Built-in methods like map, select and reduce made handling collections much simpler. Enumerable Methods in Ruby.
………………This all happened just last week, so I haven't had much time to read more but I would love to explore more of its magic!
My Takeaway
What started as a simple task of adding some fields turned into a deep dive into debugging, reading documentation and learning the internals of Rails. Tbh, I just wanted to get the job done. But the more I explored, the more I appreciated the elegance of Ruby and Rails.
Looking back, my mistakes were lessons. They forced me to read source code, experiment, and understand concepts rather than just making things work.
Now, I feel a little confident diving into the backend world. And the next time I need to write Rails code, I won’t just be copying and pasting, I will actually know what I’m doing :)
