Ruby Feels Weird (Until It Doesn’t)

Learning a Different Syntax Style

Most of my day-to-day programming work over the last several years has been in Java. After spending years writing code with curly braces, explicit structure, and strongly defined patterns, Ruby immediately felt different.

Not harder. Just unfamiliar.

At first glance, Ruby almost looks too simple. No type declarations, minimal ceremony, and methods that often read more like English than code. The syntax itself is easy to follow. The harder part is understanding the conventions and idioms Ruby developers naturally reach for.

A lot of the language initially felt strange simply because it solves common programming problems differently than what I was used to.

---

Methods Read Almost Like English

One of the first things that stood out to me was how expressive Ruby methods are.

5.even?
"hello".upcase
users.empty?

Ruby leans heavily into naming conventions that communicate intent directly in the method name itself.

Methods ending in ? typically return booleans:

user.active?
array.empty?

Methods ending in ! usually indicate mutation or a more dangerous version of a method:

sort!
upcase!

Coming from Java, this initially felt unusual because so much meaning is encoded into naming conventions rather than strict language rules. But after seeing it repeatedly, the code starts becoming surprisingly readable.

---

Conditionals Felt Backwards at First

One of the first things that really confused me was how flexible Ruby conditionals are.

You can write conditionals traditionally:

if success
  puts "done"
end

But Ruby also encourages postfix conditionals and guard clauses:

puts "done" if success

return unless user

At first, that style felt backwards to me. I kept mentally rewriting everything into larger explicit conditional blocks because that structure felt safer and more familiar.

Eventually, though, I started understanding why Ruby developers prefer this style. It keeps methods flatter and makes the primary logic easier to scan quickly.

I still think Ruby occasionally enables code to become a little too clever, but I can definitely see the appeal now.

---

Enumerables Are Where Ruby Started Making Sense

The biggest mental shift happened once I started spending time with enumerable methods like:

• each
• map
• select
• reduce

That part actually became easier once I stopped viewing it as “Ruby magic” and started relating it to Java Streams.

In Java, I already write things like:

users.stream()
    .filter(User::isActive)
    .map(User::getEmail)
    .toList();

Ruby just expresses the same idea with far less ceremony.

users
  .select(&:active?)
  .map(&:email)

At first, the Ruby version honestly looked harder to read because the syntax is so condensed. But once I became comfortable with enumerable chaining and blocks, the style started feeling much more natural.

Ruby seems heavily optimized around transforming collections cleanly and expressively.

---

The &: Syntax Looked Completely Ridiculous

This was probably my biggest “what am I looking at?” moment.

users.map(&:name)

The first time I saw that syntax, it looked completely unreadable.

Eventually I learned it was shorthand for:

users.map { |user| user.name }

Once I understood the underlying concept, it started feeling much closer to Java method references than random Ruby wizardry.

That became a recurring pattern while learning Ruby. A lot of syntax that initially looks confusing starts making sense once you understand the idea the language is trying to express.

---

Blocks, Procs, and Lambdas Took a While to Click

Another thing that confused me early on was why Ruby even needs Procs and lambdas when methods already exist.

That question ended up leading to one of the more useful conceptual breakthroughs so far.

Methods are named behavior attached to objects.

Blocks, Procs, and lambdas allow behavior itself to become something portable that can be passed around, stored, and reused dynamically.

Blocks are everywhere in Ruby:

users.each do |user|
  puts user.name
end

Then eventually you encounter Procs and lambdas:

square = ->(x) { x * x }

At first, they felt unnecessary. My thought process was basically:

“Why is this not just another method?”

The example that finally made this click for me was seeing multiple transformations passed into a method as data.

double = ->(x) { x * 2 }
square = ->(x) { x * x }

def transform(number, operations)
  operations.each do |operation|
    number = operation.call(number)
  end

  number
end

transform(2, [double, square])

That was the moment I stopped viewing lambdas as “weird alternate methods” and started understanding them as reusable chunks of behavior that can be composed dynamically.

Coming from Java, the closest mental comparison was probably functional interfaces or Stream transformations, but Ruby makes the syntax feel much more lightweight and natural.

---

Hashes and Symbols Were the First Real Gotcha

One of the first genuinely important Ruby concepts I had to stop and clarify was hashes and symbols.

Particularly this distinction:

user[:name]

versus:

user["name"]

That confused me immediately because both look nearly identical if you are new to Ruby.

Understanding symbols — and how heavily Ruby relies on them — felt like one of the first moments where Ruby stopped feeling like “different syntax” and started feeling like a language with its own conventions and mental models.

---

Still Very Much Learning

I am still extremely early in this process.

If you turn off autocomplete completely, things get humbling very quickly. That is part of why I want to spend the next phase of learning working through basic LeetCode problems entirely in Ruby. Repetition feels like the fastest way to build actual fluency with the syntax instead of just recognizing it when I see it.

So far, the hardest part of learning Ruby has not been understanding what the syntax means.

It has been understanding why Ruby developers prefer writing code this way in the first place.