Addressing Selfish Lame Excuses for Anti-MINASWAN Behavior

When mentioning the problem of Ruby/Rails subreddit members behaving in anti-MINASWAN ways (anti Matz Is Nice And So We Are Nice), some devs give ignorant selfish lame excuses like "Nobody forced you to join those groups!". This is exactly like saying to someone who got poisoned at a restaurant "Nobody forced you to go to that restaurant!", selfishly allowing other people to get poisoned there daily and even die regularly without caring to report the problem and resolve it for the benefit of everyone. Newsflash! If a restaurant does not meet health standards, it must not be open! You cannot allow people there to profit at the expense of other people who visit the restaurant without offering them healthy food and respectful treatment.

The idea of "Nobody forced you to go there" is misapplied here. It does apply if someone is complaining that "Ruby on Rails libraries do not seem to offer the performance characteristics of C/C++". In that case, those devs can go and join a C/C++ subreddit or the subreddits of other more performant statically typed programming languages instead, assuming they received fully respectful non-discriminatory treatment. But, the idea of "Nobody forced you to go there" does NOT apply when basic things like respect and niceness aren't provided equally to everyone, which is a literal form of discrimination! 

In fact, Reddit mods are total hypocrites because they do claim to provide a "safe environment" except they ironically do it with a double-standard discriminatory way by allowing some people who are mean, lazy, and literal haters of Ruby to "feel safe" while making others who are nice, hard-working, and passionate about using Ruby feel unsafe. 

Many Ruby on Rails devs are passive with regards to addressing this covert discrimination because they are indirect benefactors of it. When I hear of discrimination, I don't stay silent. I show concern. I listen. I ask if there is a way to help. In fact, there are Ruby on Rails devs that do those things with a double-standard by ironically discriminating against whoever they lend support to for "discrimination" instead of being against all discrimination for everyone equally. 

2025 Reminder That DHH Is a Total Idiot!

Just a reminder that DHH is a total idiot for not adding any Frontend Ruby tech to the Rails stack in recent years. For the last 10 years, he's pretended to be "forward thinking" and "innovative", but has been closed-minded and standing in the way of progress. He is not what he used to be when he was open-minded in the minded-2000s and helped merge Merb with Rails. Nowadays, he is clearly biased towards JavaScript against Ruby to the detriment of the Ruby community. He claims he is "embracing" JavaScript for "pragmatic reasons", which might sound good on paper and might be something I'd normally agree with, but in fact is hurting the Ruby community significantly as illustrated by the attached JS code examples that many Ruby on Rails devs write nowadays as a result of DHH's closed-mindedness and stupidity. His claim for embracing JavaScript would only be true if there weren't huge differences between JavaScript and Ruby, alas there are enormous differences between the two languages. As such, DHH is an idiot and will always be called idiot unless he humbly corrects his ways and apologizes for destroying the Ruby on Rails community by enabling devs to write code like the attached code in the last 10 years. The blood of such crappy code is on DHH's hands! Only bigger idiots would support DHH's idiotic position. They're all enemies of progress and innovation in the Ruby on Rails community. We all know Hotwire isn't enough, and the Stimulus bit is the part that many devs replace with React.js eventually or from the get-go because it doesn't solve everything effectively and conveniently. By the way, I do not necessarily propose that everyone needs Frontend Ruby as Hotwire could be sufficient for more basic Rails projects, but 100% of devs who use JS libraries like React/Angular/Ember/Vue/Svelte have zero excuses not using Frontend Ruby instead to cut their work by half with much better possibilities facilitated only by the Ruby programming language. The fact that DHH doesn't get that demonstrates how much out of depth and out of touch he's become in Ruby over the last 10 years. 

Me vs Typical Members of Ruby/Rails Subreddits

Me vs typical members of the Ruby/Rails subreddits who claim to be gods in Software Development:

• Me: Have you ever presented at RubyConf, or multiple RubyConfs?
• Them: No
• Me: Have you ever presented at RailsConf, or multiple RailsConfs?
• Them: No
• Me: Did you ever win a Fukuoka Ruby Award, or multiple Fukuoka Awards?
• Them: No
• Me: Do you maintain any Open-Source Software Projects, or award-winning Open-Source Software Projects?
• Them: No
• Me: Do you have a Master's Degree in Software Engineering, or a Bachelor in any computing related field?
• Them: No
• Me: Do you have 10 years of experience in Software Engineering at least?
• Them: No
• Me: But, you think you're a god in Software Development?
• Them: Yes

🤣🤣🤣🤣🤣 Totally delusional! 🤣🤣🤣🤣🤣 

I mean, my answer to all those questions is Yes, and yet I don't consider myself a god at all! That's because As a Software Engineering professional, I must avoid all "pride" to be able to always stay unbiased and open-minded about better ways of Software Development instead of getting attached to what I know while unintelligently pretending that makes a god. The moment someone thinks they are a god (or even a god to their former selves) is the moment they stop improving and stop performing as well as they could be.

The Ruby/Rails subreddits are currently the biggest embarrassments of the Ruby community as they often contain people who are very unhumble and unnice despite lacking experience and skills, violating the Ruby principle of MINASWAN (Matz Is Nice And So We Are Nice) as they don't give Software Engineers with interesting creative outside the box ideas the benefit of the doubt or any much-needed support, thus embarrassing themselves when such Software Engineers end up winning awards for their ideas by Matz, the creator of Ruby himself (like Glimmer DSL for Web winning at the Fukuoka Prefecture Future IT Initiative 2025 competition). Such subreddits are so badly managed that mean/unhumble developers are excused/enabled while nice/hard-working developers are usually allowed to get mistreated and piled upon there. Ruby & Rails subreddit members literally downvoted my posts about Covert Discrimination to zero, not realizing unintelligently that this ended up offering a 100% irrefutable proof of how discriminatory and hateful they are as anyone who doesn't discriminate would have immediately offered support and concern without double-standards if discrimination is pointed out, saying something like "discrimination is wrong no matter what kind it is!" without actually discriminating live against the individual raising the issue with discrimination as to prove it. 

The silence of the Ruby community about this incriminates everyone who is silent about this no matter who they are. I don't care if it's DHH, the creators of Puma, maintainers of Ruby/Rails, Ruby podcast/newsletter content authors, or whoever else. they're all guilty of being enemies of the Ruby community if they remain silent about this problem or even encourage it to happen because this problem kills good ideas, degrading the Ruby community as a whole. This forces the Ruby community to regress to least common denominator weak ideas that "the majority approves of". Truly good citizens of the Ruby community will follow MINASWAN and call out this anti-MINASWAN behavior in the Ruby/Rails community subreddits continuously until the situation is fixed. Beware of people who claim to believe in MINASWAN but apply it with double-standards, discriminating covertly against certain people.

This issue with lack of humility resulting in delusional incompetence is not limited to Redditors as it happens with everyone who has zero humility despite being lazy and having no degrees, no extensive work experience, no open-source contributions, no awards at any Software/Tech Competitions, no presentations at local meetups, no talks at software conferences, and no sufficient reading of Software Engineering books. It's so counter-productive and embarrassing how such devs who lack humility try to argue nonsense with Software Engineers who are very passionate about Software Engineering with actions not just words alone, are true hard workers, have a solid university degree or more, have more than 10 years of work experience, maintain many open-source projects, present frequently at their local meetups, talk at software conferences, and win awards in Software/Tech Competitions. Remember that a beginner snowboarder can't "school" Shaun White on snowboarding, but if they were humble, they could learn a lot about snowboarding from Shaun White who's won Gold Medals at the Olympics with his snowboarding skills. This problem with lack of humility might also be a form of Covert Discrimination against specific people that are not listened to no matter how experienced and accomplished they might be while listening to others with similar or even less experience/accomplishments. That's a form of discrimination, so it is still embarrassing given that discrimination is unacceptable.

Lack of humility in inexperienced devs is a recipe for disaster as such devs never improve, getting stuck in their mediocrity forever as a result. When I was a Junior-to-Mid-level Software Developer, I was extremely humble and always did my best to defer to the knowledge of more senior Software Developers while learning from them as much as I could. Ignoring the knowledge/experience/advice of more senior Software Developers is 100% the loss of the less experienced devs. By the way, I am not saying that as a Junior/Mid-level Software Developer, I didn't have some ideas that were better than the ideas of the more senior Software Developers. The more senior Software Developers always kept an open dialog with me to explore ideas that they have not thought of. That said, many of my ideas were ones that they already encountered and tested, finding out for themselves whether they are effective or not. I listened humbly to them when they pushed back on some of my ideas instead of "feeling offended" like so many selfish self-obsessed non-humble devs who don't put serving customers at the top of their priorities.

By the way, this post is assuming good ethical hard-working Senior Software Engineers who listen to less experienced Software Developers with a two-way dialog, not mediocre unethical rude ones who shut down dialog completely. I sometimes see some younger devs getting immaturely caught up with the drama of "experience wars" (having the attitude of "I told them! I made them understand I'm right despite not having as many years of experience as they did!") while completely forgetting customers and the focus on selflessly maximizing the use of past experience of all coworkers on a team with selfless teamwork to humbly learn and do the best work possible for customers.

Thankfully, devs that are not humble enough to learn and improve give the rest of us job security when they make fools of themselves! Thank you!!!

I Am Not a Fan of Ruby

I am not a fan of Ruby. I am mentioning this to dispel any misunderstandings that some devs have about my use of Ruby. I do not have any personal preference for using Ruby. I do not find Ruby's syntax beautiful. I do not think of Ruby code as art or anything like that. I do not like or love Ruby. 

In all circumstances, I only use Ruby as a Software Engineering decision to provide the best solution possible for specific customer functional requirements while weighing Ruby against alternative technology options, such as Java, Python, JavaScript, C++, C, Swift, Lisp, etc... in relation to pros, cons, trade-offs, and non-functional requirements, such as productivity, maintainability, extensibility, and flexibility.

I am a Software Engineer first and a Rubyist as a byproduct of that, always. If a better programming language than Ruby comes along, I would be the first to start using it to solve customer problems more effectively. That said, I will not jump on any newer programming languages just because of peer pressure or hype/buzz when they do not in fact perform better than Ruby in meeting my customer requirements. 

Ruby Mixins as Rails Concerns

Ruby mixins are usually recommended to be used as 'traits', meaning having a name that is an adjective (e.g. `Archivable`) or descriptive of what the additional object trait is (e.g. `Importer`). That enables thinking naturally about what the class is by reading the mixin name.

I would avoid a common anti-pattern I have encountered in legacy code, which is the 'concern' naming approach of Rails concerns (e.g. `ArchivingConcern`) as that is not a correct use of mixins in Ruby. If an object 'contains' a concern, that comes across as a composition relationship not a form of inheritance like mixin inheritance, so it's confusing given that `include SomeMixin` makes the object behave as the mixin, not just include it in the sense of a composition relationship. We want to be able to think of the object class as being the mixin (e.g. `Archivable`); in other words, the mixin becomes a 'trait' of the object class.

It's amazing how cryptic, difficult to reason about, and expensive to maintain Ruby codebases become when they include countless 'concerns' without honoring the Ruby naming convention for mixins as representing "traits". 

I always like to double check all Software Engineering practices before accepting them in legacy codebases. 

Montreal.rb February 2025 Design Patterns in Ruby

Design Patterns provide reusable solutions to common problems in Software Design and Implementation. Learn how to apply all 23 Design Patterns by the Gang of Four in Ruby by watching the Montreal.rb Ruby Meetup February 2025 Talk "Design Patterns in Ruby"!

YouTube Video:

https://www.youtube.com/watch?v=pi5RAynZWuA&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=16

Presentation Slides:

https://docs.google.com/presentation/d/e/2PACX-1vRMuWVMfMQ9q2YQ_MIFG2i0Jer0KDeGGnuRrZ4J8RQNcSd9ZTvJH-2rgq9_ed5L7WecPk3OuPHvRTtK/pub?start=false&loop=false&delayms=60000

GitHub Repo:

https://github.com/AndyObtiva/design_patterns_in_ruby

Full-Stack Development vs Split Frontend & Backend Development

I see a lot of uninformed posts online that misunderstand the benefits of Full-Stack Development vs Frontend/Backend Development. Know that only Software Engineers who have the full context of the value being delivered to customers end-to-end will be able to deliver max value to businesses while simplifying the Software Design and Code maximally across the Frontend and Backend! 

Anyone thinking "specialization" is useful in this case is like someone thinking that specialization in pressing the gas pedal vs the break pedal is important when driving a car even though that obviously over-complicates how to drive a car with multiple people unnecessarily as it overthinks the complexity of pressing a gas pedal vs a break pedal! It's true that specialization is useful sometimes, but this is certainly NOT one of those cases. One must take into account the complexity of work to decide on whether specialization is useful or not. Frontend Development in its essence isn't complicated enough to warrant specialization that is different from Backend Development. Remember that Software Engineers build Desktop Applications as having both the Frontend and Backend in the same application. Web Development isn't that different. In the end, users have to interact through a User Interface and pull data from a Database. Some people use Frontend libraries that are too over-engineered/over-complicated like React and Angular though, and then use them as an excuse for misplaced "specialization" while lazily coasting at lower productivity by unnecessarily focusing on Frontend Development alone while their fellow Backend Developers coast at lower productivity by unnecessarily focusing on Backend Development alone.

I have worked at several Software Development companies that employed Full-Stack Development as a unique approach that gave them a unique business competitive advantage as Developers like me and others were able to do the work of clients at much higher productivity and with much better realization of customer requirements because we had a Full-Stack perspective. And, we were as SKILLED at Frontend Development as we were SKILLED at Backend Development; in fact, more skilled than our consulting clients' Frontend Developers and Backend Developers despite them being specialized and us being Full-Stack Developers! 

From different jobs I held throughout the years, I have experience in both the Full-Stack Development approach and the split Frontend Development and Backend Development approach (on both sides of it). In 100% of my experiences with companies that split Frontend Development from Backend Development, Frontend Developers ended up overthinking and over-engineering the Frontend while Backend Developers ended up overthinking and over-engineering the Backend, so we ended up with about double the workload that would have been needed had development been done by Full-Stack Software Engineers for both the Frontend and Backend. That's why we end up with crazy-complicated React.js and TypeScript codebases that contradict and break all Ruby/Rails principles! So, never accept BS excuses for "specialization" between Frontend and Backend! They're all misguided and come from laziness and acceptance of terrible over-engineered/over-complicated technologies like React and TypeScript.

Software Developers who cannot put a stake in the ground regarding Full-Stack Development vs Frontend/Backend Development just to be "nice" to some devs they know while being unnice to their paying customers are exactly the kind of spineless pushovers that allow ridiculously over-engineered and over-bloated codebases to happen! They're the kind of Software Developers that must be fired first and NEVER hired in the first place!

In summary, always do Full-Stack Development to avoid overthinking/over-engineering your codebases and to ensure delivering the best business value to customers end-to-end!