I would have thought that "senior" means assessing things in context instead of falling back to truisms. "over engineering" only makes sense relative to a concrete problem you want to solve.
yes, of course. I usually am all about context. It's just this particular example is over-engineered in most context I've seen (and can imagine) in my 18 years of using ruby. Not much overengineered, I've seen much, much worse, but it is still annoying enough.
Sometimes, the cost of keeping really talented senior engineers who have solved a very difficult part of your tech stack is to give them the freedom to over engineer solutions that are probably a bit overcomplicated (maybe like OP). The alternative is they get bored and leave and take a wealth of technical knowledge with them
yes, of course. As I said, it's an urge. I wrote quite a few examples of such stuff myself, ruby is amazing for inventing new control structures and trying things. But then I think about my peers and future self who'll have to change and debug my code later, and spend additional time making stuff simpler. This is actually harder to do.
Programming is about managing complexity. Making stack trace twice as long, hiding control flow in data, most cases of metaprogramming do not reduce complexity, they increase it. Unless your app is all about usage of some specific pattern (a lot of procedural scenarios with sideffects, shortcircuiting on error and no return value) then "railway framework" is not worth it in ruby. Use exceptions (really!). Use throw, maybe.
True true, my org doesn’t even have a staff level, it goes from senior to principal. Not meant as a rebuttal, meant as a reinforcement of role names meaning less.