Comments for Code with Jason

Comment on Why I don’t buy “duplication is cheaper than the wrong abstraction” by Michael

Michael — Sat, 03 Jan 2026 17:56:39 +0000

> It seems to me that what’s meant by “the wrong abstraction” is “a confusing piece of code littered with conditional logic”.

Having thusly reframed the definition, it can indeed be very easy to miss the point.

There comes a time when a senior developer, after stepping back to look at the terrain, realizes that *every* rule in the book is optional and subject to context and priorities. At that moment they’ve become a master.

The “wrong abstraction” is about the *semantics* — the meaning — of what is being abstracted. The valued currency for people for whom it clearly appears as a potential source of problems is clarity, or more generally, maintainability. Some people care more about making their code *actually* accessible to other human minds. When this becomes an authentic pursuit, there’s an inherent acknowledgement of our natural biological and psychological limitations and one tends to also reign back the mechanical software engineering box-checking, which tends to be neglectful of such factors.

An abstraction can seem right for a very long time, while at the same time being confusing. How? Consider a piece of software that implements operation A that very specifically relates to oranges, and another unrelated piece B which is similarly specialized for space shuttles. Let’s imagine that A and B are separately very grokkable. They’re also semantically completely unrelated, and yet their algorithms are close enough that a case for generalizing them could *technically* be made. The abstraction would probably reduce deduplication, but it would also probably incur some valuable clarity points.

The decision to abstract or not can be valid either way, that’s not important. It’s the aware acknowledgement of gains vs losses that is.

Comment on Abstraction != abstractness by Jason Swett

Jason Swett — Wed, 18 Jun 2025 20:23:31 +0000

In reply to Travis.

I don’t know, I thought I killed it

Comment on Abstraction != abstractness by Travis

Travis — Wed, 18 Jun 2025 20:18:07 +0000

You could have used, “the chicken cross the road”! Why are your examples so morbid?!

Comment on Understanding Ruby blocks by kemboiray

kemboiray — Tue, 27 May 2025 17:03:33 +0000

In reply to mark.

Does it behave similarly to higher order functions in JavaScript?

Comment on How I code without service objects by Matt G

Matt G — Thu, 27 Feb 2025 14:03:21 +0000

I feel like I might be missing something here. I don’t understand how not using a service object is inherently a more “declarative” option. Ruby is an imperative language and unless you have the luxury of being able to take advantage of a DSL with a comprehensive declarative syntax, your application code is always going to be imperative. As far as I can tell, whether you organize your business logic in app/models or app/services doesn’t have any bearing on whether it’s imperative or declarative.

Comment on Understanding Ruby closures by Laszlo Foldes

Laszlo Foldes — Thu, 13 Feb 2025 11:36:06 +0000

You just made `number_of_exclamation_points` local, that does not make a Closure more ‘closing over’ any variable. Any variable created in a method is local to that method.

Comment on The difference between RSpec, Capybara and Cucumber by bpc415

bpc415 — Sat, 08 Feb 2025 22:53:43 +0000

One of the key advantages of using Cucumber is abstracting the software specification from the implementation. I could write a cucumber spec in python to test a rails application.

Comment on How do we tell what’s a good programming practice? by CRISTIAN M

CRISTIAN M — Wed, 05 Feb 2025 12:55:11 +0000

Great post, thanks for sharing. I totally agree with it.
Another argument I particularly find anoying is when you present good arguments but the response is ”but the rest of the project’s code was done differently so we will continue this way”.
What’s your opinion on continuous refactoring vs big refactors tickets (accumulated in the backlog)?
Regards

Comment on Meatspace abstractions by katafrakt

katafrakt — Wed, 05 Feb 2025 11:48:59 +0000

I’m not sure I would agree with a storm being an example of an abstraction. Abstraction is something we intentionally make (gear is a great example). But with storm it is “just” putting a distinct name to something that already is there. I put “just” in quotes, because even though it’s not an abstraction (IMO), it is equally important phenomenon, if not more important.

Why do we have distinct words for some things and not for others? In this case it’s probably the case of efficiency of communication – storm is more dangerous and you should react to it differently than to just rain. I think it’s more akin to patterns in software development. Patterns are not something we invent, but rather something we start to find, observe then we decide it’s important enough to give it a distinct name. And then some “code style” some people were using get a completely new life as a named entity.

Anyway, nice and thought-provoking article.

Comment on How to do multi-step forms in Rails by Sinal

Sinal — Thu, 09 Jan 2025 04:22:55 +0000

Thanks for sharing this approach. I encountered this while implementing order processing, and I will consider it.