Saturday, May 11, 2024

Ruby on Rails Developers Choose Technologies To Do The Best Job Possible For Customers

Ruby on Rails developers who say things like "Oh! It is OK to use any programming language you like! Whatever strikes your fancy is good! JavaScript is OK if that's what you like. If you prefer TypeScript, go for it!" are some of the dumbest people around and the biggest enablers of mediocrity in the Ruby on Rails community. 

Telling others to use anything means those people do not really use Ruby for the Software Engineering objective pros/cons/trade-offs that it has against other programming languages in specific project related situations, and do not really get the full unique benefits of Ruby that are not available in most other programming languages. As such, instead of using Ruby as a smart well-thought-out Software Engineering decision, they use Ruby as merely a personal preference without much understanding of how using other programming languages instead of Ruby might negatively impact customers and team work in software project development. In other words, those people are Fake Rubyists, not Real Rubyists or real Software Engineers who truly understand Ruby to begin with. What they believe is eating shit is the same as eating Pork Ribs as if shit is just another valid choice out of several that are all equal to Pork Ribs when in fact every choice has its own pros and cons, some with cons so bad that they are the equivalent of shit in Software Engineering. 

I know it sounds "nice" and "agreeable" to tell others that they could use any programming language that strikes their fancy, but in fact, it is unnice to customers to have them get their projects delivered later and with more potential for bugs and slower productivity for adding features due to using objectively unsound programming languages for certain customer project situations. The nicest thing someone could do for customers is to guide others towards using the most excellent technologies for their project situations to deliver the best solutions possible. Being nice is delivering the best quality to customers. Also, being "agreeable" is not what customers pay you for. They pay you to deliver the best work possible. Teamwork is what matters the most, not being "agreeable", and the best teamwork is facilitated by being 100% honest and disagreeing when there is a big elephant in the room, thus getting rid of it, and delivering the best quality work possible instead of being slowed down by bad technologies just to be "agreeable".

In conclusion, telling others it is OK to use any technologies just for personal preferences is a lie! It is NOT OK as using the wrong technology for a certain project will yield slower productivity, worse teamwork, and more complicated maintainability that raises costs and time for delivery significantly for customers.

As such, I never trust anyone who tells others it is OK to use any technologies they like as those people are compromised by peer pressure to please other developers instead of doing the best job possible for customers (what they are paid to do). Even some Rubyists with weak personalities (e.g. DHH) caved in to peer pressure just because "everyone is now doing it (e.g. using JavaScript), so it must be OK now to do it too" or because "Some technology [e.g. JavaScript] caught critical mass, so it must be better to go with the flow", forgetting that when Rails started, everyone was doing something completely different too and J2EE had caught critical mass back then, and yet we did NOT cave in to pressure and choose what was most popular, yet we chose Rails instead as a very bold Software Engineering decision to do the best work possible for customers. As such, they limited themselves inside the box of what is liked for personal preference reasons instead of thinking outside the box with the best possible Software Engineering solutions for customers (e.g. using Ruby in the Browser to bring Ruby's awesome productivity/maintainability to the Frontend, which not even the 2020+ versions of JavaScript come close to matching).

Getting something working with bad technologies does NOT mean you did the best job possible for customers. Sure, anyone can get anything working with almost any technologies. But, did you get it working with the highest productivity, simplest maintainability, and most enablement of teamwork? Did you cut down costs and time to delivery by using the best technology for the project situation? 

We serve the customers! The customers do NOT serve us! That means developers use the best technologies for customers depending on their specific project situations. Customers do not serve developers by accepting a negative hit on their project timeline or code quality just so that some selfish developers might get to "enjoy React" or whatever BS you hear from mediocre developers who are cheating their customers nowadays. 



No comments: